Reputation: 44605
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?
Upvotes: 7
Views: 2082
Reputation: 9189
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.
Upvotes: 9