Is this a good approach for managing common libraries?

Question

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!

Answer 1

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.