Developing my API 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 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
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
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.
- What is this Directory.Packages.props file all about? - January 25, 2024
- How to add Tailwind CSS to Blazor website - November 20, 2023
- How to deploy a Blazor site to Netlify - November 17, 2023