Frequently asked questions

Why do I see the warning “Solution foo.sln is missing an active build configuration for build.csproj”?

• Using NukeExt requires restoring a NuGet package, which Visual Studio and dotnet won’t do unless the build.csproj is configured for building. We could simply restore the build.csproj to avoid this, but it’s still a poor user experience in Visual Studio, so instead we require enabling it in the .sln.

Why are the Nuke scripts failing to run NuGet restore due to “error: NU1301: Unable to load the service index”?

• This error may occur if dotnet is unable to authenticate to a private NuGet feed. To resolve this:

1. Install the Azure Artifacts Credential Provider.
   • From PowerShell, run iex "& { $(irm https://aka.ms/install-artifacts-credprovider.ps1) }"
2. Run dotnet restore --interactive, or if you’re using our global tools, dotnet tool update -g Microsoft.XboxStudios.NukeTool --version {insert version number here} --interactive
   • You may also need the --verbosity minimal flag due to an upstream .NET bug.
   • Consider copying the build.sh and build.ps1 scripts from NukeExt which include these fixes.

How do I setup Nuke in a different place than the root folder of my Git repository?

• By default the Nuke-generated Azure pipelines build assumes the build.cmd script is in the root folder. In case you want to move the Nuke build to a different folder or have multiple builds in one Git repo, you can use a feature specific to NukeExt to set the NukeBuildDirectory.

How do I integrate Git versioning into my build?

• There are two easy ways to use Nerdbank.GitVersioning with Nuke:

  1. As suggested in the official docs, add a PackageReference to your C# project.
  2. In Nuke’s parameters.json, set the AddGitVersioning property to true

• The tradeoff is generally that option 1 has a greater feature-set, such as the ThisAssembly variable, while option 2 is simpler and more reliable. Option 1 works in Visual Studio, but its more complex NuGet package integration has caused issues in our Azure DevOps pipelines.

How do I publish multiple target frameworks, for example net472 and net8.0?

• NUKE supports this out-of-the-box using CombineWith to repeat a target multiple times. For example with cmd:

  sqtech-build.exe --publish-frameworks net8.0 net472

  or PowerShell:

  sqtech-build.exe --publish-frameworks @("net8.0", "net472")

How can I verify my build publishes specific files or patterns of files?

• When you’re signing your build artifacts, and expecting specific files to be included, NukeExt can check that with its ValidatePublishOutput option. For example in parameters.json, this will validate the artifacts/bin/NukeTool and NukeTool.DocFX folders each contain DLL files with any name and also one specific EXE file. Note that only DLL and EXE files are checked, and for greater security you should also enumerate the expected DLL files or file patterns.

      "ValidatePublishOutput": [
          "NukeTool: *.dll, NukeTool.exe",
          "NukeTool.DocFX: *.dll NukeTool.DocFX.exe"
      ]