blazor tutorial – ASP.NET Hosting Reviews and Guides

How Lazyloading Works to Increase Your Blazor Performance?

Jacques Hunt — Fri, 16 Jun 2023 08:08:55 +0000

In this article, we’ll examine how to implement lazy loading using Blazor WebAssembly. We can speed up the startup of our Blazor WebAssembly application by delaying the download of resources we don’t currently require. For instance, downloading all the files pertaining to products, authentication, and other things is useless if we have a large Blazor WebAssembly application and our users only want to view the home or contact pages. The program will only download these resources if the user specifically requests them when lazy loading is enabled.

Setup Blazor WASM Project

Open the Visual Studio and search for Blazor App. Click on the Next button,

Define the project name, path, and solution name. Click on the Create button,

After that a new window will pop up to choose the target framework (.Net 6.0) from the dropdown and make sure to select the Blazor server App and in the Advanced section “Configure the Https” is checked.

Blazor Wasm Standard Workflow

If we now launch our application, access the Dev Tools window (F12), select the Application tab, and check the cache:

Although we are still on the Home page and have not navigated anywhere else, we can see that our BlazorWasmLazyLoading.dll file has been downloaded and cached, which is typical. However, it also suggests that all of the components in this DLL have been downloaded. Of course, for small apps like this one, this is not a problem. However, it could significantly speed up downloads for a more complex application. So let’s work out a way to prevent it.

Updating the primary project with new packages

We’re going to use the Syncfusion Libraries in this article to work with the idea of lazy loading, so create a new Razor class library project called Weather and empty it out except for the _Imports.razor file. Additionally, this project needs to be referenced from the main one.

From the right-click menu of the project, choose Manage NuGet Packages.
Afterward, use the word Syncfusion. Blazor, locate, and set up the proper Syncfusion.Blazor. Blazor NuGet packages. In this location, Syncfusion has been installed. The program makes use of the NuGet packages Syncfusion and Blazor Buttons.Blazor.Calendars. Look at the illustration below.

Configure the Syncfusion Blazor Service in Program.cs file as per the below code.

using LazyLoading;
using Microsoft.AspNetCore.Components.Web;
using Microsoft.AspNetCore.Components.WebAssembly.Hosting;
using Syncfusion.Blazor;

var builder = WebAssemblyHostBuilder.CreateDefault(args);
builder.RootComponents.Add("#app");
builder.RootComponents.Add("head::after");

builder.Services.AddScoped(sp => new HttpClient { BaseAddress = new Uri(builder.HostEnvironment.BaseAddress) });
builder.Services.AddSyncfusionBlazor();

await builder.Build().RunAsync();

Implementation Lazy Loading

In order to use Blazor WebAssembly’s Lazy Loading feature, we must first make a change to the main project file. Therefore, from the context menu, right-click on the BlazorWasmLazyLoading project and choose EditProjectFile:

LazyLoading.csproj



  
    net6.0
    enable
    enable

Modifying App.razor File to Load the Required DLL

We import the required utilizing directives before injecting the AssemblyLoader to load our assembly. The OnNavigateAsync event callback in the Router component is then given the OnNavigateAsync method. The OnNavigateAsync event callback is invoked just before switching to a new page. The AdditionalAssemblies property is also set to true. This attribute instructs our program to use additional assemblies to search for components that match the correct URIs.

In the @code section, we create the _lazyLoadedAssemblies private list of assemblies and the OnNavigateAsync method with the NavigationContext parameter. We check the currently required route inside the procedure using the context argument. If the fetch data route—the route of our FetchData component—matches, we use the LoadAssembliesAsync method to load the assemblies.

@using System.Reflection;
@using Microsoft.AspNetCore.Components.Routing;
@using Microsoft.AspNetCore.Components.WebAssembly.Services;
@inject LazyAssemblyLoader assemblyLoader;

    
        
        
    
    
        Not found
        
            Sorry, there's nothing at this address.
        
    


