Skip to content

How to install and test nuget template packages locally

Developing my template pack for my Vertical Slice Architecture API template has been a fun and really rewarding project. What started out as simple little project of learning how to create project templates in .net core has turned into a minor successful project with a number of high profile users of the template and seemingly ever increasing number of new users downloading it daily.

I learned a whole heap from my side project and it’s helped in a number of ways. One of the things I learned is how to test your package locally, which strangely is not very well publicised and I only stumbled across the process while searching for something else entirely!

After a few months of exploring and using the Vertical Slice Architecture has incurred a number of tweaks and additional features required to the template pack, which when it was just me using the template was fairly easy to manage but now that there seems there are a number of organisations using it too, I have had to up my game of ensuring that anything that is released works and most importantly won’t break anything else.

As a one man development operation I have to rely on my own QA skills and processes! It has become vitally important that I continually test and dog food my updates before committing them to the repository.

Packaging a template for test

The dotnet new templating tool supports installing templates from nuget packages locally or from remote repositories. Multiple templates can be included in a single package, which allows adding and removing collections of templates from the internet with a single command.

To pack a nuget package for testing locally is actually a fairly trivial process of using the dotnet pack and defining a local folder you want your package to be located. Following the example of using my Threenine.ApiProject package, we can use the source code for the project as demonstration purposes.

We make use of the folder which we’ll exclude from a git repository we’ll name it .artifacts to do we can simply execute the dotnet pack with several arguments in the root of our project folder

dotnet pack ./src/Templates.csproj -o .artifacts --no-build

Once our package is built and ready to use, we can now simply install it using the dotnet new with the install switch -i and provide a path to the package in the .artifacts folder we want to install.

dotnet new -i .\artifacts\Threenine.ApiProject.1.0.0.nupkg

Points to remember

In this process the dotnet pack will take the version number you stipulate in the version tag of your Directory.Build.props so you will need to bump the version number there.

Typically I don’t tend to worry about managing the version number there, because I use gitversion in my Github actions to manage my package versioning so locally I don’t worry about the versioning.

Uninstall packages

You may want to uninstall you packages after completing your testing and dog fooding and to do so you can simply use the terminal command.

To find the package you want to delete you can simply list all your packages installed on your system.

dotnet new -l

Once you’ve found the short name of your project you can simply use this to uninstall using the switch -u

dotnet new -u apiproject

It is also possible to make use of the dotnet new -u to list all the packages that can be uninstalled

Conclusion

These steps are all pretty straight forward and trivial to do once you know how, but at least from my perspective they weren’t really that well publicised and I hadn’t found any supporting documents explaining it.