Microsoft went open-source with the .NET framework on 27 June 2016, when it released .NET Core 1. Miguel de Icaza described .NET Core as a “redesigned version of .NET that is based on the simplified version of the class libraries.” And Microsoft’s .NET project manager, Immo Landwerth explained that .NET Core will be “the foundation of all future .NET platforms” because of its cross-platform support.
The next major release of .NET Core was .NET 5.0. This followed .NET Core 3.1. Microsoft named this release .NET 5.0 instead of .NET Core 4.0 for two reasons. Firstly, it was to avoid confusion with the .NET Framework 4.x. Secondly, it was to emphasize that this is the immediate implementation of .NET. Hence, “Core” was dropped from the name.
The .NET 5.0 release has more app and platform support than .NET Core, as well as the .NET Framework. It also has vast improvements compared to .NET Core 3.1.
Many people have talked about .NET 5 being Microsoft’s final step in its quest to rebuild .NET as a cross-platform, open-source project. Yet, .NET 5 is also the first step in Microsoft’s new release pattern. For the near future, Microsoft promises a new version of .NET annually, releasing each November.
With .NET 6 already in preview, we can see impressive features and improvements on .NET 5. It targets features that were not present in .NET 5, like a next-generation Xamarin. This lowers the barriers between desktop and native mobile development. It means better integration between the many different Windows UI toolkits. There are also many other considerable and smaller-scale enhancements in .NET 6. Microsoft has laid out point-by-point on its official .NET product roadmap.
There’s more information on the plans, changes, and challenges encountered with the current .NET 6 development on Microsoft’s Themes of .NET.
This article explores some of these fantastic new features anticipated in .NET 6 and explores some of the recommended plugins that will fit these changes and features well.
Xamarin.Forms is an open-source, cross-platform framework for building iOS, Android, and Windows applications with .NET from a single shared codebase. Mono engineers first developed it, and Microsoft acquired it in 2016.
It offers an alternative to WinUI for cross-platform development. Its cross-platform strategy is a mix of XAML support for native controls for iOS and Android. This is alongside its own cross-platform Xamarin.Forms. Xamarin.Forms is a Model-View-ViewModel (MVVM) development platform. It has built-in pages, mobile apps layouts, and controls that allow us to build applications with a single, highly extensible, API. It allows us to subclass and customize controls, layouts, pages, and cells to make our app pixel perfect.
.NET 6 uses the .NET Multi-platform App UI. It’s a modern UI toolkit built upon Xamarin. But, it has improvements and new features as part of .NET 6 unification. It gives us the ability to build applications that are deployable to multiple devices using a single project and single codebase with minimum overhead.
Using the .NET Multi-platform App UI, developers can deliver consistent app experiences across various platforms and devices. Mobile and desktop apps can use a single shared codebase to target Android, iOS, macOS, and Windows operating systems.
The .NET 6’s multi-platform mobile and cross-platform support integrate and extend the Xamarin.Forms toolkit. It also extends Xamarin.Essentials libraries to improve cross-platform UI controls. With MAUI, we can use several device capabilities. This includes device sensors, photos, contacts, authentication, and secure storage.
Building applications with .NET 6 is straightforward, as it comes with sample mobile projects and installation instructions. It also has a C# Hot Reload and existing XAML support for faster development experiences. Also, we can manage assets for platform-specific needs from a single place.
The changes and improvements in MAUI focus on improving app performance, user experience, control, and increasing development speed. Using UI plugins like ComponetOne in MAUI applications will make the development process faster. It will also improve the application user experience in addition to what .NET MAUI already has.
The Windows Presentation Foundation (WPF) is a resolution-independent UI framework. It uses a vector-based rendering engine built to take advantage of modern graphics hardware. It provides a comprehensive set of application-development features: Extensible Application Markup Language (XAML), data binding, 2D and 3D graphics, animation, templates, documents, media, text, and typography. WPF is part of .NET, so we can incorporate it with other elements of the .NET API with ease.
In .NET 6, Arm64 continues to be a big focus since its significant performance improvements compared to .NET 5. In contrast to .NET 5, .NET 6 focuses mainly on its functional enablement to make its performance seamless. It also supports Windows form and Windows presentation framework (WFP) out of the box in contrast to the support of WFP using x64 emulation in Windows on Arm devices as in .NET 5.
On Mac, Apple Silicon support is a key deliverable of .NET 6. The .NET development team has been working on enabling support for the Apple Silicon chip since it received Developer Transition Kits (DTKs) from Apple in 2020.
Support for Apple Silicon (Arm64) chips (native and emulated) was successful in .NET 6. But now, it only supports the console apps ASP.NET Core, Mac client apps (Mac and Mac Catalyst), and the .NET SDK. Apple built this using x64 emulation for .NET 5 and earlier .NET Core releases.
.NET 6 preview 1 recorded the first enablement of Apple Silicon. But, as advised by Microsoft, these builds can be considered alpha-quality at this stage. They still have several design issues to work through and significant validation to ensure a high-quality product.
Blazor has become a smart way to build .NET web applications. This is because of its seamlessness and ease of integration with UI libraries like ComponentOne. This makes the application development life cycle more efficient.
Blazor support for .NET was first on the server. Then it was in the browser with WebAssembly. Now, .NET 6 enables writing Blazor desktop apps. Blazor desktop lets you create hybrid client apps, combining web and native UI in a native client application. Its target is web developers who want to provide rich client and offline experiences for our users. These experiences can also be enhanced using UI libraries like ComponentOne.
Blazor desktop, in its default configuration, won’t use Blazor Web Assembly. This is because there is no apparent technical or user experience reason to use WebAssembly for a desktop app. Another .NET 6 improvement is Blazor WebAssembly performance.
Blazor desktop in .NET 6 offers a lot of choices to structure our applications. We can choose to use Blazor and other web technologies for all aspects of the client application experience except for the outer-most native application container (like the title bar). We can also use Blazor desktop for targeted functionality within an otherwise native app (like WPF), like a user profile page that we’ve already implemented for our Blazor-based website. All the choices in between are equally possible.
The .NET 6 team emphasized that they initially built Blazor desktop for .NET apps, but there is no technical reason why we can’t use Blazor in a desktop app built with another app stack. For example, we might use Swift.
Blazor desktop sits on top of the new .NET Multi-platform App UI. It relies on that UI stack for a native application container and native controls with excellent performance.
Blazor in .NET 6 has startup and throughput performance equal to other desktop solutions. For those of us that love web technologies, it’s an excellent choice for building desktop apps.
We can also anticipate performance improvements for .NET 6. According to Microsoft’s official blog, Microsoft is starting a new project called fast inner loop. The first part of the project is making the build run significantly faster with a set of performance-related projects. The second part is creating new systems that will enable skipping the build phase altogether.
Microsoft stated that they imagined implementing the Xamarin team’s innovation with the XAML Hot Reload feature to become a general .NET capability. It wouldn’t be just for XAML, but also for C# Intermediate Language.
The Microsoft .NET 6 development team clarified that containers are a daily focus of the group, both as the basis of the build infrastructure and as a product scenario. They noted that even current .NET performance testing uses containers. This is due to the multiple projects planned for improving containers in .NET 6. Some of these planned improvements include:
These features, excluding the first, are dependent on crossgen2, which is a replacement of the crossgen tool. They satisfy two outcomes: make crossgen development more efficient, and enable a set of capabilities that are not currently possible with crossgen.
One of the most significant benefits of containers is that .NET developers can build a more opinionated configuration than with .tar.gz, .deb, or .msi deliverables.
Alpine 3.13 (or later), Debian 11 (“bullseye”), and Ubuntu 20.04 will be the base for .NET 6 images. .NET will not support newer versions of Ubuntu (in containers) until Ubuntu 22.04.
The .NET 6 release will integrate seamlessly with platforms and development tools for better development and user experience.
Using GrapeCity ComponentOne UI controls in WPF, Blazor, and Xamarin applications in .NET 6 significantly shortens the development time of any project. It makes applications more robust, responsive, and scalable. These components currently integrate efficiently with all versions of .NET, and will integrate perfectly with .NET 6 when released. The GrapeCity team constantly works on new features to enhance development and user experiences.
Try GrapeCity ComponentOne UI controls for web apps in .NET and .NET applications. There is a 30-day free startup package with enough to get you started. Explore how GrapeCity can enhance the next .NET application.