8

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 (that are under developing) while others are passive and hardly ever be rebuilt.

Common.dll is always under developing. There are several options how to keep my solutions code, what will you suggest and why?

A). Put common.dll source code to every solution. Pros: it will help active solutions to grow with common.dll side-by-side while passive solutions will be compilable. Cons: it's hard to synchronize active common.dll code between active solutions

B). Put common.dll binary code to every solution. Pros: all projects will be compilable while common.dll code will be centralized. Cons: it's hard to grow active solutions side-by-side with common.dll

C). Reference every project to last common.dll binaries looks like B. but it'll bring problems with passive solutions if common.dll will grow and change it's interfaces (some may say interfaces should always stay constant)

D). ?

Thank you in advance!

Andrew Florko
  • 7,672
  • 10
  • 60
  • 107
  • Do your solutions need to reference different versions of your common.dll? – Nick Jan 16 '12 at 11:15
  • 1
    Who knows. It will be easier to freeze passive solutions with exact version of common.dll then to keep all solutions up-to-date when common.dll changes. – Andrew Florko Jan 16 '12 at 11:18
  • 2
    I'd be looking at setting up your own company-side nuget feed http://docs.nuget.org/docs/creating-packages/hosting-your-own-nuget-feeds for this - it makes it significantly easier to manage satellite project reference requirements (in the package you can encode a max version as well as min version). We've just done this and it rocks. – Andras Zoltan Jan 16 '12 at 11:26

3 Answers3

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.

Community
  • 1
  • 1
vgru
  • 49,838
  • 16
  • 120
  • 201
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.

Lucero
  • 59,176
  • 9
  • 122
  • 152
1

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.

Community
  • 1
  • 1
Nick
  • 2,285
  • 2
  • 14
  • 26