Using configuration files to manage NuGet package versions (and other stuff!)
Tags: configuration, configurationmanage, netcore, softwareengineering
Published: 2018-10-11 22:43:44

---
title: Using configuration files to manage NuGet package versions (and other stuff!)
published: true
tags: configuration,configuration-manage,net-core,software-engineering
canonical_url: https://medium.com/@kritner/using-configuration-files-to-manage-nuget-package-versions-and-other-stuff-909f448369fd
---

![](https://cdn-images-1.medium.com/max/1024/1*YEroZmGevryq7HmzevaRWA.png)<figcaption>NuGet.org, microsoft search results</figcaption>

Have you ever had a LOT of projects in a solution, many of which use the same NuGet packages? Managing package versions could be a nightmare!

Working with .net core, this was very much what I was dealing with. It got quite tedious to manage NuGet package versions across 20+ projects, especially when .net core was pre 1.0 release, when you were having new packages available sometimes multiple times a day! How can one manage all these package version and keep them in sync?

For a while, I didn’t really know what to search for, and I think my issue was I was being too specific in my search terms.

The answer, at least one of them, lies in a solution wide variables file Directory.Build.props (documentation [here](https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build?view=vs-2017)). In this file you can specify things like variables, and other “pieces” that should be present in csproj files at and deeper than the directory where the Directory.Build.props file is contained. Additionally, this file works in an “inheritance” sort of manner in that “deeper” Directory.Build.props files are able to override properties set in “higher” files.

As far as the NuGet packages are concerned, here’s a sample demo…

Starting with a project with three “empty” class library projects:

![](https://cdn-images-1.medium.com/max/520/1*aLbbOOjL6uamWD8yotASPQ.png)<figcaption>Solution with 3 “empty” class library projects</figcaption>

Let’s bring in a NuGet package for demonstration purposes, and I’ll use Kritner.SolarProjection (more information [here](https://medium.com/@kritner/my-first-nuget-package-kritner-solarestimate-79d7f4abfdc2)) as the package brought in. The package can be added to all three projects via nuget package manager console, the gui, or by adding the following to the csproj files for ClassLibrary 1, 2, and 3:

```xml
<ItemGroup>
  <PackageReference Include="Kritner.SolarProjection" Version="1.0.0" />
</ItemGroup>
```

The solution should now look like:

![](https://cdn-images-1.medium.com/max/1024/1*LhQE-IHT2Bu6R7QLGHaRxw.png)<figcaption>The solution and NuGet package dependencies.</figcaption>

Now, pretend we have more projects we’re working with, and they all depend on Kritner.SolarProject. Additionally, imagine there are new versions of the package being released frequently — and we want to keep updated, because why not; our project has unit tests, integration tests, great asserts with awesome code coverage! We are set for updating our NuGet packages as they come out; at least minor revisions.

If we had more than 3 projects, say 20, that would mean updating the “1.0.0” version for Kritner.SolarProjection that many times, and hoping we don’t miss one! Directory.Build.props to the rescue!

I want to start referring to the “version” portion of Kritner.SolarProjection as a variable — NuGet-Kritner-SolarProjection.

Let’s create the Directory.Build.props file and do that:

{% gist https://gist.github.com/Kritner/511879ad29d3325e292e41db11006720 %}

And to plug it into our csproj files:

```xml
<ItemGroup>
  <PackageReference Include="Kritner.SolarProjection" Version="$(NuGet-Kritner-SolarProjection)" />
</ItemGroup>
```

Apply that same change to all 3 project files, rebuild, and voilà!

![](https://cdn-images-1.medium.com/max/1024/1*_HbrHMvcMlnFvx9ZKSqsaA.png)

Using the above makes keeping NuGet package versioning simple! There are other things you can do with this of course, but I’ll leave that perhaps for another day.

The code for this post can be found here: [https://github.com/Kritner-Blogs/DirectoryBuildProps/releases/tag/v1.0](https://github.com/Kritner-Blogs/DirectoryBuildProps/releases/tag/v1.0)

Related:

- Kritner Blog Post — [My First NuGet Package](https://medium.com/@kritner/my-first-nuget-package-kritner-solarestimate-79d7f4abfdc2)
- Microsoft — [Customize your Build](https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build?view=vs-2017)
- Kritner GitHub — [Blog post repo](https://github.com/Kritner-Blogs/DirectoryBuildProps/releases/tag/v1.0)