Microsoft has almost made it to the finish line with .NET 5, their ambitious platform unification project. For the first time since 2016 — when Microsoft introduced .NET Core and created a parallel track for cross-platform development — all .NET applications will be back together under one roof.

Having one .NET is a huge step forward, but it doesn’t necessarily mean a developer’s life will be easy. There are plenty of overlapping technologies under the .NET 5 umbrella. Some old web stalwarts are finally gone — in particular, both ASP.NET MVC and ASP.NET Web Forms are officially dead. But there are still three different, fully supported .NET models for building desktop Windows applications, which Microsoft is slowly trying to unite. Even a hot new technology like Blazor exists in two flavors (a server-side version that uses real-time communication with SignalR, and the more popular client-side version that uses WebAssembly to run C# in the browser).

The problem is particularly bad if you’re searching for the Holy Grail of rich client development: cross-platform UI. Google has Flutter. But what does Microsoft offer developers who want to design an application once, then compile it to run natively on different devices, with no web browser required?

For years the answer was “not much.” But now there’s a new project that might patch the gap, called .NET MAUI. The only catch is that it won’t be ready for .NET 5.

Let’s take a closer look.

The state of the app in .NET 5

Today, if you’re a business developer planning an application with .NET 5, you have a small set of choices. You can choose to build:

• A server-side web application with ASP.NET Razor
• A browser-based application with Blazor
• A Windows desktop application using Windows Forms, WPF, or UWP
• A mobile (iOS and Android) application using Xamarin

There are bridges between some of these options, but for the most part they are non-overlapping magisteria — in other words, you pick an island, and you stay there.

Developing for different platforms in .NET 5

If you choose to create a Razor or Blazor application (the first two options), you have unlimited reach, but you’re trapped in a web browser. There are a couple of early experiments that take Blazor out of the browser and make it look like a traditional desktop application (like Electron does) or link it to Xamarin’s mobile controls for a native UI experience. But as every developer eventually learns — often painfully — experiments aren’t a proper foundation for professional apps.

If you choose the third option (WPF, WinForms, or UWP), your app is limited to the Windows operating system. That’s fine if you need Windows-specific features (you know who you are), but you’ll have zero reach to other platforms.

The fourth option (Xamarin) is more complicated. Xamarin was created outside the company, then bought by Microsoft in 2016. It offers a toolkit called Xamarin.Forms that lets you create apps that run on iOS, Android, and UWP using a single codebase. You program with a high-level abstraction of widgets and features that maps down to native controls and device-specific functionality. But you can see the seams — juggling the franken-project structure is awkward, Visual Studio design support is spotty, and there’s no support for macOS.

(Here’s a quick side note before we move on: There is one more option that works today but isn’t a part of .NET. The open-source Uno Platform lets you write cross-platform apps built in C# and XAML, leveraging Xamarin and WebAssembly. It’s an excellent product. But without Microsoft’s official support it’s likely limited to being a niche project, much like Mono was before Microsoft acquired Xamarin.)

#microsoft #dotnet #csharp #programming #xamarin