Earlier this year I wrote about the importance of reducing the time from development to deployment and how CI/CD processes can benefit from an lightweight and fast process that doesn’t depend on container runtimes like Docker or maintenance of Dockerfiles. I introduced
konet to achieve exactly that in the .NET world and just three months later it turned out that the .NET team at Microsoft had a very similar idea (and they even refered to
The recently released .NET 7 SDK has built-in support for creating container images without writing Dockerfiles. It is available via an additional package and a separate Publish Profile:
dotnet new webapi -n mywebapi cd mywebapi/ dotnet add package Microsoft.NET.Build.Containers dotnet publish -p:PublishProfile=DefaultContainer docker run --rm mywebapi:1.0.0
Currently the support is limited to creating Linux x64 container images but support for other operating systems and architectures is in progress.
If you specify a remote container registry as a target it even works without having Docker installed and without downloading base images, but more on that later.
To use the functionality you need the .NET 7 SDK that you can install as follows:
# Linux sudo apt-get update && sudo apt-get install -y dotnet-sdk-7.0 # Windows winget install Microsoft.DotNet.SDK.7
You can create an example .NET 7 project with
dotnet new webapi -n mywebapi && cd mywebapi/ or use an existing one.
How the built-in container support works
Currently the functionality is distributed via a separate package that you need to install to your project. This
Microsoft.NET.Build.Containers package infers some information for the target container image like the base image and it’s version as well as the target container registry and repository.
After installing it you can create the container image by specifying
DefaultContainer as the publish profile.
dotnet add package Microsoft.NET.Build.Containers # you need to add "-r linux-x64" if you're on a different OS or arch dotnet publish -p:PublishProfile=DefaultContainer
In the background the binaries created by the publish command are packed into a tarball to create a new image layer with a reference to a base image. By default this creates an image based on either
mcr.microsoft.com/dotnet/aspnet for ASP.NET Core apps or
mcr.microsoft.com/dotnet/runtime for others. The resulting image is named like the assembly (e.g.
mywebapi:1.0.0) and is imported into the local Docker daemon.
Docker is no hard dependency, you can also publish directly to remote registries without downloading base images or having Docker installed by specifying the registry (and optionally the image name) during the publish with two additional properties:
dotnet publish -p:PublishProfile=DefaultContainer -p:ContainerRegistry=myregistry.io -p:ContainerImageName=lippertmarkus/mywebapi
With that the binary tarball layer is pushed directly to the registry and the according manifest and tag are created. This is great for CI/CD scenarios with limited access to container runtimes and the need for fast builds.
To make the images even smaller you can publish your apps as self-contained packages by adding the following properties:
dotnet publish -p:PublishProfile=DefaultContainer -p:PublishSingleFile=true -p:SelfContained=true -p:PublishReadyToRun=true
Through those parameters the image creation will automatically use the smaller
mcr.microsoft.com/dotnet/runtime-deps image as a base. You can of course also add all those parameters to the
*.csproj file inside the
Project.PropertyGroup tag so that you don’t need to always specify them.
Like mentioned before, currently the functionality is limited to creating Linux x64 images. Support for other OSs and architectures is in progress.
Currently also not all container registries are supported. Docker Hub and the GitHub Package Registry are currently not working. Please consult the docs for more information on the supported registries and the authentication.
With all the performance benefits of this approach, it also comes with the downside that you’re not able to execute
RUN commands during container image builds. You can work around that by running commands outside of the build and include resulting artifacts into your project or for static dependencies just create your own base image with a Dockerfile once and use that image by setting the
You can also customize the tag, working directory, ports, labels, environment variables, entrypoint and arguments of your image by setting the according properties.
Read more on the built-in container support in .NET 7 here: