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:

dotnet new

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:


A folder .template.config and a file template.config . The file will contain the definition and here is the example of it:

"$schema": "",
"author": "Me",
"classifications": [
"identity": "shortNameOfTemplate",
"name": "Description of the template",
"shortName": "shortNameOfTemplate",
"tags": {
"language": "C#",
"type": "project"
"symbols": {
"projectName": {
"type": "parameter",
"datatype": "text",
"replaces": "TemplateAppSample",
"defaultValue": "TemplateAppSample"

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>

The 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


All opinions are my own || Software Developer, learner, perfectionist and entrepreneur-kind person, nonconformist. Always seeks for the order and completeness.