Course contentsShow
← C#
Lesson 1831 of 1,90817. Deployment and Cloud ArchitectureFree lesson

Managing .NET SDK vs Runtime Layers

Decide when to use full SDK images versus lightweight runtime images for production workloads.

In this lesson, you will learn how to strategically balance build-time requirements and production footprint by choosing between the .NET SDK and the Runtime images.

When deploying .NET applications to production, your container strategy should prioritize the principle of least privilege and minimal attack surface. The .NET SDK image is a heavyweight environment containing the compiler, build tools, and NuGet cache. It is excellent for CI pipelines, but it is a security and performance liability for production.

The Runtime vs. SDK Dichotomy

The .NET Runtime (or aspnet variant) is stripped down, containing only what is necessary to execute pre-compiled binaries. By shifting from the SDK to a runtime-only base image, you significantly reduce the size of your container—often by several hundred megabytes. This isn't just about disk space; it decreases pull times during auto-scaling, reduces the attack surface by removing build tools like dotnet CLI or msbuild from the container, and improves your overall deployment velocity.

Implementation via Multi-Stage Builds

The industry-standard approach is to use a multi-stage Dockerfile. In the first stage, you pull the mcr.microsoft.com/dotnet/sdk image to restore dependencies and compile your C# code. In the second stage, you switch to the mcr.microsoft.com/dotnet/aspnet runtime image and copy only the bin/Release output.

# Stage 1: Build
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY . .
RUN dotnet publish -c Release -o /app/publish

# Stage 2: Runtime
FROM mcr.microsoft.com/dotnet/aspnet:8.0
WORKDIR /app
COPY --from=build /app/publish .
ENTRYPOINT ["dotnet", "MyApplication.dll"]

When to use the SDK in Production?

The only time you should consider keeping the SDK in a production-like environment is when performing "just-in-time" compilation on the host (rare) or if you are running a specialized debugging diagnostic toolset that requires the compiler to inspect managed symbols dynamically. However, for 99% of workloads, your production container should never know how to compile code.

Key Takeaway: Always use multi-stage builds to isolate the .NET SDK during the compilation phase, ensuring only the lightweight, hardened .NET Runtime is present in your production container image.