Moving to Desktop Applications in .NET Core/.NET 5

.NET 5 has been out for over four months now (.NET Core 3 for a year and a half)—what’s in either platform for the desktop developer? The short answer is “Enough to consider building your next desktop application in them.” Longer answer: “… and consider migrating existing applications.”

You’re building desktop applications in the .NET Framework and you’re wondering if you should be moving them to .NET Core or .NET 5. Part of your problem is that the desktop applications you’ve built on the .NET Framework have that whole “working” feature that users like so much. Do you really need to adopt a new desktop platform?

Having asked that question, I should point out that—in .NET Core and .NET 5—your experience as a WPF and Windows Forms developer isn’t all that “new”: WPF is fully supported in .NET Core, as is Windows Forms (including the Windows Forms Designer, which was released last May). When it comes to building applications, you’ll find that your fingers already know what to do. You aren’t going to be slowed down if you start your next application in .NET 5.

But that’s asking the wrong questions. The real question is whether there’s anything in desktop development for .NET Core/.NET 5 to make you want to switch.

The Payoffs

To begin with, moving to .NET Core may solve any performance problems you might have. Thanks to improvements in the .NET base class libraries, you should see all the things that drag down typical business applications run faster: database, networking and file I/O activity. In .NET 5, even screen redraws should be faster. And you don’t have to do anything to get that payoff except build your application in .NET Core or .NET 5.

You’ll get some additional relief when it comes to deploying your application. If you want to ensure that the right version of .NET Core exists on the computer with your application, you can bundle your application and the required .NET Core components into a single exe file (and, by the way, only the necessary .NET Core components that your application requires have to be bundled into that file). Finally, you really can just copy your one file to a new computer and expect your application to run.

And, while it may not be your first thought when it comes to “new, cool desktop stuff,” if you want to use the latest versions of C#, C# 8 and 9, you need to move to .NET Core/.NET 5. New C# 8/9 features include the ability to add default implementations for methods when defining an interface (what are called “traits” in other platforms), create immutable reference types (records) and write simpler code (omitting types in new expressions, using top-level expressions). In an increasingly asynchronous world, the latest versions of C# also let you create collections that work with an asynchronous foreach loop and throw in a more flexible using statement that lets you dispose of objects asynchronously (which also provides simpler code when setting up a using block for automatic disposal).

The new versions of C# are, of course, just the proverbial tip of the iceberg. In the long run, .NET Core will also be where you’ll find all “the new stuff” in desktop development. To quote Olia Gavrysh (.NET Program Manager), from back in November of 2019, “We are committed to support .NET Framework for years to come, however it will not be receiving any new features, those will only be added to .NET Core (and eventually .NET 5).” Specifically, this means that the .NET Framework won’t go beyond version 4.8 and will receive only “Windows essential” (Windows and security) updates.

Some of that new “new stuff” is WinUI (which I’ve written about elsewhere), which provides a better developer experience (hot reload so you don’t have to stop debugging to make UI changes) and a bunch of new controls, many of which are very touch friendly. If you’re building WPF applications, you can (thanks to XAML Islands) start incorporating those new controls into your existing applications … provided you’ve moved to .NET 5.

You’ll also get more functionality in your Windows Forms controls in .NET 5, too. ListView has a new API that gives you access to some significant improvements around creating groups; the Task Dialog box is much enhanced; File Dialogs can do a better job of managing their state (i.e. remembering what folder the user last looked at, for example). Accessibility support in Windows Forms controls is also improved (and you don’t have to do anything to get those benefits, either).

Migrating

That’s if you want to start new. If you want to move your existing applications to .NET Core/.NET 5, there are, as you might expect, migration issues. The two big changes are the new structure for project files and the new APIs.

Among other differences, project files are different in the .NET Core/.NET 5 world because your NuGet package references move from the packages.config file into your project file. And, while you can continue to use at least some .NET Framework APIs in your .NET Core/.NET 5 desktop applications, you really should be using the .NET Core/.NET Standard/.NET Standard Target APIs (who knows? Someday you might be able to deploy on something other than Windows). It’s certainly possible that some of the APIs you’re currently interacting with are no longer present and you’ll need to find replacements (though those will usually just be new versions of your existing APIs).

The good news here is that there are tools that will handle the conversion for you or (at the very least) identify your existing problems. You can, for example, right-click on your packages.config file and select a menu option to move your NuGet settings into your config file (some manual cleanup afterward will be required). As I’m writing this, there’s a migration document for .NET Core 3 that you can use as a guide (the .NET 5 document is still “under construction”).

We live in an agile world with tools and technologies that are constantly evolving. It makes sense that a new platform offers real benefits to start new projects on that platform (especially when the new environment looks so much like your old one). And, for the same reason that you should consider starting new projects on the new platforms, it also makes sense to move existing applications that see a lot of churn to the new platforms. Where there are performance and accessibility benefits available for the cost of migrating, it makes sense to move even stable applications. What you can’t do is ignore those new platforms.