managing and versioning common libraries across projects

Question

We have quite a few solution in our company. most of them are using a set of common libraries for different functions, (logging, caching, data-access).

the question I have is how would you make sure that they are managed properly?

Reference the tracing project directly from windows app1

Pros:You don't have to merge and branch.

Cons:You could introduce issues in systems when you recompile the code. since now its being compiled with the latest version.

Branch off tracing for each project and merge them every once in a while pros and cons are the exact opposite of the fist option.

I might be completely off on the ideas, but I'm sure there has to be a better way.

Answer 1

What we do here is just keep constantly updating and improving our common library and then when we get to a point that we're comfortable with it and it needs to be used in an application, we up the major or minor version depending on the number of changes, build an installer for it, and label it in source control.

We handle old applications by simply upgrading them to the latest version when we need to make changes to that application.

I build an SDK and Redistributable installer for the common library. The SDK goes to all the developers and includes source code, templates, documentation, puts the DLLs on their drive, and also puts the DLLs in their GAC. The Redistributable simply puts the DLLs in the GAC. We install the redistributable on the servers.

We are soon going to go to a method where we don't produce a redistributable. We will only produce an SDK, and in that SDK will be a merge module for the common library. When a developer uses the library and is ready to move their app to production, they will build an installer for it and include the merge module in that installer, that way the deployment for the application always has the right version of the common library and we don't have to worry about installing it on the servers first.

I don't know anything about your environment, so I don't know how these techniques would work for you, but it's working pretty well for us right now.

Answer 2

One important distinction to make is whether it matters if two child projects on a server are running different versions of the "shared" code. Libraries, you're probably OK. Shared services? Probably not. If the latter, then branching becomes much more of a problem because it's easy for everyone to get out of sync. If you can afford to run different versions side-by-side, then I'd go for the branching method because it gives each project/area more control over when to accept changes.

One option you didn't mention is to store the binaries for your common projects in source control, and use binary references. This has similar properties to your second option (branching). You will have fewer issues than with a direct project reference, because only known-good (or at the very least compilable) versions are availiable. One downside of this is that editing the shared projects in parallel with something using it can be a bit painful.

This will also help keep the clutter out of your larger solutions.

You can also do some clever things with this setup, such as set up a CI build on your shared projects with a custom post-build task to check in the new binaries.