2

We need to find a sensible way to manage our in-house .NET libraries that could be potentially reused by multiple projects. Googling and thinking about the issue for a few hours led me to following conclusion which I'd like to go forward with:

There would be a separate job on our build server (Jenkins) for each version of each library we have. After the library gets successfully built, build output (most often, a .dll file) would then get copied to common network repository. A structure of this repository could be similar to this:

-libraryA
    -1.0
        -libraryA_1.0.dll
    -1.1
        -libraryA_1.1.dll
-libraryB
    -1.0
        -libraryB_1.0.dll

Each project that wants to use a library will come with a simple .bat file that would copy necessary libraries from this repository to folder specifically used for storing project dependencies. Then, dependencies will be referenced from this folder. An example project could look like this:

-project
    -src
    -dependencies
        -libraryB
            -1.0
                -libraryB_1.0.dll
    -getDependencies.bat

getDependencies.bat will always delete contents of dependencies folder and get fresh copy of libraries from the repository. It would be executed before each build of the project on Jenkins. dependencies folder will never get commited to SVN.

Some alternatives I've also considered:

  • Using custom NuGet feed instead of simple repository. I've discarded this because, as I've found out, it's quite a pain to use NuGet from Visual Studio 2008 that is still in use in our company. Otherwise, this would be my preferred solution.
  • Using svn:externals to resolve dependencies. I don't like this for two reasons:
    • Instead of dealing only with binary files (as in the solution outlined above), svn:externals forces me to deal with source code. I don't want to clutter each and every project that uses the library with its source code.
    • Somehow, managing dependencies by using SVN (which, in my opinion at least, should be used to manage versioning) does not feel right. I also think that svn:externals makes it hard to track dependencies of a particular project and makes the project too dependent on SVN.

I'd really appreciate if someone could point out any potential problems with my preferred solution or just anything you think is wrong with it. Also, if I am attempting to reinvent the wheel and there is already some standardized solution to this everybody is using (except alternatives I've mentioned), please do not hesitate to enlighten me :)

Thank you very much!

Nikola Anusev
  • 6,940
  • 1
  • 30
  • 46
  • You are wise to stay away from svn:externals. They might seem nice at first, but once you get dependent on them, then you are locked in to SVN, as no other source control system that I have found has an equivalent feature. At least nothing that works exactly the same. We use the externals approach at my current job, and it isn't great. – CodingWithSpike Mar 19 '12 at 16:36
  • Yeah, there was some talk about moving from SVN to git in our shop, so I would not like to get too dependent on SVN. – Nikola Anusev Mar 19 '12 at 20:18

1 Answers1

2

You only need separate versions of your libraries for breaking changes. Adding new features and fixing bugs does not warrant a new version. Also, the projects using the libraries should keep a copy of the binary they are using in their source repository.

This affords you the ability to change and modify your shared libraries without forcing changes into the individual projects, before they are ready for them. The projects can accept them at the rate they are ready for them, by getting the latest versions as they are ready and checking those new binaries into their source control once they are satisfied with the changes.

Charles Lambert
  • 5,042
  • 26
  • 47
  • You got me really thinking here. I've originally intended to increment minor version (1.0 -> 1.1) when feature gets added and increment revision (1.0.0 -> 1.0.1) when bug gets fixed. In folder 1.0 of each library, there would be always only newest revision available and with no referenced libraries committed in SVN, I thought that I will ensure that each project will always use the most bug-free version available. Now I have to admit your approach makes more sense. I will mark your answer if no one provides some better food for thought. Thank you! – Nikola Anusev Mar 19 '12 at 20:14