@code {
    private List lazyLoadedAssemblies = new List();
    private async Task OnNavigateAsync(NavigationContext args)
    {
        try
        {
            if (args.Path.StartsWith("fetchdata"))
            {
                var assemblies = await assemblyLoader.LoadAssembliesAsync(new[] { "Sample.dll" });
                assemblies = await assemblyLoader.LoadAssembliesAsync(new[] { "Syncfusion.Blazor.Buttons.dll" });
                assemblies = await assemblyLoader.LoadAssembliesAsync(new[] { "Syncfusion.Blazor.Charts.dll" });
                assemblies = await assemblyLoader.LoadAssembliesAsync(new[] { "Syncfusion.Blazor.Data.dll" });
                assemblies = await assemblyLoader.LoadAssembliesAsync(new[] { "Syncfusion.Blazor.DropDowns.dll" });
                assemblies = await assemblyLoader.LoadAssembliesAsync(new[] { "Syncfusion.Blazor.Grid.dll" });
                lazyLoadedAssemblies.AddRange(assemblies);
            }
            if(args.Path.StartsWith("counter"))
            {
                var assemblies = await assemblyLoader.LoadAssembliesAsync(new[] { "Syncfusion.Blazor.Calendars.dll" });
                assemblies = await assemblyLoader.LoadAssembliesAsync(new[] { "Syncfusion.Blazor.Buttons.dll" });
                assemblies = await assemblyLoader.LoadAssembliesAsync(new[] { "Syncfusion.Blazor.Lists.dll" });
                assemblies = await assemblyLoader.LoadAssembliesAsync(new[] { "Syncfusion.Blazor.Navigations.dll" });
                assemblies = await assemblyLoader.LoadAssembliesAsync(new[] { "Syncfusion.Blazor.Notifications.dll" });
                assemblies = await assemblyLoader.LoadAssembliesAsync(new[] { "Syncfusion.Blazor.Popups.dll" });
                assemblies = await assemblyLoader.LoadAssembliesAsync(new[] { "Syncfusion.Blazor.Spinner.dll" });
                assemblies = await assemblyLoader.LoadAssembliesAsync(new[] { "Syncfusion.Blazor.SplitButtons.dll" });
                lazyLoadedAssemblies.AddRange(assemblies);
            }
        }
        catch (Exception ex)
        {

        }
    }
}

Keep in mind that we won’t be able to locate the downloaded Sample.dll if we launch the app and search the cache. However, if we visit the FetchData page and the counter page, we can see the content of each page as well as the dependencies that have been downloaded.

Counter page

Conclusion

Currently, we are aware of how to load various dependencies solely when necessary using Blazor WebAssembly’s lazy loading feature. As was already mentioned, this is a great feature because it speeds up the loading of our application.

All there is to it is that!

How to Troubleshoot .NET Blazor WASM Debugging

Jacques Hunt — Fri, 03 Mar 2023 04:52:49 +0000

The “Obvious” of WASM Debugging

While coding with Blazor WASM, it’s easy to get lulled into a false sense of comfort. After all, it’s all C# and .NET, right? Well, not exactly. It’s easy to gloss over that while our code runs on a version of .NET, it’s not the one we know and love. It’s different. From the official documentation:

Blazor WebAssembly (WASM) apps run client-side in the browser on a WebAssembly-based .NET runtime.
–Microsoft Docs

And it’s also reflected in the graphic used on the page, with clear iconography indicating your new Blazor WASM app running in the browser.

Well, where does the debugging happen if your app runs standalone in the client? If you answered “on the client!”, then you’d be correct. All WASM code debugging occurs in the client and is typically proxied to your IDE of choice. That means your tools need a constant connection between your integrated development environment and the client app. Being in the client also means we’re not using traditional .NET debuggers but instead relying on the debuggers found in Chrome dev-tools. Keep that in mind.

