views:

122

answers:

3

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.

+2  A: 

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.

Matt Spinelli
Thanks for the links. I just read through the distillation and it provides some good points on things I can do to clean up my API. It doesn't cover the issue of security (unless I missed) but perhaps it is in the book. I will take a look for it this weekend.
i8abug
I don't think the book would get into security per se. I provided the links though because it will help the code be more consumable (i.e. exceptions thrown meet a certain standard, not exposing things like List<T> (using IList<T> instead). And could help in making it more stable. I'd give a lot of weight to the other suggestions about architectural considerations. And I second the idea about putting a layer on top of your core functionality.
Matt Spinelli
This is pretty good. Just wanted to add that I found a link for the presentation as well which goes into a bit more detail than the distillation. http://www.myplick.com/view/27oOmIWNgx-/Brad-Abrams-Framework-Design-Guidelines
i8abug
+2  A: 

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.

RPM1984
I've never exposed an API where security was an issue before. How exactly do I layer on top of my core dll? I can create an API dll but it will need to reference the core. If users wanted to, they could still just by pass the API dll and use the core unless there is some way to lock it down.
i8abug
@i8abug - @Adrian K's answer will help you out. It doesn't really sound like you're exposing an API, you're simply "giving developers code" - to reference in their assembly. If that's the case, you need to modify the accessbility modifiers on your Core.dll. Either that, or don't give them the DLL, let them consume the functionality another way (REST-based service, WCF, etc -ie a "real" API)
RPM1984
+3  A: 

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:

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 :)

Adrian K
+1 - Good answer (based on the vagueness of the question).
RPM1984
Thanks for the insight. I've updated the question a bit to add some clarity
i8abug
Thank you. The Managed Extensibility Framework will point me in the right direction.
i8abug