.NET Framework 4.8: supported forever, and that's the trap

The runtime ships with Windows and will be patched for years. The ecosystem around it left anyway. Reading the difference before it reads you.

.NET Framework 4.8 holds a strange position: per Microsoft's lifecycle, it is supported as a component of Windows itself, patched for as long as the operating systems it ships with. No cliff, no countdown. Estates read this as safety. Read it again.

"Patched" and "viable" are different words. The framework receives security fixes; it stopped receiving the ecosystem years ago. New libraries target modern .NET only. The NuGet packages you depend on ship their last Framework-compatible versions and move on, which means your dependency tree is quietly freezing, package by package, at whatever version happened to be current when each maintainer left. No dashboard shows this. The CVE that finally matters will show it: the patched fix exists, two major versions past the last one that supports you.

Hiring reads the same clock. The engineer who wants to work on Framework 4.8 in 2029 is a specialist you will pay like one, per the staffing math that governs every legacy platform.

So the trap is precisely the absence of a deadline. Estates move off Server 2016 because January 2027 is printed on a page. Nothing prints the date your Framework estate crossed from stable to stranded, so nobody circles it, and the LTS discipline never triggers. The fix is to manufacture the date yourself: pick the dependency audit as the trigger. Once a year, count your Framework apps' packages that are more than two majors behind their current release. Rising count, no plan: that is your deadline, self-issued, with better terms than the one the incident will issue later.

Forever-supported is real. Forever-viable was never offered. The lifecycle page says the first thing. The package feeds say the second. Believe the feeds.