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