News
Blazor WebAssembly Targets .NET 5 in Latest ASP.NET Core Update
In announcing updates to web-focused ASP.NET Core development as part of a new .NET 5 Preview 7, Microsoft noted that Blazor WebAssembly -- the client-side component of the Blazor project that allows for C#-based web development instead of JavaScript -- now targets .NET 5.
After suffering some development delays, Blazor WebAssembly recently joined the Blazor Server server-side component. Both parts of the Blazor project are headed for inclusion in .NET 5, a unifying all-things-.NET release scheduled for November.
To meet that deadline, Microsoft recently shipped .NET 5 Preview 7, the penultimate numbered preview before the arrival of two release candidates (RCs) that will feature "go live" production code.
As most .NET 5 code is pretty much done, the main "what's new" highlight for ASP.NET Core updates in Preview 7 concerned Blazor WebAssembly apps now targeting .NET 5.
"Blazor WebAssembly 3.2 apps have access only to the .NET Standard 2.1 API set," explained Sourabh Shirhatti in a July 21 blog post. "With this release, Blazor WebAssembly projects now target .NET 5 (net5.0) and have access to a much wider set of APIs. Implementing Blazor WebAssembly support for the APIs in .NET 5 is a work in progress, so some APIs may throw a PlatformNotSupportedException at runtime. We'd love to hear from you if you're blocked by the lack of support for specific APIs."
Also cited were Blazor performance and accessibility improvements, along with updated debugging requirements for Blazor WebAssembly when using the open source, cross-platform Visual Studio Code editor. Now developers don't have to manually install a JavaScript debugger, because it's now included with VS Code. Enabling the preview version is still required, however.
Other notes of interest regarding ASP.NET Core updates in .NET 5 Preview 7 include:
- Certificate authentication performance improvements: The team added caching to certificate authentication in ASP.NET Core, which significantly improves the performance of certificate authentication.
- Sending HTTP/2 PING frames: Developers can now send periodic PING frames in Kestrel by setting limits on KestrelServerOptions. HTTP/2's mechanism for sending PING frames can ensure whether an idle connection is still functional.
- Support for additional endpoints types in the Kestrel sockets transport: Building upon new API introduced in System.Net.Sockets, the sockets transport (default) in Kestrel now enables developers to bind to both existing file handles and unix domain sockets.
- Custom header decoding in Kestrel: The team added the ability to specify which System.Text.Encoding to use to interpret incoming headers based on the header name instead of defaulting to UTF-8.
Several other minor improvements were also listed, with developers invited to give feedback here.
About the Author
David Ramel is an editor and writer at Converge 360.