Users can build and publish container images for their applications natively

[baronfel]

Is your feature request related to a problem? Please describe.

Users should not require a container engine to be installed on their local machines in order to author and push OCI-compliant container images for their applications. They should have tooling that makes it easy to side-step common container build errors, like missing/inadvertent files in the base image, while also having the flexibility to override every part of the container image's definition.

Describe the solution you'd like

There should be an in-box publish profile that allows for packaging the application in a container, and publishing it to any OCI-compliant registry. As much as possible, that image should be created using existing project metadata for properties like

• the default base image of the new image (for example, an ASP.NET Core web application should use the mcr.microsoft.com/dotnet/aspnet image as a base.
• the default base image tag used for the new image (a net7.0 application should use the 7.0 tag for its base image)
• output container image tag
• output container image name
• Files to be included in the new container
• Intelligent layering of dependencies

And it should implicitly set configuration for the .NET Runtime in ways that are advantageous for containers

• defaulting to a RID-specific build

This publish profile should seamlessly integrate with existing Docker-focused publish profiles for scenarios like publish-to-Azure Container Registry.

[baronfel]

We're tracking this work in a separate repo over at https://github.com/dotnet/sdk-container-builds for the moment. I go into detail a bit more in this issue, though other issues help outline the kinds of things that we'd like to be able to do.

[baronfel]

Little bit of cleanup on this issue - currently users can read about the first iteration of our approach in this blogpost. More work is ongoing to improve the story for authentication to remote registries and integrate seamlessly with Visual Studio publishing.

[baronfel]

Going to close this as we have met the mark with auth and greater registry support. Additional enhancements are incremental and can be tracked in separate issues.