ASP.NET Core .NET 8 Preview 1: New Features and Updates

ASP.NET Core has received updates in .NET 8 Preview 1, including Blazor United, improved route tooling, and HTTP/3 enabled by default. In this article, we will take a closer look at these features!

Route Tooling

Routing is a fundamental part of building web applications with ASP.NET Core. In .NET 8 Preview 1, the route tooling has received several new features that make it easier to work with and learn. These features include:

• Syntax highlighting for routes
• Autocomplete for parameter and route names
• Autocomplete for route constraints
• Route analyzers and fixers

One of the most exciting things about the new route tooling is that it’s built on Roslyn, which means it automatically adapts to the IDE that you’re using. This makes it incredibly easy to use, regardless of whether you prefer Visual Studio, VS Code, or another IDE.

The new route tooling supports Minimal APIs, Web APIs, and Blazor, which means you can use it to build a wide range of web applications. The route tooling is designed to help you catch and fix common routing issues, and it’s available in all of the major IDEs that support ASP.NET Core development.

Sure, here’s an updated version of the “Route constraint performance improvements” feature description that includes a modified code example:

Route Constraint Performance Improvements

Routing is a powerful and high-performance technology used by almost all ASP.NET Core apps, and route constraints are a commonly used feature of routing that helps match requests to the right endpoint. In .NET 8, several performance improvements have been made to constraints to maximize runtime performance and reduce startup time and memory use:

Loading code snippet...

In this example, a regex constraint is used to ensure that the “name” parameter matches a specific pattern. In .NET 8, several performance improvements have been made to constraints:

• Regex constraints are now compiled, which improves runtime performance. Compiled regexes have a one-time cost at startup, but subsequent matches are faster.
• Duplicate constraints are now shared between routes, which reduces startup time and memory use. If multiple routes use the same constraint, it only needs to be compiled once and can be shared across all the routes.
• The alpha constraint now uses a source generated regex, which improves performance. This constraint matches any alphabetic character and uses a source-generated regular expression.

These improvements make it even easier and more efficient to build high-performance web applications with ASP.NET Core in .NET 8.

New Analyzers for API Development

Developers know that high-quality code is easier to debug, test, and maintain. In .NET 8, Microsoft has introduced a suite of new analyzers that provide warnings and recommendations to improve the quality of ASP.NET Core APIs.

One of the new analyzers recommends setting or appending to a HeaderDictionary instead of using the IHeaderDictionary.Add API, which can throw an exception if duplicate keys are added. Instead, developers can leverage the indexer or the IHeaderDictionary.Append API to set, override, or append to a header. Here’s an example of using IHeaderDictionary.Append:

Loading code snippet...

Another analyzer warns if a parameter type passed to a route handler does not implement the correct interfaces. For example, the Customer type in the code below will trigger a warning because it does not implement a BindAsync method with the correct signature:

Loading code snippet...

This warning helps developers ensure that their APIs are robust and that the appropriate interfaces are implemented for proper operation.

Finally, the RequestDelegate analyzer detects if a RequestDelegate is implemented incorrectly. This analyzer ensures that the response of the RequestDelegate is not discarded at runtime and recommends the use of c.Response.WriteAsync or minimal APIs instead. Here’s an example of using c.Response.WriteAsync:

Loading code snippet...

These new analyzers are a valuable addition to the ASP.NET Core development experience, helping developers create high-quality code that is easier to debug, test, and maintain. Microsoft would like to thank the community members who contributed to these analyzers and helped improve the ASP.NET Core development experience.

Blazor WebAssembly Debugging in Firefox

Debugging Blazor WebAssembly apps is now possible using Firefox, thanks to the latest updates in .NET 8 Preview 1. Debugging Blazor WebAssembly apps requires configuring the browser for remote debugging and then connecting to the browser using the browser developer tools through the .NET WebAssembly debugging proxy. At this time, debugging Firefox from Visual Studio is not supported.

To debug a Blazor WebAssembly app in Firefox during development, follow these steps:

