Blazor WebAssembly Targets .NET 5 in Latest ASP.NET Core Update
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."
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 for Converge360.