.NET 6

The .NET framework has been around since the year 2000. Over the years, it has grown into a very mature, popular framework that could target many platforms. However, sharing code between those different platforms was not an easy task because of how the .NET framework was built. With .NET Core, Microsoft wanted to start from a clean slate using .NET Standard as a way to share code between the different platforms. They took the API surface of the base class library and started implementing everything anew, using modern techniques and APIs to improve performance of the framework. .NET Standard was created as an interface. It exposed parts of the BCL API; .NET Core is an implementation of that .NET Standard interface. Because .NET Standard was an abstraction, we could create .NET Standard class libraries that could be referenced from every type of platform, as long as they used the correct version of .NET Core. This quickly became confusing as .NET Core 3 was using .NET Standard 2.1, but .NET Standard 1.6 was .NET Core 1.0. The next step in unifying all of .NET was taken with .NET 5. .NET 5, which was actually .NET Core 4, was the release where .NET Core became the successor of the classic .NET Framework. The final release of the classic .NET Framework is 4.8; from that moment on, .NET Core is the main branch of the framework. To avoid confusion, later on .NET Core was renamed to simply .NET and the versioning of the classic .NET framework was taken over, hence .NET 5. .NET Standard disappeared as well; as of .NET 5, we just have .NET 5 class libraries and those are compatible with every platform that is on .NET 5. .NET 6 is one of the final steps in unifying the platform as it unifies Mono and .NET, fulfilling the “one .NET” dream.

Version Support

First and foremost, .NET 6 is a Long Term Support release (LTS), meaning it will receive updates for the coming 3 years (up until, and including, 2024). Non-LTS versions are supported for 1 year, usually up to 3 months after the next LTS version release.

So how do we recognize LTS versions from non-LTS versions? Simple. Every odd numbered release (.NET 5, .NET 7, etc.) will be a non-LTS release and every even numbered release (.NET 6, .NET 8, etc.) will be an LTS release (Figure 1-1). The current release cadence Microsoft has set for .NET is a new release every year around November. This release cadence was introduced with .NET 5.

Why is this important? If you’re starting a new software project, it’s important to know that the underlying framework will not cause any security risks. No software is bug-free, so bugs and security risks will show up over the lifetime of any software; .NET is no exception. Writing your software using a version of .NET that will receive patches and updates for the coming years ensures that vulnerabilities and bugs in the framework get patched instead of potentially make your application crash, or vulnerable for attacks.

Does this mean that we can forget about the odd-numbered releases, since they are only supported for about a year? Not necessarily, it all depends on the context around the software you’re developing. If you’re building software that will still be in active development by the time of the next .NET LTS release, it can easily be included in the backlog to upgrade to the next version once it lands. If you’re building software that will be delivered in the current non-LTS timeframe and there’s no maintenance planned on the software, make sure your customer knows about the support. So, as usual it depends. Luckily, upgrading to a next release usually isn’t very difficult. If you are in a consultant role, set the correct expectations to your customer.

Supported Versions

All details concerning support for .NET can be found in the official .NET Support Policy found at https://dotnet.microsoft.com/platform/support/policy/dotnet-core.

A Unified Platform

From the very start, .NET Core was meant to be cross-platform and cross-idiom. Its purpose was to bring a bunch of separate, .NET-based technologies together under one umbrella. Before .NET Core, we could do different styles of apps, but not all of those were part of .NET, for example, Mono, the open-source .NET implementation for Linux- and Unix-based systems and Xamarin, the native mobile .NET solution built on Mono.

.NET Core 3 shifted the unification of .NET into high gear by adding Windows Presentation Foundation (WPF) and Windows Forms (WinForms) support into the framework. .NET 5 expanded on this work by adding Mono; the work on Mono brought .NET into the WebAssembly world. Blazor WebAssembly was the first result of this unification. With Blazor WebAssembly, we got native .NET running in the browser, using Mono. More information on Blazor can be found in Chapter 5 of this book. .NET 6 delivers the fully realized unified vision by including Xamarin as a part of .NET instead of a separate framework.

Xamarin is no longer the mobile platform that happens to look like .NET. It’s now a part of the framework, using .NET class libraries and .NET SDK tools to provide a great developer experience. A quick example of this is being able to use dotnet new ios or dotnet new android followed by dotnet build or dotnet run. As a result, you’ll see a mobile project being created, compiled and running on either a physical device or emulator. This is the result of work that started back in .NET 5, by bringing Mono into .NET.

We’ll dive deeper into Xamarin in the MAUI chapter of this book.

Roadmap

Microsoft made the decision to openly develop .NET, something they’ve done since .NET Core. That means that the backlog for .NET 6, and future versions, is visible to everyone. There’s even a Blazor-based web application that shows an overview of what’s proposed, what’s in progress, and what’s been completed. The website can be found at https://themesof.net/, and because everything happens out in the open, the Blazor web app’s source code is available at https://github.com/terrajobst/themesof.net.

