.NET

How Long a .NET Version Is Supported Decides When You Upgrade

Modern .NET ships a major release every November. Even-numbered releases are Long Term Support and are serviced for three years; odd-numbered releases are Standard Term Support and are serviced for eighteen months. Support ends on a published date whether or not anything is wrong with the application, and once it ends the runtime stops receiving security fixes, so the upgrade gets scheduled by the calendar rather than by the feature list.

The version an application targets lives in the target framework moniker in the project file, and runtimes install side by side, so one host can carry several and each application binds to the one it was built against. A library that has to be referenced from both .NET Framework and modern .NET targets netstandard2.0, which is the last version .NET Framework can consume, or multi-targets and carries conditional code for each.

Upgrading a single project is usually a smaller job than the things around it that hold the version in place:

• Package dependencies, whose own minimum target eventually moves past yours, at which point fixes stop arriving on the version you are sitting on.
• The operating system or container base image, which carries its own end of support date that rarely lines up with the runtime's.
• global.json, which pins the SDK a build uses and stops a newer developer machine from quietly building with a different toolchain.
• A managed hosting platform, which offers a fixed list of runtime versions and retires them on its own schedule rather than yours.

Three Causes That Look Like the Same Slowdown

An ASP.NET Core service that is comfortable at low load and unresponsive at high load usually has one of three causes underneath, and from the outside they present identically: latency climbs, then requests time out. Requests-per-second and queue depth alone will not separate them. They are distinguishable with dotnet-counters against the System.Runtime and Microsoft.AspNetCore.Hosting providers, which is worth doing before anyone adds instances, since more instances means more connections against the same pooled resource, so scaling out makes pool exhaustion worse rather than better.

• Thread pool starvation, which shows as queue length climbing while the thread count grows one thread at a time, because that is the rate the pool injects threads past its minimum. The cause is blocking on a request thread, usually .Result, .Wait() or GetAwaiter().GetResult() somewhere on the path, and the fix is an async call chain end to end rather than a higher minimum thread count.
• Connection pool exhaustion, which shows as requests waiting and then failing at the pool's timeout rather than at the query's. The default maximum pool size in ADO.NET is 100 per distinct connection string, and the usual reason for reaching it is a connection held open for the length of a request instead of the length of a query.
• GC pressure, which shows as percent time in GC and Gen 2 collection counts rising in step with load. Large short-lived buffers are the common source, since arrays over 85,000 bytes go straight to the large object heap, and in a container the effect is sharper because the runtime sizes its heap from the cgroup memory limit rather than from the host's total memory.

Configuration Resolves Differently on the Server Than on a Laptop

Applications that behave locally and misbehave once deployed usually differ in how configuration resolves rather than in code. One of the first things to check is which environment name the host is actually reporting: ASPNETCORE_ENVIRONMENT selects which appsettings.{Environment}.json is layered on top of appsettings.json, and when the variable is unset the host defaults to Production, so a setting that only ever existed in the Development file is simply absent, with no error to read.

Providers are applied in order and later ones win: appsettings.json, then the environment-specific file, then user secrets in Development, then environment variables, then command line arguments. Environment variables express nesting with a double underscore rather than a colon, so Logging:LogLevel:Default is set as Logging__LogLevel__Default, and a variable written with a colon on a Linux host neither binds nor complains.

Three more differences only surface once something sits in front of the application:

• Behind a reverse proxy or an ingress controller, Request.Scheme stays http until forwarded headers middleware is configured to trust X-Forwarded-Proto, and until then generated absolute URLs and OAuth redirect URIs come back as http and fail validation at the identity provider.
• Data protection keys are written inside the container by default, so authentication cookies and antiforgery tokens issued before a restart, or by a different replica, are rejected. The key ring has to be persisted to shared storage and the application name set explicitly so replicas agree on it.
• Globalization differs by image. Alpine-based images carry no ICU unless icu-libs is installed, and invariant globalization mode changes culture-sensitive parsing, sorting and string comparison, which surfaces as dates and decimals read differently than they were on Windows.

Running ASP.NET Core Under IIS

IIS does not host a modern .NET application the way it hosted .NET Framework. The server needs the ASP.NET Core Hosting Bundle, which installs the ASP.NET Core Module along with the runtime, and the application pool is set to No Managed Code, because the pool is not loading .NET Framework. Publishing emits a web.config that points IIS at the module, and because that file is generated, hand edits to it on the server are lost on the next publish unless they are made to the source web.config in the project.

In-process hosting runs the application inside the IIS worker process and is the default. Out-of-process runs Kestrel as a separate process that IIS proxies to over a loopback port. Under IIS the request body size is capped in two places, Kestrel's own maximum request body size and maxAllowedContentLength in web.config, so an upload can be rejected by whichever limit was not raised, and the error returned differs depending on which one fired.

How a Schema Change Actually Reaches Production

Calling Database.Migrate() from application startup is the version that is easiest to write and the first to break. With more than one replica starting at the same moment, several processes attempt the same migration at once, and the application's own database account has to hold schema-altering rights for the entire time it is running rather than only during a release.

Two alternatives keep the migration inside the release rather than inside the application. A migration bundle, produced by dotnet ef migrations bundle, is a self-contained executable that the deploy step runs with the connection string supplied at run time, so the runtime account never needs DDL rights. Generating a script with the idempotent option instead produces SQL that can be read and reviewed by whoever owns the database and is then applied by that same release step, which suits a database owned by a different team with its own change process without the change being moved by hand.

Whichever route runs them, migrations have behavior worth knowing before the first branch merge:

• Migrations are ordered by the timestamp in their file name, so two branches that each add one produce a conflict in the model snapshot that a text merge will happily resolve into something that applies cleanly and describes the wrong model. Regenerating the later migration after the merge is the reliable fix.
• A column rename is scaffolded as a drop and an add unless the migration is written as RenameColumn, so the generated version compiles, applies, and discards the data in that column.
• Down migrations are not a rollback path once the new version has written data. A forward fix is the realistic plan, and the down method is mostly useful during development.
• Data backfills are not generated. EF Core scaffolds schema operations only, so moving or populating data belongs in its own migration or its own reviewed script.