I learned a whole heap from my little 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 for me using the template and exploring new approaches ways of developing an API, was fairly easy to manage but now that there seems there are a number of organisations using it too, therefore 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 create 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
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.
Gary is Technical Director at threenine.co.uk, an independent software vendor specialising in IoT, Field Service and associated managed services,enabling customers to be efficient, productive, secure and scale-able.
