.NET Framework APIs that won’t be coming to .NET 5.0

Microsoft’s shift to a new .NET is nearly complete. .NET Core 3.0 is here, and it’s the foundation for next year’s big bang release of .NET 5.0. That’s when .NET Core becomes the main development branch for all of .NET, and the old .NET Framework slides off into a well-deserved retirement and a very long support lifecycle.

That doesn’t mean all your existing .NET code will run on .NET 5.0. To be honest, odds are it won’t. This is the new Microsoft, not the old, and keeping legacy code alive is no longer a priority. Yes, Microsoft will help you move to the new framework, but you’ll need to do a fair bit of heavy lifting to get your code in shape for the transition. Unless you plan to stay on the .NET Framework forever, you have a year or so to use .NET Core 3.0 as a proving ground for a new, cross-platform .NET future.

The long road to .NET 5.0

As Immo Landwerth, program manager for .NET, notes on GitHub, .NET Core began life with a minimal set of APIs from the .NET Framework, with 18,000 or so, enough to deliver key functions. Over time that number has increased. .NET Standard 2.0, which was designed to make it easier to work across different .NET implementations, increased support to more than 38,000 .NET Framework APIs in .NET Core 2.0. More were added with the Windows Compatibility Pack for Windows-specific .NET Core apps, taking the total to more than 60,000.

The process of porting APIs has continued in .NET Core directly and in .NET Standard. The current release of .NET Core 3.0 has added support for many Windows Presentation Foundation (WPF) and WinForms APIs (though only for Windows applications), giving you more than half the total .NET Framework APIs. That’s only for the existing .NET Framework; .NET Core has approximately 62,000 of its own APIs, with support for modern Internet technologies such as gRPC.

Porting .NET Framework APIs to .NET Core has resulted in a lot of good work by the .NET team, but it’s reached the point where they’re unable to go much further. Older technologies such as Windows Workflow, Web Forms, or the Windows Communication Foundation aren’t compatible with modern Internet standards, and in many cases may result in security issues. The APIs that have made the transition are needed for the way we build apps today: for the desktop, mobile, the web, and cloud. If you’re building those in .NET, then you shouldn’t have too much work to get ready for 2020’s transition.

If the APIs you need aren’t in .NET Core 3.0, then they’re not going to be in .NET 5.0. The question then is: Does your code really need those APIs, or can you use something else?

It’s a big question, and one that needs some thought. One key aspect is the status of your code. Is it under active development, or is it, like the .NET Framework, legacy code that’s in extended maintenance? Active development code should be redesigned and rewritten where necessary. With legacy apps you’ll need to monitor the support status of the .NET Framework and make decisions aligned with Microsoft’s plans.

Finding alternatives to legacy .NET APIs

For the APIs that are being abandoned, Microsoft is already suggesting alternatives, with new .NET Core APIs filling many of the gaps. Some, like WebForms, have logical replacements. For WebForms it’s in the shape of Blazor and its mix of server-side rendered views and WebAssembly-hosting of new in-browser components. Others will need more work, as there’s no direct replacement and security-related decisions mean that commonly used features are now considered unsafe.

One key feature that won’t shift to the new framework is .NET Remoting. In a long thread on Twitter, a Microsoft engineer noted that abandoning .NET Remoting was for security reasons, as it was impossible for it to meet modern security standards. Its disappearance shouldn’t be too much of a hardship, as .NET Core’s gRPC support should take up the slack. There may be some issues with authentication, as Windows authentication doesn’t currently work with gRPC’s HTTP/2 because it is based on Kerberos.

Mismatches like this, between older, insecure protocols and newer ways of working, are at the heart of many Microsoft decisions. Yes, it’s good to be backward-compatible, but not at the expense of application security. We live in a world where it’s more important to think in terms of an Internet-first, zero-trust security model than one where our applications always run on secured private networks.

Dropping protocols that can’t be secured and can’t meet the standards we now require will cause issues in any migration to .NET 5, but it’s better thought of as an opportunity to rework code to meet those standards rather than code being left behind by a transition. If you don’t want to make those changes, Microsoft will continue to support the existing .NET Framework for many more years—at least 10 years of support is planned.

The .NET community response

If you rely on older protocols, services, and APIs, but still want to move to the newer .NET releases, there’s a chance that many of these missing APIs will eventually end up working with .NET 5.0 in some form. It’s important to note that if they do, it won’t be as official Microsoft projects.

The Microsoft .NET team is instead looking at releasing some of the .NET Framework libraries and APIs as open source under an MIT license, so that community teams can build their own implementations of familiar APIs. We’re already seeing work on versions of Windows Workflow and Windows Communication Foundation, with a focus on server implementations. It’s possible that a handful of the remaining APIs could be added later, if they add something to the .NET roadmap and the direction that’s being taken.

It’s never easy changing things. Like moving to a new house, something is always going to be left behind or get broken along the way. Microsoft is at least letting us know where the gaps will be in its .NET transition, with plenty of time to either rework code or transition it to long-term support programs. Even if we can’t update legacy code, the .NET Framework is not being completely abandoned, with Microsoft committing to at least a decade of support. Whatever we choose to do, users won’t be left wondering why their apps have stopped working.