.NET SDK Container Publishing

When to Use This Skill

Use this skill when:

• You want a container image for a .NET service and do not want to hand-write a Dockerfile
• You want to know how to tag, name, or expose ports on an SDK-built image without a Dockerfile
• You are wiring container publishing into CI / CD or a release pipeline
• An SDK-built image pushes to the wrong registry, gets the wrong tag, or picks the wrong base image
• You need a tarball of an image for scanning or air-gapped loading

Do not use it when:

• You need a RUN step or arbitrary layer customization in the image. The SDK tooling cannot emulate RUN; write a Dockerfile instead.

What This Is

Since .NET 7, dotnet publish builds a container image natively. The Microsoft.NET.Build.Containers tooling ships with the SDK, so no Dockerfile is required and no Docker install is needed to produce an image. Docker or Podman is only required to run the image locally. This is documented in the containerize with dotnet publish tutorial.

The quickest path is one command:

dotnet publish /t:PublishContainer -c Release

That compiles the app and emits an image in one step. The image name defaults to the project's AssemblyName. Override it with ContainerRepository (renamed from ContainerImageName in earlier versions - see the sdk-container-builds customization notes).

The Three Output Modes

The tooling writes the image in one of three ways. Pick based on where the image ends up.