WebAssembly steals the show from ASP.NET Core in .NET 7 RC1 – Visual Studio Magazine

New

WebAssembly steals ASP.NET Core show in .NET 7 RC1

WebAssembly, the open-source technology that powers client-side Blazor, was the star of the ASP.NET Core show in the new .NET 7 Release Candidate 1.

Sometimes abbreviated to Was Mit provides a portable compilation target for C# code in client-side Blazor WebAssembly, freeing Microsoft-centric web developers from the pervasive constraints of JavaScript when working on browser-based web applications.

As a key foundational technology of the Blazor project that is part of ASP.NET Core, it received the lion’s share of attention in a recent development from Microsoft. Publish on ASP.NET Core updates in the September 14 .NET 7 RC1 release. WebAssembly updates cover ASP.NET Core areas, including debugging and authentication, as well as .NET build tools and JavaScript interop.

Here’s a summary of WebAssembly updates for Blazor WebAssembly and .NET 7.

  • Dynamic authentication requests in Blazor WebAssembly: To handle advanced authentication scenarios in Blazor WebAssembly apps, developers can now create dynamic authentication requests at runtime with custom parameters as part of out-of-the-box authentication support. existing job that leverages OpenID Connect and several Azure-based identity providers.
  • Blazor WebAssembly debugging improvements: A host of updates here include:
    • Support for Just My Code parameter to show or hide type members that are not from user code
    • Support for inspecting multidimensional arrays
    • Call Stack now shows the correct name for asynchronous methods
    • Improved expression evaluation
    • Correct handling of new derived member keyword
    • Support for debugger-related attributes in System.Diagnostics
  • .NET WebAssembly build tools for .NET 6 projects: A new wasm-tools-net6 workload resolves incompatibility issues between .NET 6 and .NET 7 projects. It is an add-on to the existing wasm-tools workload, which installs the .NET WebAssembly build tools for .NET 7 projects. However, these build tools are incompatible with existing projects built with .NET 6, so developers can turn to the wasm-tools-net6 workload in order to use the .NET WebAssembly build tools with a .NET 6 project when working with the .NET 7 SDK. Thus, multi-targeting will be required for projects using the .NET WebAssembly build tools that must support both .NET 6 and .NET 7.
  • .NET JavaScript Interoperability on WebAssembly: Another workload is introduced for new experimental models: wasm-experimental. “.NET 7 introduces a new low-level mechanism for using .NET in JavaScript-based applications,” Microsoft explained. “With this new JavaScript interop capability, you can also invoke .NET code from JavaScript using the .NET WebAssembly runtime [as] call JavaScript functionality from .NET without any dependency on the Blazor UI component model.”

    The developers install the new experimental workload with this command:

    dotnet workload install wasm-experimental

    “This workload contains two project templates: WebAssembly Browser App and WebAssembly Console App,” Microsoft explained. “These templates are experimental, which means the developer’s workflow for them hasn’t been fully sorted out yet (for example, these templates don’t run in Visual Studio yet). But the .NET and JavaScript APIs used in these templates are supported in .NET 7 and provide a foundation for using .NET over WebAssembly from JavaScript.”

Blazor roadmap for .NET 7
[Click on image for larger view.] Blazor roadmap for .NET 7 (source: Microsoft).

As shown in the graphic above that illustrates the Blazor section of the ASP.NET Core roadmap for .NET 7, Blazor comes to the fore, with the most items. As can be seen, while things like “Dynamic and Extensible Authentication Requests” (discussed above) have been adopted and marked with purple checkmarks (as well as “Developers targeting the browser-wasm can use the execution of Web Crypto APIs”, which is not discussed in the announcement post), other items yet to be covered range from “Real multithreading (on supported browsers)” to “Ability to run multiple applications Blazor server / web assembly in the same document”.

Other ASP.NET Core improvements
While the ASP.NET Core development team was definitely focused on improving WebAssembly functionality in .NET 7 RC1, other highlights included:

  • Manage location change events
  • Comprehensive Kestrel certificate chain improvements
  • Faster HTTP/2 downloads
  • HTTP/3 improvements
  • Experimental Kestrel support for WebTransport over HTTP/3
  • Experimental OpenAPI support for gRPC JSON transcoding
  • Rate-limiting middleware improvements
  • Improvements to macOS developer certificates
ASP.NET Community Standup - Blazor in .NET 7 Part II
[Click on image for larger view.] ASP.NET Community Standup – Blazor in .NET 7 Part II (source: Microsoft).

More details on all of the above can be seen in the announcement post and a recent ASP.NET Community Standup online video featuring Blazor in .NET 7 Part IIshown above.

Complete ASP.NET Core Roadmap for .NET 7
Meanwhile, the team is giving an overview of all the ASP.NET Core work planned for .NET 7 in the ASP.NET Core Roadmap for .NET 7 on GitHub, which separates work items into categories for ASP.NET Core Runtime, ASP.NET Web Frameworks, and ASP.NET Web UI.

Complete ASP.NET Core roadmap
[Click on image for larger view.] Complete ASP.NET Core Roadmap for .NET 7 (source: Microsoft).

As noted above, Blazor and WebAssembly elements dominate this latter category, although Blazor Hybrid also has a good amount of upcoming work, which you can read more about in the Visual Studio Magazine article, “What’s Coming to Blazor Hybrid in .NET 7.”

While most roadmap issues address specific issues or requests, five “principles” issues explain the goals in general terms of security, performance, accessibility, DPI awareness, and overall readiness:

  • Security
    • Need to define what the threats are here
    • Rogue-ish third-party component?
    • Need to look at threat models for other native client platforms eg WPF as we will likely have a subset of the same concerns
    • Need to consult each native WebView component’s documentation guidance for best practices
  • Performance:
    • Define performance goals and scenarios with specific #s we will target
    • Build scenarios on the main competitors and ours
    • Automate measurements on relevant platforms
    • Need to consult each native WebView component’s documentation guidance for best practices
    • A feature to consider:
      • Enable pooling of WebViews and/or enable external creation of WebViews (from an existing pool externally). This technique is used in major applications which often have multiple web views, but only a subset of them are visible at a time.
  • Accessibility:
    • Check compatibility with screen readers
    • Check keyboard navigation such as tab key in and out of WebView
    • Check automation metadata, for example AutomationAttribute in WPF
    • Need to consult each native WebView component’s documentation guidance for best practices
  • DPI awareness:
    • Need to consult each native WebView component’s documentation guidance for best practices
    • We should also consult the docs for each UI platform to see if there are any best practices to follow.
  • Global preparation:
    • In general, globalization and localization
    • But also templates to create applications that use these templates. It’s likely that Blazor and native UI platforms each have their own flavors, so we need to see how they fit into a single app.
    • Does each native WebView component have some of its own concerns/features that we need to be aware of?

About the Author


David Ramel is an editor and writer for Converge360.



Lance B. Holton