News

.NET 8 Preview 1: Native AOT Upgrade and the New 'Blazor United'

Microsoft today shipped the first preview of .NET 8, for which the company touted polishing of native Ahead-of-Time (AOT) compilation, and, on the web-dev side, the new Blazor United project that melds mix-and-match server-side and client-side rendering functionality.

While native AOT -- or NativeAOT, as Microsoft calls it -- was introduced in .NET 7 (see the Visual Studio Magazine article, ".NET 7 Preview 3 Is All About Native AOT"), the dev team will devote more work to it for the November release of .NET 8, such as reducing app size.

"Publishing app with Native AOT creates a fully self-contained version of your app that doesn't need a separate runtime because everything is included in a single file," said Microsoft's Jeremy Likness in an "Announcing .NET 8 Preview 1" post. "As of preview 1, this single file is smaller. In fact, Linux builds are now up to 50% smaller."

Microsoft has been all over native AOT in the wake of a survey a few years ago wherein respondents indicated its absence was holding back .NET adoption.

Does the lack of officially supported native AOT option prevent you from using .NET more?
[Click on image for larger view.] "Does the lack of officially supported native AOT option prevent you from using .NET more?" (source: Microsoft).

Microsoft listed the benefits of native AOT as:

  • Reduced memory footprint: AOT compiled code requires less memory compared to JIT compiled code, as the JIT compiler generates intermediate code that is not needed in AOT compiled applications. This can be especially beneficial for devices with limited memory, such as embedded systems and mobile devices.
  • Improved startup time: AOT compiled code starts up faster compared to JIT compiled code, as it eliminates the need for the JIT compiler to generate intermediate code and optimize the code for the specific hardware and software environment. This can be especially beneficial for applications that have to start up quickly, such as system services, serverless "functions" and background tasks.
  • Improved battery life: AOT compiled code consumes less power compared to JIT compiled code, as it eliminates the need for the JIT compiler to generate intermediate code and optimize the code for the specific hardware and software environment. This can be especially beneficial for devices that rely on batteries, such as mobile devices.

Meanwhile, ASP.NET Core principal program manager Daniel Roth penned his own post on what his team is doing, starting out with a Steve Sanderson prototype project he dubbed "Blazor United" (see the article, "ASP.NET Core Dev Team Launches 'Blazor United' Push for .NET 8").

"In .NET 8 we're working to combine the benefits of server-side and client-side rendering into a single full-stack programming model based on Blazor," Roth said. "We're currently calling this effort 'Blazor United.' Blazor United will enable you to use a single Blazor-based architecture for server-side rendering and full client-side interactivity with Blazor Server or WebAssembly. That's all within a single project with the ability to easily switch between different rendering modes and even mix them in the same page. Blazor United will also enable new rendering capabilities, like streaming rendering and progressive enhancement of navigations and form posts."

He also addressed native AOT for web developers: ".NET 7 introduced support for publishing .NET console projects as native AOT, producing a self-contained, platform-specific executable without any runtime JIT. Native AOT apps start up very quickly and use less memory. The application can be deployed to a machine or container that doesn't have any .NET runtime installed. In .NET 8 we will extend support for native AOT to ASP.NET Core, starting with cloud-focused, API apps built with Minimal APIs that meet expectations regarding published file size, startup time, working set, and throughput performance."

Along with his discussion of native AOT, Likness also highlighted other general .NET 8 work concerning container images, JSON improvements, Linux support and much more. Everything is detailed in the new "What's new in .NET 8" documentation.

Blazor Roadmap
[Click on image for larger view.] Blazor Roadmap (source: Microsoft).

As far as the nitty-gritty details of ASP.NET Core improvements, interested readers can consult the ASP.NET Core Roadmap for .NET 8, which is dominated by a whopping 24 items for Blazor, topped by Blazor United, as shown in the screenshot above.

Microsoft's busy raft of shipments also includes Visual Studio 2022 v17.5, Visual Studio for Mac 17.5 and EFCore 8 Preview 1, along with a post addressing Visual Studio 2022 version 17.5 for C++ Developers.

About the Author

David Ramel is an editor and writer at Converge 360.

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube