Deploying .NET 8 means more than choosing an LTS release

Microsoft has released .NET 8 with three years of long-term support. For developers moving an existing application, that support commitment sits alongside several separate choices: whether to ship a runtime, compile ahead of time, trim unused code, and change a container’s operating defaults.

The November 14 announcement brings those capabilities together under one release. The launch code shows why adopting the supported platform doesn’t mean enabling every deployment feature at once.

File photo: Microsoft buildings, efes, 2015. CC0 1.0, via Wikimedia Commons. Recompressed and responsively cropped; not the .NET 8 launch.

A target platform isn’t a bundled runtime

A runtime identifier such as linux-x64 describes the operating-system and processor target. In .NET 8, specifying one no longer automatically makes an application targeting .NET 8 self-contained.

The 8.0.100 SDK’s inference rules make this distinction explicit. Without another setting that changes the result, self-contained defaults to false. Applications that need to carry their runtime can request that separately.

This matters when translating an existing publishing command. Selecting a Linux target and deciding whether the destination needs an installed runtime are different questions. There are also exceptions to the new default: publishing with Native AOT or trimming can still imply self-contained deployment when it hasn’t been explicitly configured.

Native AOT changes compatibility, not just packaging

Native AOT compiles an application to native code before deployment, rather than relying on just-in-time compilation while it runs. Microsoft’s ASP.NET Core launch explanation says the resulting application includes required runtime libraries and can run without a separately installed .NET runtime.

That isn’t a universal conversion switch. The release introduces ASP.NET Core Native AOT support focused on cloud-native APIs. Its compatibility table lists gRPC as supported and Minimal APIs as partially supported, while MVC, Blazor and SignalR aren’t supported in that deployment mode. Their availability elsewhere in .NET 8 doesn’t imply AOT compatibility.

Trimming is part of this decision. The launch SDK enables trimming for AOT when the trimming property hasn’t already been set. The release documentation also identifies restrictions on dynamic assembly loading, runtime code generation and unconstrained reflection.

An application can therefore work during ordinary development yet encounter problems when published. Microsoft distinguishes warnings in application code from warnings arising in dependencies, which may only appear during publication. A successful development run isn’t a substitute for inspecting the publish result and testing the native executable.

The new AOT Web API template makes its assumptions visible: it uses Minimal APIs, a slim builder and generated JSON serialization metadata. It also starts with HTTP rather than HTTPS, anticipating a deployment where an ingress service handles HTTPS. That template choice doesn’t configure such a service for the developer.

A container user must actually be selected

The release’s container changes have a similar distinction. In the launch-day Debian runtime-dependencies Dockerfile, Microsoft creates the non-root app user and sets ASPNETCORE_HTTP_PORTS=8080. Creating that account isn’t the same as selecting it: the inspected Debian runtime and ASP.NET image chain contains no USER app instruction.

Developers using that Dockerfile route still need to choose the intended process user and align their port mappings. The announcement separately describes SDK-published containers as non-root by default. Those are different publishing paths, not interchangeable defaults.

This account is based on release-source inspection, not a benchmark, container run or security test. The three-year support window provides a maintenance horizon; it doesn’t establish that every application, dependency and deployment configuration fits every new option.