It would be great to have better dotnet tool integration, especially now that we have local tools in .NET Core 3.0. I've been pondering what a minimal Cake build could look like. My BoardGameGeek.Dungeon repo can serve as the use case.

Current Cake related files:

• cake.ps1 bootstraps Cake on Windows
• cake.sh bootstraps Cake on Linux
• tools/packages.config locks Cake version

For Azure Pipelines and GitHub Actions builds I avoid the Cake bootstrap by using a Docker image with the Cake tool already installed. However, all builds still have to bootstrap Cake modules in order to use dotnet tools in the Cake build itself, one of the most common being GitVersion.

BoardGameGeek.Dungeon is built using Cake.Dungeon, and in the depths lives the bootstrap.cake script with the following:

#module nuget:?package=Cake.DotNetTool.Module&version=0.4.0
...
#tool dotnet:?package=GitVersion.Tool&version=5.1.2

This is the first barrier to diet Cake nirvana as it requires Cake to be invoked twice, first to install the Cake.DotNetTool.Module to extend Cake to support #tool, then again for the actual build, using something like the following:

cake --bootstrap && cake

Not too bad, although more verbose in PowerShell until v7 drops next year with long overdue support for pipeline chain operators, but really it's surely about time this module moved into Cake core, and when it does we'll want it to play nice with dotnet local tools. (The two step bootstrap will still be required if you're using other Cake modules, but I'd argue that's much less common, and using dotnet [local] tools is standard now, especially if writing cross-platform builds.)

Anyway, given support for dotnet local tools, I would be able to delete the above Cake related files and replace them with a single dotnet-tools.json manifest file:

{
  "version": 1,
  "isRoot": true,
  "tools": {
    "cake.tool": {
      "version": "0.36.0",
      "commands": [
        "dotnet-cake"
      ]
    }
  }
}

Then to invoke the build on a clean machine I'd use the following:

dotnet tool restore && dotnet cake --bootstrap && dotnet cake

... or when the dotnet tool module is moved to Cake core:

dotnet tool restore && dotnet cake

... and when the Cake dotnet tool is already installed (on a local dev machine):

dotnet cake

Also, for this to integrate better with dotnet local tools, the #tool directive should use the local tool directly, presumably invoking dotnet <tool>, rather than extracting and copying what was previously a global tool into the Cake tools directory alongside addins and modules. (I'm hoping such a change would also avoid the quirk resulting from building the same directory in Windows and then WSL or Docker with a host mount, or vice versa, where you first need to explicitly delete any such copied dotnet tools which would be for the wrong platform.)

So in summary, a minimal Cake build would simply leverage dotnet local tools to bootstrap Cake itself, and given the dotnet tool module was moved to Cake core, a common case requiring an extra module bootstrap step could most likely be avoided, and the #tool directive would use the dotnet local tool directly, rather than copying a platform specific executable into its own tools directory.