Supported Operating Systems

The above tables list supported operating systems, versions, and architectures at the time of writing. The most up-to-date version of this list for .NET 6 is available at https://github.com/dotnet/core/blob/main/release-notes/6.0/supported-os.md.

Command Line Interface

.NET ships with a powerful Command Line Interface (CLI) tooling system since .NET Core. With the .NET command line, we can do things like creating a new project, installing tools and templates, running tests, compiling, and much more. While most of the CLI commands are rarely used manually, we can use them to script build and deploy automation. Tools like Azure DevOps or GitHub actions have full support for these commands.

Before we use the CLI, we have to install .NET 6 on our machine. If you have Visual Studio 2022 installed, you might already have it up and running.

We can see what version of .NET we are currently running by opening up a Powershell prompt and executing dotnet –-version.

If you get another version, maybe from .NET 5, you can download the .NET 6 installer from https://dotnet.microsoft.com/download/dotnet/6.0. Make sure to download and install the SDK to get the command line tooling.

Once .NET 6 is installed, we can see what project templates we have by executing dotnet new. The tooling will list all available options if we don’t specify a specific template as shown in Figure 1-4. The contents of this list depend of course on the different workloads and templates you have installed on your system.

Let’s try to create, build, and run a .NET 6 WinForms application without any help from an IDE.

First we create the project by selecting the correct dotnet new template.

TargetFramework is set to net6.0-windows, so we’re running on .NET 6 using the Windows compatibility pack. The compatibility packs are explained in more detail in Chapter 2. For now it means that we are running on .NET 6 but referencing some extra binaries so we can hook into the native Windows APIs, for example, to render our application or access the filesystem. Next step, let’s build the project through dotnet build.

I first made sure my command line was set in the directory where the .csproj or .sln file lives. If this is the case, a simple dotnet build suffices. The tool looks for a .csproj or .sln in its current directory and starts building it. What is happening right now is the exact same thing that happens when we build a project in Visual Studio. We call the .NET build system MSBuild and pass in parameters and a reference to a project, and it will start building. Once it is done building, you will find the familiar bin and obj folders in the project folder that you will also find after building from Visual Studio. There is no extra magic happening in Visual Studio; it triggers the same command we just executed manually.

As a final step, we execute dotnet run which will effectively build the project if necessary and launch it, showing a blank WinForms page as shown in Figure 1-7.

We’ll get deeper into the command line in Chapter 3 of this book.

Desktop Development

The desktop to this day remains a very important target for applications. Not every type of application is suited to be a web application. That’s why Microsoft brought WPF and WinForms back into active development with the release of .NET Core 3. Not only that, but they are also expanding the possibilities for desktop developers.

Before they brought WPF and WinForms back, however, they were considered legacy. It was time for a new modern desktop application framework. The Universal Windows Platform saw the light of day years ago as the cross-device Windows app framework. It promised a “build once, run everywhere” experience, and they mostly delivered. But since UWP was mostly targeted at mobile experiences through Windows on tablets and phones, it kept lacking in features to make it a true successor to WPF. Today UWP has matured into a decent application framework that can deliver modern, fast applications, but it still does not have all features WPF has.

To close this gap, Microsoft has introduced the Windows App SDK. The Windows App SDK aims to bring all desktop development options closer together. The Windows App SDK brings a set of Windows APIs that are decoupled from Windows itself. The APIs are released via NuGet packages so that they can be updated out of band with the operating system.

The Windows App SDK consists of a few parts. One of the major parts is WinUI 3. WinUI 3 decouples the XAML-based UI controls of UWP from the framework and makes them available as NuGet packages. This makes it possible for Microsoft to update their control library apart from the operating system. It also makes it possible for application developers to support newer UI features on older versions of Windows, without the need of operating system upgrades.

Getting started with The Windows App SDK can be done in a few different ways, which we’ll get deeper into in Chapter 4. The fastest way to get into Project Reunion is by using the WinUI templates in Visual Studio.

The Blank App, Packaged template creates a new UWP project, including a package manifest for distribution through the Microsoft Store. Figure 1-9 shows the newly created solution.

If you’ve ever built a UWP app, you might not see any difference at first sight. However, under the hood all the XAML controls this app is using are coming from a NuGet package, not from the UWP SDK like it used to. Have a look at the dependencies shown in Figure 1-13.

Figure 1-10 shows that the Windows SDK is still referenced; we still need that for all the system calls, like creating the app’s window and drawing everything on screen. The controls however all come from the Microsoft.WindowsAppSDK NuGet package.

