In my previous article article[^] I described how I resolved a dependency problem between two different projects using NuGet. An assembly that was created by one project was required as a dependency by a different project. I resolved the dependency problem using NuGet. The build of the donor project created and published a package that was consumed by the build of the recipient project.
Although this all worked absolutely perfectly, the only slight drawback was that my solution relied on a network share as the location where the packages were published. This didn’t seem very satisfactory. A better solution would be to publish the packages to an HTTP endpoint i.e. a web based package repository of some kind. The package repository needed to be private. The assemblies I needed to publish weren’t intended for general purpose use, but only intended to be used by the other members of the development team in our own applications. So a public NuGet repository wasn’t an option.
There are several ways of achieving this. Visual Studio Team Services (VSTS) package management, a private NuGet server or a third party package management service such as myget[^] all provide the ability to host your own private packages. The last option incurs costs (albeit fairly trivial costs unless you are scaling up), and we don’t currently use VSTS services. So that left a private NuGet server as the proposed solution.
This works by creating your own ASP.NET web application, which you then host on your internal network or cloud infrastructure. The key feature in creating this web application is that you must add the NuGet.Server package to it. This allows the web application to serve as a package manager. A full description of how to create this web application can be found here[^].
It didn’t take long before I had the web application up and running. The next step was to update both the donor build script (to publish the package to the newly created NuGet server), and the recipient build script (to install the package from the NuGet server).
There are two settings in the web.config file that are worth mentioning.
Hide Copy Code
<add key="requireApiKey" value="true"/>
- requiredApiKey — by default this is set to true. This means that you need to specify an API key when pushing / deleting packages. This ensures that only authorised applications (those you have entrusted with the private API key) can push and / or delete packages to your NuGet server. In our case, the NuGet server is hosted inside our firewall and only accessed by our build scripts. So we didn’t require this functionality. So I set this value to false accordingly.
Hide Copy Code
<add key="allowOverrideExistingPackageOnPush" value="false"/>
- allowOverrideExistingPackageOnPush — by default this is set to false, indicating that you cannot push the same package to the NuGet server more than once. I ran into this behaviour when testing that the builds were correctly publishing the package. I was manually queuing builds and so ran into this behaviour as I was getting an error when attempting to publish the same package to the NuGet server. I’ll probably reset it back to its default once it has been up and running for a while, but for now, it’s set to true while I’m still testing it out and manually queuing builds.
Publishing your assemblies to a NuGet server simplifies your DevOps process considerably. Each time the donor build is triggered, a new version of the package is created and published to the NuGet server. It is then up to the recipient build to determine which version of the assembly (or package) it wishes to consume. There is no automatic pull to use the latest package by the recipient build. This is a manual intervention under the control of DevOps.
When the recipient build is ready to use the new version of an assembly, it will do so in a development environment first to make sure there are no breaking changes, and to undertake sufficient regression testing. This is also where unit tests come into their own. If all your unit tests pass with the new package, then you can be fairly confident that everything works. The caveat being, your level of confidence is directly proportional to the quality of your unit tests.
The NuGet server works exactly as expected, and each build publishes / installs packages to and from the NuGet server perfectly. Yet again, the integration between the Team Foundation Server (TFS) 2015 build scripts and the private NuGet server is as tight as you would expect from Microsoft. They just work, and that’s all you can ask for.
If this article was helpful to you, please do hit the 💚 button below. Thanks!