- name: dotnet-cake
- description: Cake (C# Make) is a cross-platform build automation system with a C# DSL for tasks such as compiling code, copying files and folders, running unit tests, compressing files and building NuGet packages. This snap exposes the Cake .NET tool as the dotnet-cake command, matching the upstream tool command name.
- snapcraft: https://github.com/canonical/dotnet-cake-snap/blob/main/snap/local/template.snapcraft.yaml (Note: the actual snapcraft.yaml is generated from this template by the Makefile, which fills in the version, grade, confinement and branch placeholders at build time.)
- upstream: GitHub - cake-build/cake: 🍰 Cake (C# Make) is a cross platform build automation system. · GitHub
- upstream-relation: Packaging publisher. This snap is maintained by Canonical to distribute the upstream Cake tool; we are not the upstream authors but package and distribute it.
- supported-category: programming languages, Cake is a build automation tool that executes C# build scripts (a C# build DSL), directly analogous to cmake, make and other build tooling already published as classic. It also fits under “tools for local, non-root user driven configuration of/switching to development workspaces/environments”.
- reasoning: Cake is a build automation tool, not a sandboxed end-user application. As a build orchestrator it must:
- Read and write source code, build artifacts, and output files at arbitrary paths across the user’s filesystem (project trees, output directories, temp locations), which strict confinement’s home interface cannot cover since projects and toolchains commonly live outside $HOME (e.g. tmp, opt, mounted volumes, CI workspaces).
- Execute arbitrary external commands and toolchains referenced from build.cake scripts, compilers, dotnet, test runners, package managers, shell tools, and user-defined executables installed anywhere on the host. There is no interface that grants execution of arbitrary host binaries under strict confinement.
- Spawn child processes that themselves require unrestricted filesystem and execution access to perform the build.
The core problem: Cake is not self-contained. A build.cake script routinely invokes external host toolchains that are not (and cannot be) bundled inside the snap. For example:
DotNetBuild("./src/MyProject.csproj"); // requires the host .NET SDK
StartProcess("git", ...); // requires the host git
StartProcess("npm", ...); // requires the host npm / Node
Under strict confinement a snap cannot execute arbitrary host binaries, it can only run what is packaged inside the snap, and there is no supported interface to grant execution of arbitrary system executables. This breaks Cake’s central purpose as a general-purpose build orchestrator: the vast majority of real-world build.cake scripts would fail because they depend on host-installed tools.
These are the same reasons that other build tools such as CMake are published as classic. The available interfaces (home, removable-media, etc.) do not provide access to arbitrary system paths nor the ability to invoke arbitrary host toolchains, both of which are fundamental to Cake’s core functionality.
I understand that strict confinement is generally preferred over classic.
I’ve tried the existing interfaces to make the snap to work under strict confinement.
(Not sure how to tick both above, but I ticked both)