Description
Starting in .NET 11, SDK container publishing to a local container runtime automatically prefers the platform-native CLI when available: wslc on Windows and container on macOS. This changes which local runtime receives the image when Docker or Podman is also installed.
Related implementation: dotnet/sdk#55249
Tracking issues: dotnet/sdk-container-builds#651 and dotnet/sdk-container-builds#636
Version
.NET 11 Preview 7
Previous behavior
When LocalRegistry was not explicitly set, the SDK probed Docker and Podman and loaded the published image into the selected Docker/Podman runtime.
New behavior
On Windows, the SDK first probes wslc; on macOS, it first probes Apple's container CLI. If the platform-native tool is available and its service is running, the SDK loads the published image there. Docker and Podman remain fallbacks. Users can explicitly select Docker, Podman, Wslc, or Container through the LocalRegistry MSBuild property.
Type of breaking change
Reason for change
Windows and macOS now provide platform-native container tooling. Preferring those tools gives users the native platform experience while preserving Docker and Podman fallback behavior.
Recommended action
If automatic selection is acceptable, no action is required. To keep using a specific runtime, set the LocalRegistry MSBuild property explicitly, for example -p:LocalRegistry=Docker or -p:LocalRegistry=Podman. Use Wslc or Container to explicitly select the platform-native Windows or macOS runtime.
Feature area
Containers; SDK
Affected APIs
No APIs are removed. Microsoft.NET.Build.Containers.KnownLocalRegistryTypes adds the Wslc and Container constants, and local runtime auto-detection behavior changes.
Description
Starting in .NET 11, SDK container publishing to a local container runtime automatically prefers the platform-native CLI when available:
wslcon Windows andcontaineron macOS. This changes which local runtime receives the image when Docker or Podman is also installed.Related implementation: dotnet/sdk#55249
Tracking issues: dotnet/sdk-container-builds#651 and dotnet/sdk-container-builds#636
Version
.NET 11 Preview 7
Previous behavior
When
LocalRegistrywas not explicitly set, the SDK probed Docker and Podman and loaded the published image into the selected Docker/Podman runtime.New behavior
On Windows, the SDK first probes
wslc; on macOS, it first probes Apple'scontainerCLI. If the platform-native tool is available and its service is running, the SDK loads the published image there. Docker and Podman remain fallbacks. Users can explicitly selectDocker,Podman,Wslc, orContainerthrough theLocalRegistryMSBuild property.Type of breaking change
Reason for change
Windows and macOS now provide platform-native container tooling. Preferring those tools gives users the native platform experience while preserving Docker and Podman fallback behavior.
Recommended action
If automatic selection is acceptable, no action is required. To keep using a specific runtime, set the
LocalRegistryMSBuild property explicitly, for example-p:LocalRegistry=Dockeror-p:LocalRegistry=Podman. UseWslcorContainerto explicitly select the platform-native Windows or macOS runtime.Feature area
Containers; SDK
Affected APIs
No APIs are removed.
Microsoft.NET.Build.Containers.KnownLocalRegistryTypesadds theWslcandContainerconstants, and local runtime auto-detection behavior changes.