Package Managers: Nuget

Why is packaging important?

When you purchase a product, the first thing that you notice is the packaging. What do you think when you first open a product with thoughtful packaging? For me, there’s an initial assumption of quality based on the care taken to prepare the item for consumers.

Similar assumptions can be drawn from well-packaged software. When a development team is tasked with maintaining, improving or recreating a solution, the first impression of that software is critical. Packaging is the first indicator of quality. If the team determines the code base to be of low quality, they may opt for a total rewrite instead of simple maintenance increasing costs in both the short and long term.

With any Sitecore solution, there are portable libraries that need to be included with the solution to facilitate environment setup. In several cases, I’ve seen development teams add those portable libraries into source control. Most of the time this is because the team is unaware of other options. This article discusses package managers and how your team can leverage these tools to create your own distributable packages.

Source control is designed for pre-compiled code. Adding compiled code to your repository creates bloat in your repo and makes versioning and upgrades very challenging. Package Managers solve this problem and others.

What is a package manager?

package manager keeps track of what software is installed on your computer, and allows you to easily install new software, upgrade software to newer versions, or remove software that you previously installed. As the name suggests, package managers deal with packages: collections of files that are bundled together and can be installed and removed as a group.

What is a package manager? (

There are a myriad of popular package managers that you use everyday: Nuget, NPM, Chocolatey to name some of the most common for dot net devs. When I mention Nuget, most developers are very familiar with the consumption of public packages posted on or public Sitecore packages at

Options for publishing and hosting your own packages depend on who you want to consume those packages. If you can open-source your code, hosting in a public feed like is an option. For others, their code is proprietary and should only be distributed amongst a small group. Private feeds accomplish this goal. Myget will host a private feed for you, but at a cost.

Most people aren’t aware that you can host your very own private packages directly within Azure DevOps using the Artifacts feature. I use these feeds to publish Sitecore support, TDS and Helix foundation modules for my teams. This feature is free if you have a Visual Studio subscription. I’m going to talk about Helix Modules in a later post, so for now I’m going to focus on the Sitecore Support use case.

One ‘perk’ of being a Sitecore certified developer is that I get access to the Sitecore support pipeline. When the support team determines that a patch is required, the Sitecore team will generally compile some code and zip the library up with some instructions for installation. I wish support could provide these libraries as part of a feed, but the overhead of maintaining that feed for each customer would become unmanageable pretty quickly.

Instead, I use a tool called Nuget Package Explorer to create a package with the necessary assemblies included and then publish to my Azure DevOps Artifacts feed. Let’s walk through those steps:

Create your Nuget Package

  • Install Nuget Package Explorer using Chocolatey
choco install nugetpackageexplorer
  • Download your files from Sitecore support
  • Unzip those files to a folder on your machine, i.e.
  • Open Nuget Package Explorer
  • Create a new package
  • Update the package metadata on the left-hand side by clicking on the icon with the card and the pencil. The key required attributes to update here are:
    • Id (i.e. Sitecore.Support.999999)
    • Version – This is very important. I’ve left the default here in the past, but the Sitecore version number would help developers understand whether the package applies to their solution.
  • Add content to your package by right-clicking on the ‘package contents’ pane and selecting ‘Add Lib Folder’
  • Right-click on the ‘lib’ folder and select ‘Add Existing File…’
  • Select your binaries
  • Save the package to disk. i.e.

Publish Your Package

  • Create your feed
  • Connect to your feed
  • Select Nuget.exe
  • Download a recent copy of nuget to a local folder. i.e.
  • If you don’t have a recent copy of Visual Studio on your machine, you can download and install the credential provider
  • Using the nuget cli, push your package to your feed with Powershell i.e.
c:\nuget\nuget.exe push -Source "My Nuget Feed" -ApiKey az "C:\nuget\localrepo\Sitecore.Support.999999.nupkg"
  • If prompted, enter your ADO credentials
  • With the publish complete, you can now add your feed url to Visual Studio or using your solution’s nuget.config
  • Browse for your package in Visual Studio
  • Install the package to any dependent projects


This does require a bit more time to setup, but it will save your team a ton of time when setting up their development, testing and production environments.

Now that I’ve explained the purpose of Package Managers and how to host and publish to your own private Nuget feed, the next post will discuss the Principles of Package Management and how those principles are applied to Sitecore Helix.

Leave a Reply