Release Notes

Version 7.0.0 of Cake has been released. Take it for a spin and give us feedback on our discussion board.

This release includes new features, improvements and bug fixes to Cake Scripting, Cake Frosting and Cake Sdk since the Cake v6.3.0 release! 🚀 🍰

Cake now fully supports running on .NET 11, and with this C# 15, which means you can take advantage of the latest framework, runtime, and language improvements (#4998, #4999). When running on .NET 11, Cake is also built with the new .NET 11 runtime async enabled (#5177).

Cake itself will no longer run on .NET 8 or .NET 9 (#4997), but Cake will continue to support building projects targeting .NET 9, .NET 8, older versions of .NET and .NET Framework.

The supported platform matrix for Cake 7.0.0 will look like this:

Cake.Template now defaults to net11.0.

As with every major release, we've taken the opportunity to clean things up. Most builds should just work, but these are the changes worth knowing about:

With Cake.Tool migrated from Autofac to Microsoft.Extensions.DependencyInjection (#2835), all three runners now share the same DI container, and the ServiceProvider alias that Cake.Sdk users already know is now available on ICakeContext everywhere.

That means services registered by a module loaded with the #module directive can be resolved straight from your script:

The very same module works with Cake Frosting, where you also get constructor injection into your tasks:

Cake.Sdk now also runs on the same BuildScriptHost as Cake .NET Tool (generator#208), so settings and behavior are identical regardless of runner. On the topic of consistency, Cake Frosting no longer exits with -1 for any kind of error; it now returns the CakeException.ExitCode (1 by default), just like the other runners (#3830, generator#207).

In Cake 6.2.0 we introduced an opt-in unified dependency graph when running multiple targets, so dependencies shared between targets only execute once. In Cake 7.0.0 this is now the default (#5060).

Above, a shared Build dependency will now execute once, not once per target. If you rely on the previous behavior, you can opt out via argument

or via cake.config

#tool directives install tools up front, before your build runs. With the new InstallTool / InstallTools aliases (#2471) you can install tools from within a task, only when that task actually executes. This works with all runners.

The DSL also received a few quality of life improvements:

Cake 7.0.0 comes with a bunch of new aliases:

Also new are DotNetDownloadPackage (#5103), DotNetNuGetWhy (#5109) and DotNetNuGetLocalsList / DotNetNuGetLocalsClear (#5112), together with new .NET 11 settings for DotNetRun (#5115), Microsoft Testing Platform settings for DotNetTest (#5119) and Framework for DotNetFormat (#5117).

DotNetPublish now supports publishing container images (#5159, #5173), either through the new Container settings or the convenience extension methods:

And as Cake.Sdk builds are regular .NET apps, you can publish your Cake build itself as a container, ready to run in any CI or container environment:

When Cake runs on .NET 11, ProcessSettings can opt in to the new .NET 11 process APIs on a per process basis (#5085), i.e. KillOnParentExit, StartDetached, RestrictInheritedHandles, DiscardStandardOutput and DiscardStandardError, and there's a new StartProcessAndForget alias returning the process id.

Regardless of .NET version, you can now also pass standard input to a process (#5125), as a string or bytes:

Building on the NuGetLogin trusted publishing support from Cake 6.3.0, Cake 7.0.0 adds AzureLogin (#5070), which exchanges a GitHub Actions OIDC token for an Azure access token. No Azure CLI and no client secret needed:

If you're using Azure.Identity, AzurePrepareWorkloadIdentity writes a federated token file that WorkloadIdentityCredential / DefaultAzureCredential picks up:

Your workflow needs the id-token: write permission for the token request to succeed.

Cake.Template has a new cakeci template (generator#255), which scaffolds a minimal CI pipeline running your Cake file-based build:

Supported providers are github, azuredevops, bitbucket, gitlab, appveyor, woodpecker, rwx and bitrise.

We've now set the recommended version of Cake.Core for addins to target to 7.0.0 (#5001).

This won't break the build, but you might see warnings like the one below when addins or modules are loaded.

The recommended target framework monikers for addins are now:

This release also includes a lot of smaller improvements and fixes: interpolated strings now correctly bind to the FormattableString log overloads (#5155, generator#258), using declarations on the first line are no longer hoisted as using alias directives (#5157), GetSpecialPath maps correctly on Unix (#5095), legacy .NET Framework / CoreCLR host code has been removed and internals modernized with frozen collections, GeneratedRegex and System.Text.Json, and the API docs now include Cake DSL examples (#5024, #5026, #5028, #5030).

This release was made possible thanks to the Cake team and the contribution of these awesome members of the Cake community listed below:

Full details of everything that was included in this release can be seen below.

Version 6.3.0 of Cake has been released. Take it for a spin and give us feedback on our discussion board.

This release includes new features, improvements and bug fixes to Cake Scripting, Cake Frosting and Cake Sdk since the Cake v6.2.0 release! 🚀 🍰

NuGet.org trusted publishing lets you exchange a GitHub Actions OIDC identity token for a short-lived API key, which means you no longer need to store a long-lived NUGET_API_KEY secret in your repository. Cake 6.3.0 adds NuGetLogin (#4945) so you can do that exchange from within your Cake script, without adding a separate login action step to your workflow and passing the key back into the build:

The OIDC token and the returned API key are automatically registered as secrets, so they're masked in the build log. Your workflow needs the id-token: write permission for the token request to succeed:

If you publish to a different feed, the GitHubNuGetLoginSettings overload lets you override the token service URL and OIDC audience:

Addins compiled with nullable reference types enabled used to produce CS8632 warnings ("the annotation for nullable reference types should only be used in code within a #nullable annotations context") because Cake generates the alias declarations above your script, in a compilation where annotations are disabled. Adding #nullable disable to your own script didn't help.

Cake 6.3.0 makes alias generation nullability-aware (#4977) rather than suppressing the warning:

The Cake.Sdk generator received the matching fix (#165), so nullable return types are retained in generated code and flow into your IDE's nullable analysis.

The task summary table styled both foreground and background colors, which assumed a dark terminal and made the report hard to read — in some cases unreadable — in light themes and terminals with a custom background (#4870). The report now only sets foreground colors and lets your terminal's own background show through, so it looks right regardless of theme.

Cake.Sdk scripts also got better exception reporting (#179). Generated code now registers handlers for unhandled and unobserved task exceptions during bootstrap, formats them with Spectre.Console instead of dumping a raw stack trace, and exits with a non-zero code on critical failures. Failures that previously crashed silently — or scrolled past as unreadable output — are now condensed into a readable report, and it works without any setup in your script.

This release was made possible thanks to the Cake team and the contribution of these awesome members of the Cake community listed below:

Full details of everything that was included in this release can be seen below.

Version 6.2.0 of Cake has been released. Take it for a spin and give us feedback on our discussion board.

This release includes new features, improvements, and bug fixes to Cake Scripting, Cake Frosting, and Cake.Sdk since the Cake v6.1.0 release! 🚀 🍰

Cake now includes an RWX build provider (#4840), alongside GitHub Actions, GitLab CI, Azure Pipelines, and the other supported systems listed under build system integrations. Documentation is available on the RWX integration page. When your build runs on RWX, scripts get the same IsLocalBuild / provider detection pattern you already use elsewhere—for example:

See IRwxProvider for run, task, git, and runtime metadata, plus BuildSystem.Rwx.Commands for output values and artifacts.

Below is an example of an RWX YAML configuration that runs on Ubuntu 26.04, checks out your code, installs the .NET SDK using global.json, and then shows the three ways to invoke Cake on CI—Cake.Sdk file script, Cake .NET Tool, and Cake Frosting. See Running Cake on RWX for more examples.

For a single runner in your own repo, keep only the dotnet commands you need.

Cake.Tool and Cake.Sdk integration tests and pull requests now build continuously on RWX as well. Thank you to RWX for sponsoring the project with a build instance.

This release was made possible thanks to the Cake team and the contribution of these awesome members of the Cake community listed below:

Full details of everything that was included in this release can be seen below.

Version 6.1.0 of Cake has been released. Take it for a spin and give us feedback on our discussion board.

This release includes new features, improvements, and bug fixes to both Cake Scripting, Cake Frosting, and Cake Sdk since the Cake v6.0.0 release! 🚀 🍰

Update: Cake.Sdk 6.1.1 has been released to address a dependency issue. If you use Cake.Sdk, we recommend updating to 6.1.1.

You can now pass interpolated strings directly to the logging aliases, so formatting is clear, and the cost of building the message is only paid when the log level is active.

Using a FormattableString (interpolated string):

Using FormattableLogAction for lazy evaluation (the message is only formatted if the current verbosity allows it):

All of Error, Warning, Information, Verbose, and Debug support both overloads.

Cake.Sdk now goes beyond .NET tools: you can install and run any NuGet package with #tool / InstallTool, just like Cake.Tool already does. That makes it easy to pull in platform-specific packages (e.g. Bicep CLI) and invoke them with Command or the tool aliases.

Example: installing the Bicep CLI for the current OS and architecture, then running it:

This release was made possible thanks to the Cake team and the contribution of these awesome members of the Cake community listed below:

Full details of everything that was included in this release can be seen below.

Version 6.0.0 of Cake has been released. Take it for a spin and give us feedback on our discussion board.

This release includes new features, improvements and bug fixes to Cake Scripting, Cake Frosting, and the new Cake.Sdk runner since the Cake v5.1.0 release! 🚀 🍰

Cake now fully supports running on .NET 10, and with this C# 14, which means you can take advantage of the latest framework, runtime, and language improvements.

The supported platform matrix for Cake 6.0.0 will look like this:

We're excited to announce Cake.Sdk as a new official runner for Cake! Cake.Sdk provides a modern way to get the Cake tool scripting experience in regular .NET console applications. This brings you the stellar experience of the new "dotnet run app.cs" feature (requires .NET 10), while also working seamlessly with .NET 8 and 9 for regular csproj projects.

Here's the minimal example:

Cake.Sdk is a custom SDK that provides a convenient way to create Cake projects with minimal configuration. It automatically sets up common properties and provides a streamlined development experience for Cake-based build automation projects, whether you're using the new file-based approach or traditional project-based builds.

Key features include:

The easiest way to get started with Cake.Sdk is using the Cake.Template package, which provides several templates for different scenarios:

First, install the template package:

Create a new Cake file-based project:

For the simplest possible setup, you can use the minimal template:

For larger projects, you can organize your code across multiple files:

For traditional project-based approach:

We've now set the recommended version of Cake.Core for addins to target to 6.0.0.

This won't break the build, but you might see warnings like the one below when addins or modules are loaded.

The recommended target framework monikers for addins are now:

This release was made possible thanks to the Cake team and the contribution of these awesome members of the Cake community listed below:

Full details of everything that was included in this release can be seen below.