Best practice to share common libraries between solutions in .NET

Question

We have pool of MSVS solutions (Solution \"A\", \"B\", \"C\", ... ) that share basic functionality in assembly called \"Common.dll\".

There are 3-5 active solutions (th

Answer 1

We practice something mostly like B.

A CI server makes sure that the common libraries are always up-to-date (even if they use other common libraries themselfes). Each solution which uses common libraries has a "Lib" folder where we put the build artefacts, but these are not under source control (in contrast to external artefacts, such as the ones imported though NuGet).

So while developing you don't get problems because of breaking changes in the common libs and the developer chooses the point in time when he upgrades (but he always has to do that before he commits to the central repo).

The CI server will always copy the latest common libraries into the "Lib" of the solution under build, so that the latest common libraries are integrated. If we need to create a build with old libraries (specific hotfix release - very rare), we can always use the build artefacts with the matching date. Normal patch/fix releases are usually also upgraded to the latest common libraries though.

Answer 2

There are other options, also:

D) Put all projects inside the same SVN (or other CVS) root.

This allows branching and tagging while making sure you have a consistent version of Common branched with every project. This way you simply include the project in each solution as needed.

The problem is, of course, that all projects are inside the same SVN. :)

What's good about it is that you are sure to get a snapshot of your Common.dll's source code in every branch you create.

E) Use SVN Externals

If you're using Subversion, you can use SVN Externals (mapping a local subfolder to a url of a versioned resource). GIT supports something similar too, but it's a bit complicated if you want to submit changes to the external repos.

Answer 3

I'd say discount (A) straight away, as you will kill any capability you have for maintainability!

Effectively, it does come down to how often these code bases will change.

Our curent solution on a similar setup I'm working on is to have a seperate 'Common' project, and the binaries are copied to the 'Libs' folder for each Project that references the Common one. The reason for this is that we then have the capability to deploy explicit versions of common.dll to each project. The Libs folder is maintained via TFS. So whilst the parent project does not need to be recompiled, TFS will see a new check in and can act accordingly.

Your other option which I'd consider is to reference the common project 'in situ' as per one of the solutions at this link. Note though that this limits your ability to reference different versions of common unless you are creating seperate project versions for each physical version, which would be unlikely and unadvisable, again due to maintainability.