Introduction
Containers have become the standard way to package and deploy modern applications. Whether you're deploying to Kubernetes, Azure Container Apps, AWS ECS, or Google Kubernetes Engine, containers provide consistency across development, testing, and production environments.
Traditionally, creating a containerized .NET application required writing and maintaining a Dockerfile. While Dockerfiles are powerful, they introduce additional complexity, especially for developers who simply want to package and deploy their applications.
Recent versions of .NET introduced native container publishing capabilities that allow developers to build container images directly from the .NET CLI without creating a Dockerfile.
This simplifies the containerization process, reduces maintenance overhead, and helps developers adopt cloud-native deployment practices more easily.
In this article, you'll learn how native container publishing works, its benefits, how to configure it in .NET applications, and when it should be used in production environments.
The Traditional Container Workflow
For many years, containerizing a .NET application required a Dockerfile.
Example:
FROM mcr.microsoft.com/dotnet/aspnet:9.0
WORKDIR /app
COPY . .
ENTRYPOINT ["dotnet", "MyApp.dll"]
Typical workflow:
Source Code
|
v
Dockerfile
|
v
Docker Build
|
v
Container Image
Although effective, Dockerfiles introduce additional files and configuration that must be maintained.
Challenges with Dockerfiles
Dockerfiles are widely used, but they can introduce several challenges.
Maintenance Overhead
Each application requires a properly configured Dockerfile.
Security Risks
Outdated base images can introduce vulnerabilities.
Build Complexity
Multi-stage builds can become difficult to maintain.
Configuration Drift
Different projects often use different Dockerfile conventions.
These issues become more noticeable in larger environments.
What Is Native Container Publishing?
Native container publishing allows .NET to generate container images directly during the publish process.
Instead of:
Publish
|
Docker Build
|
Container Image
The workflow becomes:
Publish
|
Container Image
The .NET SDK handles image creation automatically.
No Dockerfile is required.
How Native Container Publishing Works
The .NET SDK includes built-in support for generating Open Container Initiative (OCI) compliant images.
The process looks like this:
Application
|
v
.NET SDK
|
v
Container Image
|
v
Registry
The SDK selects an appropriate base image and builds the final container image.
Benefits of Native Container Publishing
Native container publishing offers several advantages.
Simpler Configuration
No Dockerfile is required.
Faster Onboarding
Developers can containerize applications quickly.
Consistent Builds
The .NET SDK follows standardized build practices.
Reduced Maintenance
Fewer files need ongoing updates.
Cloud-Native Friendly
Works well with modern deployment platforms.
These benefits make containerization more accessible for .NET developers.
Prerequisites
Before publishing containers natively, ensure you have:
Verify your SDK version:
dotnet --version
Keeping the SDK updated ensures access to the latest container features.
Creating a Sample Application
Create a new Web API project.
dotnet new webapi -n NativeContainerDemo
cd NativeContainerDemo
The application is now ready for container publishing.
Publishing a Container Image
Use the following command:
dotnet publish \
-t:PublishContainer
The SDK automatically creates a container image.
No Dockerfile is needed.
Understanding the Publish Process
During publishing, .NET performs several tasks.
Compile Application
|
v
Publish Output
|
v
Generate Container Image
|
v
Tag Image
The entire process is managed by the SDK.
Configuring Container Settings
Container settings can be configured in the project file.
Example:
<PropertyGroup>
<ContainerRepository>
nativecontainerdemo
</ContainerRepository>
</PropertyGroup>
This defines the repository name for the generated image.
Setting Image Tags
Specify custom tags.
<PropertyGroup>
<ContainerImageTag>
v1.0.0
</ContainerImageTag>
</PropertyGroup>
This helps with version management.
Example image:
nativecontainerdemo:v1.0.0
Versioned images simplify deployment and rollback operations.
Selecting Base Images
The SDK automatically selects suitable base images.
Example:
mcr.microsoft.com/dotnet/aspnet
Depending on the application type, .NET chooses:
Developers can override these defaults when necessary.
Using Custom Base Images
Custom base images can be configured.
Example:
<PropertyGroup>
<ContainerBaseImage>
mcr.microsoft.com/dotnet/aspnet:10.0
</ContainerBaseImage>
</PropertyGroup>
This provides greater control over runtime environments.
Publishing Directly to a Registry
Container images can be pushed directly to registries.
Example workflow:
Application
|
v
Publish Container
|
v
Container Registry
Supported registries include:
Azure Container Registry
Docker Hub
Amazon ECR
Google Artifact Registry
This streamlines deployment pipelines.
Running the Published Image
After publishing, run the container.
docker run -p 8080:8080 nativecontainerdemo
The application becomes accessible through the exposed port.
This process is identical to traditional container images.
Native Container Publishing and CI/CD
Native publishing integrates easily into CI/CD workflows.
Example pipeline:
Source Code
|
v
Build
|
v
Publish Container
|
v
Push Registry
|
v
Deploy
This reduces pipeline complexity by eliminating separate Docker build steps.
Deploying to Kubernetes
The generated container images work with Kubernetes.
Example deployment flow:
Container Registry
|
v
Kubernetes Cluster
|
v
Pods
Since the output is OCI-compliant, Kubernetes can run it without modification.
Deploying to Azure Container Apps
Native container images can also be deployed to Azure Container Apps.
Workflow:
.NET Application
|
v
Container Image
|
v
Azure Container Registry
|
v
Azure Container Apps
This provides a fully managed cloud-native deployment model.
Security Benefits
Native container publishing can improve security practices.
Consistent Base Images
The SDK uses trusted Microsoft container images.
Reduced Human Error
Less manual configuration means fewer mistakes.
Simplified Updates
Base image updates are easier to manage.
Smaller Attack Surface
Standardized images reduce unnecessary customization.
Security still requires ongoing monitoring and patch management.
When Dockerfiles Are Still Useful
Native publishing does not eliminate every Dockerfile scenario.
Dockerfiles remain useful when:
Installing Additional Packages
Example:
apt-get install
Complex Multi-Stage Workflows
Advanced build customization may require Dockerfiles.
Custom Operating System Configuration
Applications with specialized requirements often need additional setup.
Third-Party Dependencies
Custom runtime environments may require manual configuration.
In these situations, Dockerfiles still provide greater flexibility.
Performance Considerations
Native publishing offers performance advantages.
Benefits include:
However, runtime performance is generally similar because the generated image still runs the same .NET application.
Performance optimization should focus on application design rather than container generation methods.
Best Practices
Keep SDK Versions Updated
Use the latest stable .NET SDK.
Use Versioned Images
Avoid relying solely on the latest tag.
Store Images in Registries
Maintain centralized image management.
Integrate with CI/CD
Automate publishing and deployment.
Monitor Container Security
Regularly scan images for vulnerabilities.
Use Custom Base Images Carefully
Only customize when necessary.
Following these practices improves maintainability and reliability.
Common Challenges
Registry Authentication
Publishing may require additional registry credentials.
Image Naming
Incorrect repository names can cause deployment issues.
Platform Compatibility
Verify compatibility with deployment environments.
Custom Runtime Requirements
Some applications still require Dockerfile customization.
Organizational Standards
Existing enterprise processes may already depend on Dockerfiles.
Understanding these challenges helps avoid deployment issues.
Real-World Use Cases
Native container publishing works particularly well for:
ASP.NET Core APIs
Microservices
Background workers
Cloud-native applications
Internal business services
Container-based development environments
These scenarios benefit from simplified container management.
Conclusion
Native container publishing represents a significant step forward for .NET cloud-native development. By allowing developers to create OCI-compliant container images directly from the .NET SDK, it eliminates the need for many Dockerfiles and simplifies the application deployment process.
For ASP.NET Core applications, microservices, and cloud-native workloads, this feature reduces complexity, improves consistency, and accelerates developer productivity. While Dockerfiles still have an important role in advanced customization scenarios, many applications can now be containerized, published, and deployed using only the .NET CLI.
As container adoption continues to grow across Kubernetes, Azure Container Apps, and other modern platforms, native container publishing provides .NET developers with a faster and more streamlined path from source code to production deployment.
Join the conversation! Your thoughts help the community grow.