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.