• Open the Blazor WebAssembly app in Firefox.
• Open the Firefox Web Developer Tools and go to the Console tab.
• With the Blazor WebAssembly app in focus, type the debugging command SHIFT+ALT+D.
• Follow the instructions in the dev console output to configure Firefox for Blazor WebAssembly debugging:
• In the new Firefox instance, leave the about:debugging tab open and open the Blazor WebAssembly app in a new browser tab.
• Type SHIFT+ALT to open the Firefox Web Developer tools and connect to the Firefox browser instance.
• In the Debugger tab of the Web Developer Tools, open the app source file you wish to debug under the file:// node and set a breakpoint. For example, set a breakpoint in the IncrementCount method of Pages/Counter.razor.
• Navigate to the Counter page and click the counter button to hit the breakpoint.

These steps enable you to debug your Blazor WebAssembly app in Firefox using the Web Developer Tools. This is a valuable addition to the Blazor WebAssembly development experience and helps developers debug their apps more easily.

Experimental Webcil format for .NET assemblies

In some environments, firewalls and anti-virus tools block the download or use of .dll files, which prevents the use of web apps based on .NET assemblies, like Blazor WebAssembly apps. To address this issue, the wasm-experimental workload now supports a new .webcil file format that can be used to package .NET assemblies for browser-based web apps. This is a valuable addition to the .NET ecosystem as it helps developers deploy apps more easily in environments where .dll files are blocked.

To try out the new Webcil format with a WebAssembly Browser App, follow these steps:

• Install the wasm-experimental workload: dotnet workload install wasm-experimental

• Create a new app: dotnet new wasmbrowser

• Add the WasmEnableWebcil property to the .csproj file

Loading code snippet...

• Run the app and verify in the browser’s DevTools that .webcil files are being downloaded, not .dll files.

The Webcil format is currently only available for the experimental WebAssembly Browser Apps, but Microsoft plans to enable it for Blazor WebAssembly apps in a future update. If you encounter issues with using .webcil files in your environment, please let Microsoft know by creating an issue on GitHub.

Specify initial URL for

The new StartPath property on BlazorWebView allows you to set the path to initially navigate to. This is useful when you want to take the user straight to a specific page once the BlazorWebView is loaded.

Loading code snippet...

New option to keep the SPA development server running

When building a single-page app (SPA) with ASP.NET Core, both the SPA development server and the backend ASP.NET Core need to execute during development. The SPA development server is configured to proxy API requests to the ASP.NET Core backend.

When the ASP.NET Core process is terminated, the SPA development server is by default terminated as well. Restarting the SPA development server can be time consuming and cumbersome.

The new KeepRunning option on SpaDevelopmentServerOptions enables leaving the SPA development server running even if the ASP.NET Core process is terminated.

Loading code snippet...

Support for named pipes in Kestrel

Named pipes is a popular technology for building inter-process communication (IPC) between Windows apps. You can now build an IPC server using .NET, Kestrel, and named pipes.

Loading code snippet...

For more information about this feature and how to use .NET and gRPC to create an IPC server and client, see Inter-process communication with gRPC.

HTTP/3 enabled by default

HTTP/3 enabled by default:

HTTP/3 is a new internet technology that offers several advantages over older HTTP protocols, including faster connection setup, no head-of-line blocking, and better transitions between networks. In .NET 7, support for HTTP/3 was added to ASP.NET Core and Kestrel, but in .NET 8, it is enabled by default alongside HTTP/1.1 and HTTP/2.

Some key points about HTTP/3 in .NET 8:

• Enabled by default in ASP.NET Core and Kestrel.
• Faster connection setup and no head-of-line blocking.
• Better transitions between networks.
• Supports HTTP/1.1 and HTTP/2.
• Enables clients to use QUIC instead of TCP for transport.

Code example:

To enable HTTP/3 in a .NET 8 project, you can use the following code in your ASP.NET Core app:

Loading code snippet...

In the above example, we are using the UseKestrel method to configure Kestrel as the web server and Listen to specify the IP address and port to listen on. The HttpProtocols.Http3 option is used to enable HTTP/3.

Note that this example assumes you have already added the necessary packages for HTTP/3 support, such as the Microsoft.AspNetCore.Server.Kestrel.Https package.