Upcoming .NET version introduces updates to runtime, hardware, and asynchronous execution.
The consistent annual release schedule for .NET offers a strong framework for introducing fresh features and enhancing its core components. Freed from dependency on Windows updates, the project delivers consistent previews alongside essential bug and security patches. This enables users to anticipate future developments and test new functionalities. Concurrently, we can assess the impact of the forthcoming platform update on our existing codebase.
Expected in November 2026, the next significant iteration, .NET 11, has recently seen its initial public preview released. Similar to previous early glimpses, this version is far from complete, featuring several intriguing advancements designated as “foundational work not yet ready for general use.” Consequently, these elements are unavailable for experimentation in Preview 1. Development is ongoing and progress can be monitored on GitHub.
The primary appeal of this initial preview lies not in novel language capabilities (which will be detailed later in the year), but instead in .NET’s fundamental infrastructure: specifically, its compiler and runtime environment. The modifications present here hint at the strategic direction for this year’s release and suggest future deployment scenarios envisioned by the development team for .NET.
Updates for Android and WebAssembly
A significant modification planned for 2026 involves the transition of Android .NET applications from the Mono runtime to CoreCLR. While the contemporary .NET ecosystem originated from the open-source Mono initiative and currently employs its proprietary CoreCLR runtime, it previously relied on the legacy runtime for its WebAssembly (Wasm) and Android deployments.
Migrating to CoreCLR for Android enables developers to access identical features across all platforms, simplifying the assurance of consistent MAUI behavior regardless of its execution environment. The CLR team highlights that beyond enhanced compatibility, this shift will also yield performance gains, particularly in application startup durations.
Regarding Wasm, this transition is anticipated to further streamline the provision of unified Blazor support for both server-side and WebAssembly code, thereby simplifying the entire application development workflow. The initiative for this migration remains in its preliminary phases, with the initial SDK and interoperability tasks completed. Significant work remains before executing applications beyond “Hello World” using CoreCLR on Wasm and WebAssembly System Interface (WASI) becomes feasible. The objective is to incorporate RyuJIT support by the conclusion of the .NET 11 development period.
Complete support is slated for .NET 12; however, achieving a .NET runtime that is code-compatible with the broader .NET ecosystem for WebAssembly represents a considerable advantage for both environments. The WebAssembly CoreCLR functionalities in .NET 11 should be considered a preview, providing opportunities for diverse scenario testing and utilizing these trials to inform subsequent development.
Integrated capabilities for distributed systems
Among the more compelling new functionalities is one that seems to address evolving methodologies in code construction and deployment. While a significant portion of our development, particularly desktop applications, still operates on single machines, an increasing volume of code requires interaction with external APIs. Such code necessitates asynchronous execution to prevent API calls from impeding user experiences or device performance while an application awaits a remote server’s reply. This operational paradigm gains even greater importance for cloud-native applications, which frequently consist of loosely coupled microservices orchestrated by platforms such as Kubernetes or serverless functions on Azure or other cloud environments.
CoreCLR in .NET 11 is undergoing re-engineering to bolster its support for these increasingly vital design patterns. Previous iterations required explicit activation for runtime asynchronous capabilities within the CLR. However, in Preview 1, runtime async is enabled by default on CoreCLR; therefore, to evaluate your code’s interaction with this feature, you only need to install and integrate the preview components into your applications.
Currently, this novel functionality is restricted to proprietary code, as fundamental libraries are not yet compiled with runtime asynchronous support. This situation is set to evolve over the coming months as libraries are recompiled and integrated into subsequent previews. Third-party code will probably delay adoption until Microsoft issues a preview accompanied by a “go live” license.
To understand the advancement of this feature, one can consult what the documentation refers to as an “epic issue.” This resource details the feature’s present status and outstanding tasks. Development commenced during the .NET 10 cycle, leading to the completion of much foundational work. Nevertheless, several critical functionalities remain categorized as issues, including just-in-time support for multicore architectures and specific vital optimization methods, such as dynamic recompilation driven by profile-guided optimization in response to actual workloads.
It is crucial to recognize that such challenges constitute only a fraction of what must be accomplished for the successful implementation of runtime asynchronous support in .NET 11. Given the multiple months separating Preview 1’s introduction and the ultimate general availability release, the .NET team possesses ample time to finalize these components.
As this feature is still under development, enabling its support in ahead-of-time (AOT) compiled applications will necessitate configuring specific project file flags. This involves inserting a few lines into the project file and subsequently recompiling the application. Presently, it is advisable to build and test with AOT runtime async, followed by recompiling once you are prepared to explore the new functionality.
Modifications in hardware compatibility
A noteworthy point is that the refined .NET runtime in .NET 11 comes with updated hardware prerequisites, which might lead to incompatibility with legacy hardware. It demands contemporary instruction sets. Specifically, Arm64 now mandates armv8.0-a featuring LSE (armv8.2-a with RCPC for Windows and M1 for macOS), while x64 on Windows and Linux requires x86-64-v3.
This aspect could introduce breaking changes, as obsolete hardware will now trigger error messages and prevent code execution. For the majority of current PCs, devices, and servers, this should not pose a problem, given that these specifications align with .NET’s operating system support, rather than catering to increasingly uncommon older hardware. Nevertheless, if your .NET applications are running on hardware nearing end-of-support, an upgrade will be necessary, or you’ll have to continue utilizing older code for the foreseeable future.
Additional hardware platforms receive .NET support, with their respective runtimes provided externally. This encompasses compatibility for RISC-V hardware and IBM mainframes. Currently, these represent niche areas of interest: one facilitates migrations and updates for legacy enterprise software, while the other aims to deploy code on forthcoming open hardware architectures. It will be intriguing to observe whether RISC-V support achieves widespread adoption, given the rapid advancements in silicon performance and its existing presence in prevalent Internet of Things development boards and processors from entities like Raspberry Pi, where it forms part of the RP2350 microcontroller system-on-a-chip.
Such developments make examining the runtime documentation at the onset of a new .NET development cycle particularly insightful. Reviewing GitHub issues and notes provides a glimpse into the rationale behind .NET’s evolution, allowing us to leverage the project’s open design principles to strategize our software development efforts around code that will not reach general availability until later in the year.
Retaining a grasp of the foundational elements of a platform such as .NET remains crucial. Increased knowledge illuminates how numerous interconnected components converge to underpin our code. Comprehending how to best utilize compilers and runtimes to enhance performance, ensure reliability, and broaden reach proves highly beneficial.
Ultimately, this mirrors the ongoing work of the teams as they craft the languages we will employ to construct our applications, with .NET progressing through further previews, steadily advancing towards the ultimate release of .NET 11.
