The Immortal .NET 4.8 Framework

I opened the Veamcast solution in Visual Studio today and got this greeting:

Support for Native UWP project is being deprecated.

It's a polite way of saying: that thing you built on? We're done with it.

The message comes from the packaging project — VeamcastPackagingProject — which wraps the WPF desktop app in a UWP container. We didn't use it because we loved UWP. We used it because WPF didn't have what we needed at the time: protocol registration (veamcast://), toast notifications, background tasks, Windows Store distribution. The UWP packaging project was the bridge.

The bridge they keep burning

Microsoft has a pattern. They build a platform, ask you to commit to it, then deprecate it and point you to the next thing. Silverlight. Windows Phone. UWP. Each time, the pitch is the same: this is the future, build here. Each time, the future has an expiration date.

UWP was supposed to be the universal app model — one platform for desktop, phone, Xbox, HoloLens. The phone died. The store never took off. Xbox stayed its own world. What remained was a desktop app framework that was harder to use than the one it was supposed to replace.

Meanwhile, in .NET 4.8

Through all of this, .NET Framework 4.8 just keeps running. It shipped in 2019 and Microsoft declared it the last major version of the .NET Framework. No more feature updates. Just security patches and reliability fixes. Forever.

That sounds like a death sentence. It's actually a superpower.

Veamcast's core — the WPF desktop app, the email client, the browser, the channel system — runs on .NET 4.8. It has run on .NET 4.8 for years. It will continue to run on .NET 4.8 because:

• Windows ships with it built in. No runtime installer, no version conflicts.
• It's frozen, which means nothing breaks. No surprise behavioral changes between versions.
• WPF on .NET 4.8 is mature and complete. WebView2 works. MailKit works. Everything we need works.
• .NET Framework is a component of Windows, so it stays supported for as long as it's installed on a supported version of Windows. Microsoft says it will keep shipping in Windows, with no plans to remove it.

.NET Framework 4.8.1 is the latest version of .NET Framework and will continue to be distributed with future releases of Windows. As long as it is installed on a supported version of Windows, .NET Framework 4.8.1 will continue to also be supported.

Microsoft, .NET Framework Support Policy (dotnet.microsoft.com)

A billion machines can't be deprecated

It's worth saying out loud how big that last point is. .NET Framework 4.8 is a component of Windows, not a download. It ships inside Windows 10 1903 and every release after it, including Windows 11. Microsoft's own figure for monthly active Windows 10 and 11 devices is north of a billion, and every one of those machines has 4.8 sitting on it whether the person using it has ever heard the phrase or not.

Plenty of them are running on it right now. Payroll systems, point-of-sale terminals, warehouse scanners, hospital scheduling, the line-of-business app somebody's back office opens every single morning: an enormous amount of the software that actually runs the world is WinForms and WPF on .NET Framework. Most of the people depending on it will never know they are. They just know the thing opens.

That install base is the whole reason 4.8 can't be killed. Microsoft could deprecate UWP because hardly anyone shipped on it. Retiring .NET 4.8 would mean breaking a billion desktops and most of the world's internal business software on the same morning. It isn't a promise they made out of sentiment. It's arithmetic.

Which is the part the just migrate already advice always leaves out. A framework doesn't survive because it's modern. It survives because of how much would stop working if it went away.

The new stuff isn't always better

Yes, .NET 10 (and whatever comes next) is faster. It has better async support, better AOT compilation, better everything on paper. For new projects, especially web APIs and cloud services, it's the right choice, and we use it: Veamcast's own API layer (VeamcastAPI) runs on .NET 10.

But for a desktop app that works? Migrating a large WPF application from .NET 4.8 to .NET 10 is not a weekend project. It's a months-long effort with subtle breaking changes, third-party library incompatibilities, and zero user-visible improvement at the end. Your users don't care what CLR version loads their email.

Meanwhile, the phone app is .NET 10

This is the part that gets lost when "still on 4.8" gets heard as "refuses to move." Veamcast is not one runtime. It is four, and each surface gets the one that actually fits it:

• Desktop - WPF on .NET Framework 4.8. Years of working code, on a runtime that is already installed on the machine.
• API - VeamcastAPI on .NET 10, behind api.veamcast.com.
• Web front end - Blazor on .NET 8.
• Phone - VeamcastMAUI on .NET 10, targeting net10.0-android and net10.0-ios.

That last one is the clearest case for modern .NET there is. .NET MAUI puts the Android app and the iOS app in one C# codebase, talking to the same api.veamcast.com the desktop talks to. None of that was ever possible on .NET Framework, which never left Windows and never meant to. So the mobile app never got a migration argument. It was written on .NET 10 because .NET 10 is where mobile lives.

But look at what that choice costs, because it is the exact cost 4.8 does not charge. MAUI is the descendant of Xamarin.Forms, which came out of Xamarin, which Microsoft bought in 2016. It is a young framework with a long pedigree of renames, and it still ships behavior changes release over release. Its Android build wants a specific JDK and a specific Android SDK on the machine. Its iOS build cannot produce a file any human can install without a Mac and a paid Apple Developer membership. Every one of those is a moving part that can break a build on a Tuesday for reasons that have nothing to do with your code.

That churn is the price of being on mobile at all, and it is worth paying, because there is no stable alternative and no decade-old app to protect. The desktop has both. That is the entire difference. Same team, same solution file, same week: take the bleeding edge where it buys something, and leave 4.8 alone where the bleeding edge would only cost.

What about the UWP deprecation?

The capabilities we originally needed UWP packaging for are now available without it:

• Protocol registration — WPF can register veamcast:// directly via the registry.
• Toast notifications — Available through Windows App SDK or community libraries.
• MSIX packaging — Works with plain WPF, no UWP wrapper needed.
• Store distribution — MSIX supports WPF apps directly.

So the deprecation warning is really just Microsoft catching up to reality. The UWP wrapper was always a workaround. Now WPF can do it natively, and we can drop the packaging project when we're ready. No rush.

The lesson

Frameworks that promise the future tend to have short lives. Frameworks that just work tend to stick around. .NET 4.8 made no promises about the future. It just said: I'm done. I work. I'll be here.

That's the most immortal thing a framework can say.