how to handle a common library in TFS & share dlls

Question

I have 2 different applications set up in tfs source control. Both share a common library, also set up in source control.

The current process for changes to the common library is build it, copy across the dll's to a location for the other applications to pull in and work with. This is manual and does not work well, especially now that I am moving to TFS CI Builds.

Layout like this in TFS:

-TFS
   - Web 1
      | Main
      | RB_1_0
   - Web 2
      | Main
      | RB_1_0
   - Shared
      | Main
      | RB_1_0
      | RB_2_0
      | RB_3_0

So I am looking to change this, automate it. But not sure how I can do such. As you can see there are multiple branches etc. As its a common library I was considering to set up like I work with nuget packages, where changes are pushed to my web 1 and/or web 2. I am not sure how easy it is to set this up.

Would be possible to review the above structure and give opinion on the best way to manage the distribution of the outputted dll's from common? In a CI environment? Is Nuget the best option?

Answer 1

NuGet is what I use for this.

Modify the build process to create new packages for the common package

Add an activity to build a nuget package, and another that copies it to a network share you use as a NuGet repository. There's a few projects floating around like Tfs NuGetter that can be used instead of manually editing the build template.

If you don't want to modify your build template then you could use a tool like [tfs deployer] and write a custom deployment script that creates NuGet packages instead. Or write something that hooks into the build complete event.

Enable Restore Packages on build for all solutions

This means you don't need to store the packages in source control, or deal with packages not downloading when you get latest on the solution.

When you want to update the version of the dependency open the solution and update it like any normal NuGet package.