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 🙂