In order to setup a repository with NUKE, the global tool
Nuke.GlobalTool must be installed:
$ dotnet tool install Nuke.GlobalTool --global You can invoke the tool using the following command: nuke Tool 'nuke.globaltool' (version '0.10.0') was successfully installed.
When using ZSH as a shell, the dotnet tools path
$HOME/.dotnet/tools must be added manually (see dotnet/cli#9321). This can be achieved by adding
export PATH=$HOME/.dotnet/tools:$PATH to the
Afterwards, the setup can be invoked with
By default, NUKE will search for the next VCS directory (
.svn) and consider it the root directory for our build. If we want to change that behavior
By default, NUKE will use the .NET Core SDK as bootstrapping method. Passing the
--boot parameter, will reveal .NET Framework/Mono as another option. Note that even with .NET Core SDK bootstrapping, the build will be able to compile projects targeting .NET Framework. For further comparison, the template scripts build.netcore.ps1/build.netcore.sh and build.netfx.ps1/build.netfx.sh can be checked.
When the setup has finished, the applied changes can be checked (e.g.
git status -s -uall):
||Root directory marker file; references default solution file|
||Build project file (console application)|
||Bootstrapping for Windows/PowerShell|
||Bootstrapping for Unix/Bash|
||Roslyn code formatting settings|
||ReSharper code formatting settings|
|Changed solution file||Include build project if chosen|
When using the .NET Core SDK bootstrapping, there is a possibility to remove the bootstrapping files
build.sh. In that case,
dotnet run can be called directly on the build project file. However, having the bootstrapping files in place ensures the availability of the dotnet CLI. If no local installation exists, it will be downloaded. Also this approach takes the
global.json file into account, which allows to define the SDK version.
For maximum readability, NUKE prefers certain code formatting settings. For example, these include to omit accessibility modifiers and use expression-bodied properties. In case the build project should look like any other project, the two files
.dotsettings may simply be removed.
The setup can be continued with an extended wizard, which helps to scaffold the initial
Build class according to best practices. For instance, it suggests to use GitVersion for generation of version numbers and provides a default implementation for the