How should I use Nuget for internal enterprise development?

Question

We use Nuget for our internal development to allow us to share code across teams. We run into issues however when one person is working on code that will be deployed across multiple nuget packages at the same time. For instance

A depends on B which depends on C.

A, B and C have their artifacts pushed to Nuget and that's how we manage the dependencies between A, B and C. The trouble we find is that if a developer wants to make changes in C and quickly see those changes reflected in A, they have to go through the following process.

1. Make change in C.
2. Push change up to git
3. CI picks up change to C and builds and deploys new nuget package.
4. Go into B and update reference to C using a nuget update package command.
5. Push up the change to the packages.config file up to git
6. CI picks up change to B and builds and deploys new nuget package for B
7. Now open A and change reference to B and nuget update package
8. Make changes in A to go along with the changes in B(and transitively C)

This seems extremely painful and is causing some of our developers to question the choice of Nuget for our internally developed code. Everyone still like it for consuming external packages.

Is there any better workflow for using Nuget internally?

Answer 1

In our company we have solved the cascading updates problem with the following setup. First we have the following setup for our NuGet repositories and build server.

• There is an internal NuGet repository that holds all the published packages for the company. This repository is just a shared directory on one of our servers.

• Each developer can have (but doesn't need to have) one or more directories on their own machine that serves as a local NuGet package repository. By using a user specific NuGet configuration the developer can control in which order NuGet searches through the package repositories to find packages.

  <?xml version="1.0" encoding="utf-8"?> <configuration>   <packageRestore>     <add key="enabled" value="True" />   </packageRestore>   <packageSources>     <add key="Dev" value="D:\dev\testpackages" />     <add key="Company" value="<UNC_ADDRESS_COMPANY_REPOSITORY>" />     <add key="NuGet official package source" value="https://nuget.org/api/v2/" />   </packageSources>   <disabledPackageSources />   <activePackageSource>     <add key="All" value="(Aggregate source)" />   </activePackageSource> </configuration> 

• All solutions have automatic package restore turned on, so that we don't have to commit the packages to our version control system.

• Developers only control 3 out of the 4 version numbers, e.g. if the version is <MAJOR>.<MINOR>.<BUILD>.<REVISION> then developers can only change the major, minor and build numbers, the revision number is set to 0 except in builds done by the build server where it is the build number of the build. This is important because it means that for a given version consisting of a major, minor and build number the build server will always produce the higher version number. This again means that NuGet will prefer to take the package version coming from the company package repository (which only gets packages through the build server).

In order to make a change to one of the base libraries there are two possible processes being used. The first process is:

1. Make the changes to the base library (A). Update the version of (A) if needed.
2. Run the MsBuild script to build the binaries and create the NuGet packages of (A)
3. Copy the new NuGet packages over to the package repository on the local machine
4. In the dependent project (B) upgrade to the new packages of (A) that were just placed in the local machine package repository (which should be of a higher version than the ones available on the company wide repository, or NuGet.org)
5. Make the changes to (B).

If more changes are required to (A) then repeat steps 1,2 and 3 and then delete the package of (A) from the working directory of (B). Next time the build runs NuGet will go looking for the specific version of (A), find it in the local machine repository and pull it back in. Note that the NuGet cache may thwart this process some of the time, although it looks like NuGet may not cache packages that come from the same machine(?).

Once the changes are complete, then we:

1. Commit the changes to (A). The build server will run the integration build to verify everything works.
2. Tell the build server to run the release build, which builds the binaries and pushes the NuGet packages to the company-wide NuGet repository.
3. In (B), upgrade to the latest version of (A) (which should have a higher version number than the test package because the test package should have version a.b.c.0 while the newly build version in the company-wide repository should be a.b.c. where > 0
4. Commit the changes to (B). Wait for the build server to finish the integration tests
5. Tell the build server to run the release build for (B).

Another way of doing the development work is by taking the following steps

1. Make the changes to the base library (A). Update the version of (A) if required.
2. Build the binaries
3. Copy the binaries over to the location where NuGet unpacks the package of (A) for project (B) (e.g. c:\mysource\projectB\packages\ProjectA.1.2.3.4)
4. Make the required changes to project (B)

The commit process is still the same, project (A) needs to be committed first, and in project (B) the NuGet reference to (A) needs to be upgraded.

The first approach is slightly neater because this process also warns if there are faults in the NuGet package of (A) (e.g. forgotten to add a new assembly) while in the second process the developer won't know until after the package for (A) has been published.