Imported from andormihaly/ai-dotnet-template (template/.codex/.agents/skills/container-publish/SKILL.md). Install upstream with npx skills add andormihaly/ai-dotnet-template --skill container-publish. Copyright stays with the author.

.NET SDK Container Publishing

Core Principles

1. Use SDK container publishing when the application does not need custom Dockerfile build steps.
2. Run production containers as non-root.
3. Prefer small, hardened runtime images when application requirements allow them.
4. Use a Dockerfile when OS packages, custom build stages, or other image customization require it.

Patterns

Basic Publish

dotnet publish src/AiDotNet.Api/AiDotNet.Api.csproj /t:PublishContainer --os linux --arch x64

Project Configuration

<PropertyGroup>
  <TargetFramework>net10.0</TargetFramework>
  <ContainerRepository>myapp-api</ContainerRepository>
</PropertyGroup>

Add container-family/base-image settings only when they are appropriate for the application's globalization, diagnostics, and native-library needs.

Registry Publishing

Authenticate with the target registry before pushing and pass registry/repository/tag settings explicitly.

dotnet publish src/AiDotNet.Api/AiDotNet.Api.csproj /t:PublishContainer --os linux --arch x64 -p:ContainerRegistry=myregistry.azurecr.io -p:ContainerImageTag=1.0.0

Multi-architecture

Use supported runtime identifiers when both x64 and arm64 images are required. Verify all native dependencies support each target architecture.

Anti-patterns

• Do not run production containers as root unless there is a demonstrated requirement.
• Do not choose a chiseled/distroless image without checking globalization, diagnostics, shell, and native-library requirements.
• Do not embed registry credentials in project files or source control.
• Do not force SDK container publishing when a Dockerfile is the clearer solution.

Decision Guide