Project references v NuGet dependencies

Question

I am in the process of introducing NuGet into our software dev process, both for external binaries (eg Moq, NUnit) and for internal library projects containing shared functionality.

TeamCity is producing NuGet packages from our internal library projects, and publishing them to a local repository. My modified solution files use the local repository for accessing the NuGet packages.

Consider the following source code solutions:

1. Company.Interfaces.sln builds Company.Interfaces.1.2.3.7654.nupkg.
2. Company.Common.sln contains a reference to Company.Interfaces via its NuGet package, and builds Company.Common.1.1.1.7655.nupkg, with Company.Interfaces.1.2.3.7654 included as a dependency.
3. The Company.DataAccess.sln uses the Company.Common nupkg to add Company.Interfaces and Company.Common as references. It builds Company.DataAccess.1.0.8.7660.nupkg, including Company.Common.1.1.1.7655 as a dependent component.
4. Company.Product.A is a website solution that contains references to all three library projects (added by selecting the Company.DataAccess NuGet package).

Questions:

If there is a source code change to Company.Interfaces, do I always need to renumber and rebuild the intermediate packages (Company.Common and Company.DataAccess) and update the packages in Company.Product.A?

Or does that depend on whether the source code change was

• a bug fix, or
• a new feature, or
• a breaking change?

In reality, I have 8 levels of dependent library packages. Is there tooling support for updating an entire tree of packages, should that be necessary?

I know about Semantic Versioning.

We are using VS2012, C#4.0, TeamCity 7.1.5.

Answer 1

It is a good idea to update everything on each check-in, in order to test it early.

What you're describing can be easily managed using artifact dependencies (http://confluence.jetbrains.com/display/TCD7/Artifact+Dependencies) and "Finish Build" build triggers (or even solely "Nuget Dependency Trigger").

Answer 2

We wrote our own build configuration on the base project (would be Company.Interfaces.sln in this case) which builds and updates the whole tree in one go. It checks in updated packages.config files and .nuspec files along the way. I can't say how much of a time-saver this ended up being for us, even if it might sound like overkill at the beginning.

One thing to watch out for: the script we wrote checks in the files even if the chain fails somewhere in between, to give us the chance of fixing it on our local machine, check in the fix and restart the publishing.