Let’s say you have a solution with projects in it and some projects represents NuGet packages. I know it is not ideal, but the NuGet package project are really small and I didn’t want to create solution for each individual project. And also they are share some code. And I didn’t want to publish all the packages when I made changes to one project only not affecting the others
A good example is a solution with UI controls – each project representing a group of UI elements or a single element. Like set controls from a big controls vendor – I imagine the solution is quite big with projects like grid control, map control, charting, etc. By adding a NuGet package projects you can keep these distributed separately – one package for grid (ComponentVendor.UI.Grid), one package for maps (ComponentVendor.UI.Maps), etc. End-users do not have to download one big massive package (ComponentVendor.UI) which will make them to delete the unused references later.
The solution structure
UI SharedCode Maps Maps.NuGet (references Maps) Grid Grid.Nuget (references Grid) ...
The first step was to create a TeamCity project for the solution and build configurations for:
- root – build the entire solution (that’s why you set up the CI build) with VCS root pointing to source control root of the solution and with
UI.slnas build file
- all packages – manually triggered distribution all the packages at once
- each NuGet package project
Setting up the build configuration for NuGet package project:
- create new VCS root that points to the project source control directory to “isolate” this project from changes made in other projects
- add VCS root checkout rule:
+:.=>ProjectDirectory, this will checkout the sources into this directory
- set MSBuild build file to
- add build step to create NuGet package with
.csprojfile as specification file and
ProjectDirectoryas base directory
The build and publication of the package is triggered by changes made to package project, for example by changing the package version.