Use boilerplate solution with “dotnet new” and stay DRY
In this article I want to share a small technique which saves time on repetitive tasks of creating similar projects. In my project there are multiple types of projects: CLI tool, a microservice, a data pipeline, a job. A programming language might be any, but we’re using often C# and Siddhi. Every time I create a project I’m doing the same things. For example, in case of C# microservice, I’m adding the same configuration of Serilog, same internal NuGet packages, same shared configurations and so on. This eats a lot of time which I could have spent instead on creating real value to the project. I’m repeating again and again the same operations. In software development this is the devil which we call “a waste” and trying to fight it. In contrast, if you go too far in this fight you may meet another devil which we call “an automation” which becomes a sophisticated system on its own.
If you haven’t heard, DRY stands for “Don’t Repeat Yourself”. Basically, the boilerplate tool should be easy to learn, maintain, distribute and it should be easy to contribute by teammates. If you try to build a tool which offers such features you might get to the point when the solution becomes too sophisticated. I tried to build one using the PowerShell module. The solution was similar to what you can see if you look at Chocolatey (a package management for Windows). In the end the development started to eat too much of my time and was abandoned because it wasn’t the goal.
Problems which it supposed to solve are as follows:
- create template projects with predefined setup and structure
- support any programming language
- offer a simple way to create new custom templates and distribute them
- installation on local machine should be very easy
- support of templates customization during creation
There is a tool which is developed by .NET community which supports almost everything from my list above. It’s
dotnet new. If you’re .NET developer, you already have this tool installed since it’s a part of .NET Core SDK. If you’re not, you may be interested in having a glance at it, because as I noticed it can be used with any languages since it operates with files. If you’re a front-end developer you might have experience with React boilerplate tools or similar. In contrast
dotnet new doesn’t stick you to .NET framework. You can use it for, basically, creating a folder with predefined files, structure and replace text in files, execute post actions. It shouldn’t be only C#. And you can create your templates almost “in the blink of an eye”.
The easiest way
The easiest way to get it to work for you is not the best way. But it’s very quick and you can start sharing templates in your team. You need to create a Git repository with a template solution. This solution should be correct according to the programming language of your choice. For example, for C# you should be able to compile it. Now you need to add a definition of the template:
.template.config and a file
template.config . The file will contain the definition and here is the example of it:
"name": "Description of the template",
This is it. Now you can clone the repo on the machine where you’d like to install the template and run:
dotnet new -i <absoluteOrRelativePath>
absoluteOrRelativePath should be a canonical path to the folder with the template. Now you can use it. Create or go to a folder where you’d like to create a new project from the template and run this:
dotnet new shortNameOfTemplate
It will create the project which you’ve defined in the current folder. If you’d specify parameter
--projectName MyNewProject it will replace any occurrence in files of
TemplateAppSample to your new name.
Moreover, you can define and install multiple templates. If your templates are defined under some parent folder, the
absoluteOrRelativePath should point to it and
dotnet new will find all templates in sub-folders and install them.
The advanced way
You can create a template pack and distribute it via NuGet package. The package could be deployed to your private NuGet server. The installation in such a case would be as easy as follows:
dotnet new -i MyTemplatePack::1.0.0 --nuget-source http://MyPrivateNuGetServer/v3/index.json
You need to specify the NuGet source if you’re using a private one. At the moment of writing this article
dotnet new cannot use sources which you registered with
dotnet nuget .
Browsing, Updating and Uninstalling of Templates
You can check installed templates by running the command
dotnet new --list . It will show you the following output:
It’s interesting to note that the field
Tags represents the information which you specified in the property
classifications of your template definition.
You can get more information about template options by running the command
dotnet new shortNameOfTemplate --help .
The uninstallation of templates is not very user friendly at the moment of writing this article. While you can use relative paths to install templates, you need to use absolute paths to uninstall templates. When you use the NuGet package to install templates, you need to use just the name of the NuGet package without version.
dotnet new -u <absolutePath>
dotnet new -u MyTemplatePack