tags:

views:

78

answers:

2

I've inherited an enormous .NET solution of about 200 projects. There are now some developers who wish to start adding their own components into our application, which will require that we begin exposing functionality via an API.

The major problem with that, of course, is that the solution we've got on our hands contains such a spider web of dependencies that we have to be careful to avoid sabotaging the API every time there's a minor change somewhere in the app. We'd also like to be able to incrementally expose new functionality without destroying any previous third party apps.

I have a way to solve this problem, but i'm not sure it's the ideal way - i was looking for other ideas.

My plan would be to essentially have three dlls.

  1. APIServer_1_0.dll - this would be the dll with all of the dependencies.
  2. APIClient_1_0.dll - this would be the dll our developers would actual refer to. No references to any of the mess in our solution.
  3. APISupport_1_0.dll - this would contain the interfaces which would allow the client piece to dynamically load the "server" component and perform whatever functions are required. Both of the above dlls would depend upon this. It would be the only dll that the "client" piece refers to.

I initially arrived at this design, because the way in which we do inter process communication between windows services is sort of similar (except that the client talks to the server via named pipes, rather than dynamically loading dlls).

While i'm fairly certain i can make this work, i'm curious to know if there are better ways to accomplish the same task.

A: 

Why not just use the Assembly versioning built into .NET?

When you add a reference to an assembly, just be sure to check the 'Require specific version' checkbox on the reference. That way you know exactly which version of the Assembly you are using at any given time.

Justin Niessner
A: 

You may wish to take a look at Microsoft Managed Add-in Framework [MAF] and Managed Extensibiility Framework [MEF] (links courtesy of Kent Boogaart). As Kent states, the former is concerned with isolation of components, and the latter is primarily concerned with extensibility.

In the end, even if you do not leverage either, some of the concepts regarding API versioning are very useful - ie versioning interfaces, and then providing inter-version support through adapters.

Perhaps a little overkill, but definitely worth a look!

Hope this helps! :)

johnny g
I second MEF as a good solution for adding extensibility, but it would be a significant effort to expose your application services through MEF if your application is not already structured with dependency injection in mind. One advantage with MEF is that you need the 'Client' (framework) layer, but don't require the 'Support' layer, as hooking up the interfaces is handled by MEF.
Dan Bryant
Thanks, johnny - that's a great set of links. You and Dan are probably right - a bit overkill for what i'm trying to accomplish at the moment. I need to have a very basic API available within the next week. But i'll most certainly spend some time looking at this stuff for future development...
Justavian