.NET MAUI – RC1 – BlazorWebView – Streamlined

Yesterday, Apr 12, 2022, the first Release Candidate (RC) version of .NET MAUI got released with the freeze in API design surface before General Availability (GA) in May later this year. After multiple preview releases in the past 13 months, in fact, it all started with .NET 6 Preview 2 on Mar 11, 2021, and now reached the RC stage where it can be deployed to Production and backed by an official go-live support policy.

Visual Studio 17.2.0 Preview 3.0 was also released with an updated Mobile Workload to support the same.

I’ll do a series of articles on what’s changed in the RC1 release and also compare and contrast the changes wrt to Xamarin.Forms to cover the migration area.

And this is a follow-up article on the .NET MAUI Blazor series as eventually there’re quite a few changes in the way the dependencies are registered for accessing the BlazorWebView. Have provided links to the first two articles in this series here: Getting Started with .NET MAUI Blazor and How to Interop with .NET MAUI.

Now the way how BlazorWebView is registered in the Startup is streamlined across all the supported platforms (.NET MAUI, Windows Forms, and WPF). We’ll take a look at each one of them.

.NET MAUI:

NuGet package:

Microsoft.AspNetCore.Components.WebView.Maui

For a .NET MAUI app, when the <UseMaui>true</UseMaui> tag is defined and the project target Razor SDK, the corresponding NuGet package is implicitly referenced. No need to define it again.

Prior to RC1:

If you just start fresh, it’s safe to skip this section as it talks about earlier implementation which is not relevant now.

It was a two-step registration: First, the Maui BlazorWebview would get registered with the MauiAppBuilder (builder) object, and then the BlazorWebView is registered into the DI container via the Services property as shown in the below code:

var builder = MauiApp.CreateBuilder();
builder.RegisterBlazorMauiWebView().UseMauiApp<App>();

builder.Services.AddBlazorWebView();
return builder.Build();

Now from RC1:

It’s a single-step registration, that requires invoking only the unified method with the DI container, i.e., Services property, as shown in the below code sample. Note the change in the name of the new method. There is a convention being followed here. We’ll get to know once as dive into the other frameworks.

Developer Tools:

Before moving on to the other frameworks, Debugging is essential to ensure that everything is rendered as expected or to delve into the minute details if something goes wrong. For that, we need to enable the Developer Tools, which behaves the same way as with our modern browsers. For that to work, call this method on the same Services property.

The method name is common across all frameworks.

Pro Tip: When enabled, use Ctrl+Shift+I to open the developer tools from the application UI where BlazorWebView is hosted.

builder.Services.AddBlazorWebViewDeveloperTools();

Can be restricted to Debug build alone by wrapping it within the Preprocessor directive as shown below.

var builder = MauiApp.CreateBuilder();
builder.UseMauiApp<App>();

builder.Services.AddMauiBlazorWebView();

#if DEBUG
builder.Services.AddBlazorWebViewDeveloperTools();
#endif

return builder.Build();

Windows Forms:

NuGet package:

Microsoft.AspNetCore.Components.WebView.WindowsForms

Add this code to any of the Form where BlazorWebView is needed as shown below.

var services = new ServiceCollection();
services.AddWindowsFormsBlazorWebView();

#if DEBUG
builder.Services.AddBlazorWebViewDeveloperTools();
#endif

var serviceProvider = services.BuildServiceProvider();

var blazor = new BlazorWebView()
{
    Dock = DockStyle.Fill,
    HostPage = "wwwroot/index.html",
    Services = serviceProvider
};

blazor.RootComponents.Add<Main>("#app");
Controls.Add(blazor);

WPF:

NuGet package:

Microsoft.AspNetCore.Components.WebView.Wpf

Similar to that of the other two frameworks, but slightly differ in the way how the resource is handled.

Code-behind:

var services = new ServiceCollection();
services.AddWpfBlazorWebView();

#if DEBUG
builder.Services.AddBlazorWebViewDeveloperTools();
#endif

var serviceProvider = services.BuildServiceProvider();
// Note the resourceKey can be anything, but use it in a consistent way
Resources.Add(key: "services", value: serviceProvider);

XAML: (only relevant code is shown for brevity)

<!-- Use the same resourceKey that is used while adding into the ResourceDictionary -->
<b:BlazorWebView HostPage="wwwroot/index.html" Services="{StaticResource services}">
    <b:BlazorWebView.RootComponents>
        <b:RootComponent ComponentType="{x:Type local:Main}" Selector="#app" />
    </b:BlazorWebView.RootComponents>
</b:BlazorWebView>

If intended to use it in multiple Forms / Pages, then it is wise to manage it separately and invoke it in the App startup. Check out the Blazor Desktop Templates for details. Available as NuGet package and VSIX extension.

Happy coding. Stay connected as we continue to learn and share the experiences from this exciting journey of being a .NET developer.