Let’s investigate how and where this connection can go wrong and help you debug your Blazor WASM standalone apps.

Chromium Web Browsers Are Required

Currently, Blazor WASM debugging only works with Chromium-based browsers.

Google Chrome (version 70 or later)
Microsoft Edge (version 80 or later).

These browsers have the necessary developer tools to connect and communicate with your development environment. Sorry, Firefox and Safari users. You’ll need Chrome installed.

Missing Launch Settings Fields

Most ASP.NET Core projects will come with a launchSettings.json file. Here we can tell the dotnet process how to run our web host application. However, for Blazor WASM hosts, we need a few more settings than we initially had with a vanilla ASP.NET Core app.

"BlazorWithBackend.Server": {
  "commandName": "Project",
  "dotnetRunMessages": true,
  "launchBrowser": true,
  "inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}",
  "applicationUrl": "https://localhost:7174;http://localhost:5276",
  "environmentVariables": {
    "ASPNETCORE_ENVIRONMENT": "Development"
  }
}

You’ll need an additional inspectUri field and an optional dotnetRunMessages field. The inspectUri field is the endpoint to which the Chromium-based browser will connect via WebSocket. Without this field, no proxy-based debugging is possible.

Missing NuGet Packages

There are two locations where you need to ensure you have NuGet packages installed correctly in your Blazor WASM solution: The client and the server.

The Blazor WASM client project requires you to install two NuGet packages:

Microsoft.AspNetCore.Components.WebAssembly
Microsoft.AspNetCore.Components.WebAssembly.DevServer

The DevServer package includes the BlazorDebugProxy required to connect the client and IDE. Without this package, you aren’t debugging anything.

The Blazor WASM host, also need the following package of Microsoft.AspNetCore.Components.WebAssembly.Server, which includes the necessary middleware to host your Blazor application.

Misconfiguration of Blazor Middleware

You’ll need several pieces of middleware to get debugging working, specifically the UseWebAssemblyDebugging method call. In addition, the order of middleware registrations requires to be accurately registered. I’ve included a correct sample below from the default templates.

var app = builder.Build();

// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
    app.UseWebAssemblyDebugging();
}
else
{
    app.UseExceptionHandler("/Error");
    // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
    app.UseHsts();
}

app.UseHttpsRedirection();

app.UseBlazorFrameworkFiles();
app.UseStaticFiles();
app.UseRouting();
app.MapRazorPages();
app.MapControllers();
app.MapFallbackToFile("index.html");

Enabling The JavaScript Debugger

Remember how I said previously that EVERYTHING HAPPENS IN THE CLIENT? Well, you need to enable the JavaScript debugger in your favorite IDE. Personally, as a JetBrains Rider user, it’s as simple as checking the with JavaScript debugger checkbox found in the run configuration from your server host.

Running the Correct Run Configuration

This tip is specifically for JetBrains Rider users. After enabling the JavaScript debugger, you might accidentally start the JavaScript Debugger run configuration. This allows Rider to connect to an existing running app, but doesn’t start your host application if it is not already started. This might cause your browser to launch and hang on Blazor’s “Loading” screen. If you find yourself waiting longer than you expect, double-check the run configuration you launched.

Global.Json and .NET 6

As of writing this post, some of your IDEs only have support for .NET 6 debugging. If you have any preview versions of .NET installed, you may want to set your global.json file to lock the SDK version to the .NET 6 band.

Restart the Chrome Instance, No The Other One

So when debugging Blazor WASM apps, your IDE might start a brand-new instance of Chrome with different settings. Check your taskbar and dock for multiple instances of Chrome. Locate the one your IDE started and quit and retry the debugging process.

It’s common to see messages saying: “Blazor Wasm Debugging: lockfile exists, connecting to already running browser”. The message means you have the debugging instance of Chrome still running from previous attempts.

Shut it down and try again.

Final Verdict

I hope to give you some suggestions for getting your Blazor WASM client debugging with your favorite IDEs.