handling dependencies to a frequently-changing DLL

Question

we have a number of c# projects that all depend on a common DLL (also c#). this DLL changes somewhat frequency as we're in an environment where we need to be able to build and deploy updated code frequently. the problem with this is, if one of these updates requires a change to the common DLL, we end up with several client apps that all have slightly different versions of the DLL.

we're trying to figure out how to improve this setup, so we can guarantee that anyone can check out a project (we use SVN) and be able to build it without issue. it seems like tagging each and every DLL change to a new version is excessive, but I'm not sure what the "right" solution is (or at least something elegant).

it would be ideal if any solution allowed a developer to be able to step into the DLL code from visual studio, which only seems to be possible if you have the project itself on your machine (might be wrong there).

Answer 1

Frankly, I think versioning your DLL in source control is the RIGHT solution.

It's very possible that a quickly changing core DLL could cause binary and source compatibility in a client project. By versioning, you can prevent each project from using the new DLL until you're ready to migrate.

This provides a level of safety - you know you won't break a client's project because somebody else changed something underneath you, but it's very easy to upgrade at any time to the new version.

Versioning in SVN is trivial - so I wouldn't let this be an issue. It's also safer from a business perspective, since you have a very clear "paper trail" of what version was used with a given deliverable of a client project, which has many benefits in terms of billing, tracking, testability, etc.

Answer 2

I think you could benefit from setting up a continuous integration server with targets for each of the client projects and the common DLL project.

This way you'll immediately know when changes in the common DLL breaks any of the client projects. It could reduce the trouble of updating client projects when common DLL's interface changes. This solution might be inadequate if you development team is distributed and very large.

I wouldn't say there is a RIGHT solution though. There are many ways to manage dependency problems.

You could also have a look at Maven. It will help you set up project dependencies. Not sure how you can integrate Maven into Visual Studio though. Maven will allow you to specify which version of a project (in SVN) you want to depend on. Developers will then be able to checkout the correct project version and build their projects. Maven will checkout the correct version of the dependent projects from SVN for them. I haven't work with it myself, but a lot of open source projects in the Java community uses it.

Answer 3

There's no easy solution - and the previous two answers are possibly the more accepted method of achieving what you want. If you had a CI environment, and were able to roll out all of your apps on-demand from a store that was built via CI, then you could avoid this problem. That can be lofty ambition, though, if there are old apps in there not governed by tests etc.

If your application is .Net 3.5 (might even need the SP1 too) then did you know that assemblies that are loaded from the network now no longer have any trust restrictions? This means that you could configure an assembly path on the machines in question to point to a shared, highly available, network location - and have all of your apps locate the assembly from there.

An alternative to this, but which would achieve the same goal, would be to build a component that hooks into the AppDomain.CurrentDomain.AssemblyResolve event - which is fired whenever the runtime can't auto-discover an assembly - and do a manual search in that network location for the dll in question (if you were to take the AssemblyName portion of the Full Name, append .dll to it, then you'd be reproducing the same search that the .Net Fusion binder performs anyway).

Just a thought ;)