.NET Framework vs. .NET: What You Need to Know

It’s been twenty years since the .NET framework first appeared. Since April 2019, it has been frozen at .NET Framework 4.8, and .NET (formerly .NET Core) has replaced it.

Starting with .NET Framework 4.5.2, Microsoft announced that .NET Framework would be tied to the lifecycle of the OS. For Windows 10, that means its lifecycle will end in October 2025. However, Windows 11 includes .NET Framework 4.8, so there’s no rush to jump to .NET 6.

If you’re developing software in C#, you have a choice: Should you stay with .NET Framework or move to .NET?

Two Scenarios to Consider

Scenario One: Web Work: All the innovation and improvements are now in .NET. This is where you’ll find Blazor, SignalR, Microservices and ASP.NET Core. However, the differences are fairly minor, as .NET Core (the precursor to .NET) has been around for quite a while, and the upgrade assistant tool will do the conversion. With all that in mind, let’s move on to:

Scenario Two: Desktop Work: Both WinForms and WPF can run on .NET, though only on Windows, not Linux or Mac. If you have an existing .NET Framework application that you wish to run on .NET, then it will need converting using a Microsoft-provided upgrade assistant (more on that later). Console applications work well on Linux and Mac.

Another difference is the versions of C#. Newer versions of C# are only appearing in .NET, with the most recent being C# 11 (currently in Preview), while .NET Framework 4.8 is permanently stuck at C# 7.3. It is possible to install C# 8.0 on .NET Framework (as this Stack Overflow question explains) but there are some new features such as new nullable attributes that aren’t supported.

WinForms on .NET

Over the years I’ve developed quite a few WinForms applications; in theory, they should also work in .NET. However, I’ve found the designer is something of a work in progress and occasionally takes a very long time to open. It has been completely redesigned in .NET 6, as this Microsoft blog post explains. It doesn’t feel quite as snappy as the designer on .NET Framework.

As part of this article, I created a simple form in a .NET Framework project and the same in .NET 6, both using the most up-to-date Visual Studio 2022 on Windows 11.

System.Drawing

If your WinForms application does any amount of graphics processing, it’s likely that it uses System.Drawing. This provides access to the Windows GDI+ graphics functionality. If you start developing for Linux with .NET, you’ll notice that the System namespace no longer contains Drawing. This was one of the breaking changes announced in the notes for .NET 6 (you can read about it).

Try running an application using System.Drawing on Linux or Mac and you’ll get this exception: “System.Drawing.Common is not supported on non-Windows platforms.” There is a configuration switch that lets you hide this exception on .NET 6 but it will be removed in .NET 7. Microsoft suggests you switch libraries to one of ImageSharp, SkiaSharp or Microsoft.MAUI.Graphics.

I converted an application to use SkiaSharp to generate a Bitmap image in RAM and then save it to disk as a .png file. It ran with no issues on both Windows and Linux (Ubuntu 22.04); but changing libraries is quite a pain and will take a few days or weeks to do. There’s no easy conversion, as the graphics code has to be rewritten.

Upgrade Assistant

This is a free command line tool created by Microsoft for upgrading .NET Framework projects to .NET 6. It not only handles WinForms and WPF projects but also UWP projects, console applications, ASP.NET MVC websites and .NET Framework class libraries. It works for both C# and VB.NET projects. A tutorial about the upgrade assistant has been provided by Microsoft.

Once installed you can analyze or upgrade the project. Doing the analyze command produces a .sarif formatted file. This is short for Static Analysis Results Interchange Format. There’s a free Sarif viewer available here for Visual Studio and an extension for VS Studio Code. It outputs this:

[20:11:27 INF] Running analyzers on WinFormsAppFramework

[20:11:28 INF] Identified 0 diagnostics in project WinFormsAppFramework

[20:11:28 WRN] HighDpiMode needs to set in Main() instead of app.config or app.manifest – Application.SetHighDpiMode(HighDpiMode.<setting>). It is recommended to use SystemAware as the HighDpiMode option for better results.

[20:11:28 INF] Analysis Complete, the report is available at …(snipped).

Running the assistant with upgrade displays a series of steps, starting with backing up the project. Then it’s a matter of just pressing 1 to do the next step or 2 to cancel it. When my project was converted, the only difference I noticed in code was that the Main() method had the following call added:

Application.SetHighDpiMode(HighDpiMode.SystemAware);

It compiled and ran without issues.

Conclusion

Having to upgrade with the assistant means that it’s probably something you’ll do only when you really need to, particularly if it uses System.Drawing. I’ve a feeling that a lot of WinForms and WPF software will remain on .NET Framework for some years to come. The benefits of being able to build applications for Linux and Mac won’t happen if it uses WinForms/WPF for UI.

If you wish to develop a GUI C# application for Linux or Mac, then you’ll need an alternative library. There are several around (Uno, Avalonia and others), so explore what works for you.