What is the best way expose key classes/methods my core API to 3rd party developers?

Question

I have an application that I have designed and this app has a pretty decent core dll that contains an API that my main view's exe uses. I would like to allow other developers to access this core dll as well but I don't want them to have as much access as me since it would be a security risk. What is the standard way of exposing my core dll? Are there any particular design patterns I should be looking at?

I'm using C#

Edit: my question was a little vague so here is some clarification

My program is deployed as a windows exe which references the core.dll. I want other people to create extensions which dynamically get loaded into my program at start up by loading dlls in the /extensions directory. The 3rd party dlls will inherit/implement certain classes/interfaces in my core.dll. I only want to give 3rd parties limited access to my core but I want to give my exe additional access to the core.

I should mention that this is the first time I have written a program that imports DLLs. Perhaps this whole method of allowing users to add extensions is wrong.

Answer 1

How do I modify/expose my API for other developers?

To deliberately allow other developers to work with an API you've built touches on many things, which can be broken into two areas:

1. Resources (documentation, samples, etc) that makes it easier for them to understand (yes - basically an SDK).
2. Architecting, constructing and deploying your solution so that it's easy to actually work with.

Examples include:

• By packing it in a way that suits re-use.
• By using naming conventions and member names that others can easily follow.
• Documentation, samples.
• Providing the source code (as open source) if you're happy for them to modify it.

I would like to allow other developers to access this core dll as well but I don't want them to have as much access as me since it would be a security risk.

Ok, so this gets us right into the second area - the actual solution.

The problem you have is not a trivial one - but it's also quite do-able; I'd suggest:

• Looking into existing material on plugins ( https://stackoverflow.com/questions/tagged/plugins+.net )
• Personally, I've found using attributes and Dependency Inversion to be a great approach.
• There's also stuff like the Managed Extensibility Framework which you should consider.

The big issue you face is that you're into serious architecture territory - the decisions you make now will have a profound impact on all aspects of the solution over time. So you might not be able to make an informed decision quickly. Still - you have to start somewhere :)

Answer 2

Since you're using C#, I would look at Microsoft's Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries and use FxCop to in-force many of them (latest version here ). This won't be all you'll likely need, but it would help put you in the right direction.

Also, take a look at the freely available distillation of Framework Design Guidelines by the same author.

Answer 3

The "design patterns" in terms of an API are more related to things like REST.

I don't want them to have as much access as me since it would be a security risk

Then i would (for the sake of maintenance), layer on top of the core DLL extra logic to prevent this.

The thing is, the "clients" call the API, not the Core DLL.

"How" the API accesses the Core DLL is under your full control. Just only expose operation contracts that you wish.