Blazor wasm lazy loading is not working

[Stamo-Gochev]

Describe the bug

Using lazy loading of assemblies fails when a service extension method is used.

Additional context

A blazor wasm project is configured to use lazy loading for a class library project that has some dependencies. The app is inspired by the example from Dan Roth and the MyComponents lib.

The problem occurs when a service extension method is used, which is empty. Not using this method works as expected and no errors are thrown.

To Reproduce

1. Clone https://github.com/Stamo-Gochev/blazor-wasm-lazy-loading-issue
2. Set the server project as a startup project
3. Run the app by pressing Ctrl + F5

Expected

The dependency assemblies are loaded without errors.

Actual

An exception is thrown and the app crashes. The actual component that triggers lazy loading is in the Counter.razor file.

Exceptions (if any)

AN exception is thrown in the console

System.IO.FileNotFoundException: Could not load file or assembly 'MyComponents, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.

Further technical details

• ASP.NET Core version 5.0 RC2
• Include the output of dotnet --info
• The IDE (VS / VS Code/ VS4Mac) latest

[captainsafia]

Thanks for opening this issue, @Stamo-Gochev!

The scenario that you're describing isn't supported by the lazy-loading features in Blazor. The AddMyComponent method from MyComponent1 is used in the initialization logic before the app has been launched and the OnNavigateAsync code path is invoked.

We designed the lazy-loading feature to support lazy-loading on a per-route basis. Since the AddMyComponent method needs to be used when the application first launches, it's reasonable to lazy loaded. For your scenario, I'd recommend splitting up the parts of your package that you do want lazily-loaded (the components) from the things you want to use during initialization (the AddMyComponent API).

Let me know if you have any follow-up questions.

[Stamo-Gochev]

@captainsafia A follow-up question - as splitting a package into multiple packages in order to support lazy loading is not always possible (e.g. in order to be backward compatible), is there any chance for the current limitation to be fixed in the future or have some type of a workaround? As the service injection is not working, another approach might be to define the injected service as a variable and mark it with some attribute to signal the variable is dependent on the lazy loading feature (note that currently this fails with the same error as described above):

@code {
        [LazyLoaded]
        public MyCustomComponentClass CustomClass { get; set; } = new MyCustomComponentClass();
}

[captainsafia]

@Stamo-Gochev Thanks for the feedback! That's definitely a valid scenario that we had considered in the design but opted out of since we didn't consider it to be a common scenario.

Would you be interested in opening an issue with this feature request so we can gauge how many folks would find this helpful?

[Stamo-Gochev]

@captainsafia I will log an issue, but is the service injection possible at all as it works on per app level (services.AddSingleton<SomeService>) or are you rather referring to the "workaround" suggestion with an attribute (the exact implementation can be something else like a configuration)?

[captainsafia]

are you rather referring to the "workaround" suggestion with an attribute (the exact implementation can be something else like a configuration)?

I was referring to the second scenario with the workaround. It's reasonable to assume that people might not want to split out their components into a separate RCL to get them to work with lazy-loading.

With regard to the service injection, the scenario you provided doesn't work with lazy-loading since the lazy-loaded service is used before the app has been initialized at all.

[Stamo-Gochev]

@captainsafia I've logged the issue in #27811, feel free to update it accordingly.

[ChristianWeyer]

@Stamo-Gochev Thanks for the feedback! That's definitely a valid scenario that we had considered in the design but opted out of since we didn't consider it to be a common scenario.

Would you be interested in opening an issue with this feature request so we can gauge how many folks would find this helpful?

Hi @captainsafia :-) I can confirm that this a is very common and indeed much-needed scenario for splitting out functional modules that can be lazy-loaded.
Thanks!