An easy way to discover all the controls available in WinUI is by browsing the control gallery app available on the Windows Store www.microsoft.com/store/productid/9P3JFPWWDZRC.

The source code of the gallery app is available at https://github.com/Microsoft/Xaml-Controls-Gallery/.

The Control Gallery Sample App is not only a demo application, but it provides XAML snippets and links to official documentation for every control in the toolkit.

Blazor

Blazor is Microsoft’s answer to front-end web frameworks like Angular, Vue, and React. Its main selling point is that you can write these web apps in C# rather than JavaScript. You can still inject JavaScript and consume JavaScript libraries where you need to, but everything can basically be done through C#.

Source: https://webassembly.org

Like the official description says, Wasm is a virtual execution environment in your browser. Wasm is an official W3C spec https://www.w3.org/wasm/.

Since Wasm is an environment that runs native code, Microsoft was able to get a version of .NET running inside of Wasm. With this, Blazor Wasm was born.

.NET 6 brings Blazor to the desktop. With Blazor Desktop, we can build hybrid applications, parts can be native UI, and parts can be web UI. It’s not unlike Electron, but it differs in that applications can actually be, for example, part WPF and part web. Figure 1-13 shows a Blazor Desktop application that mixes native WPF controls with a Blazor Web Component.

As you can see in Figure 1-13, Blazor Desktop goes beyond just mixing two UI stacks. The data is shared between them. The counter increment button is web UI, while the button to see the counter value and the message box showing the value are both native Windows UI through WPF. This enables a very interesting scenario where parts of a web application can be refactored into web components to be used on both a web application and a native application.

We’ll learn more about Blazor in Chapter 5 of this book.

MAUI

WPF, WinForms, and the Windows App SDK are all tightly coupled to Windows. A more cross-platform solution from Microsoft is called the .NET Multi-Platform App UI. The .NET Multi-Platform App UI, MAUI for short, is one of the biggest new parts in .NET 6. It basically is the new version of Xamarin Forms, but it’s more than that. MAUI brings an entire new project system, no longer fiddling around with at least three projects in your mobile app solution. One project that contains all your mobile heads, assets, and shared code. Everything together in one .NET project.

MAUI no longer focuses solely on mobile either; it’s now a full-fledged solution for building cross-platform, cross-idiom applications. Xamarin Forms has had support for UWP for quite some time, but it was never an important part of the framework, which resulted in a poor developer and user experience. With MAUI we can target Android, iOS, macOS, and Windows. All as first-class citizens. For Windows, this means improved UWP support, by leveraging the Windows App SDK.

As for XAML flavor, if you’re building a cross-platform application with MAUI, you’ll be using the same flavor of XAML you’re used to from Xamarin Forms. As for macOS, Xamarin Forms has support for macOS through AppKit bindings; that support is still there.

Apple is now taking a different route for macOS development and has introduced Mac Catalyst, a framework that enables developers to build macOS desktop applications with UIKit. MAUI includes bindings for both AppKit and Mac Catalyst to suit every developer’s needs. However, since Mac Catalyst is the default for Apple, MAUI also takes this as the default framework for macOS-based applications.

Getting a Xamarin Forms installation up and running has been notoriously hard so far. It’s one of the most heard complaints from developers trying to get into Xamarin. You’d need to install Visual Studio with the correct mobile workload and install the correct UWP SDK versions, Android SDK version, and iOS SDK versions. Next to that, if you want to build iOS apps on Windows, you’ll need a mac with the correct version of Visual Studio for Mac, Mono, and iOS SDK installed. With .NET 6 comes a tool that can check your system for MAUI compatibility and install all missing pieces for you. In pure .NET fashion, it’s a command line tool that you can install through the dotnet command line.

Running the tool will launch it in a new CLI window.

The tool is community supported and open source; the source can be found at https://github.com/Redth/dotnet-maui-check.

We’ll dive deeper into MAUI in Chapter 6 of this book.

Wrapping Up

In this introductory chapter, we reviewed .NET roadmap and its history. I hope this chapter gave you a sense of what .NET 6 is about and made you eager to dive deeper into the latest release of .NET. The different concepts that we have touched upon in this chapter will be explored further in the rest of the book. We will take a closer look at .NET tooling with the command line interface; we will explore desktop development in WPF, WinForms, and the Windows App SDK. We will learn about building powerful web applications that run on the client with Blazor and how to build cross-platform mobile apps with MAUI.

While not an exhaustive list of everything .NET 6 offers, we have selected the most important parts of .NET 6. .NET 6 is a big and important release; it brings a plethora of new features and new paradigms to the framework. Consequent chapters in this book will cover many of those and go into much more detail. Before we dive into all the feature goodness, let’s take a look under the hood in Chapter 2 and explore the various runtimes and extensibility packs.