Description
Recently we did some work to fix problems caused by satellite assemblies when building Blazor WebAssembly apps: #18207. The original issues were #17644 and #17754.
Although that change does now make the build succeed, the runtime behavior is not desirable. Applications now download all satellite assemblies for all cultures, even though we don't have any feature to make use of any of them. The JS-side code doesn't have any knowledge of which assemblies are satellite ones or not, or what cultures they relate to, so it has to fetch and load them all.
The simplest fix might be to change the JS-side code to infer cultures based on URLs. For example, the assembly MyAssembly1.dll is culture-independent, whereas en-GB/MyAssembly1.resources.dll could be inferred to be en-GB-specific. A more elaborate solution would be to change the schema of blazor.boot.json so it explicitly has sections for resources of different cultures.
Extra clean-up
As part of doing this, we should review whether the logic for attaching satellite assemblies to the build output is really correct. Currently, Blazor.MonoRuntime.targets contains a task _ResolveBlazorOutputs that claims to do this, but the explanation of its method given in comments is very unclear to me.
- It's unclear in what way
@(ReferenceCopyLocalPaths),@(_BlazorManagedRuntimeAssemby), and@(_BlazorResolvedAssembly)each differ or overlap. Some of them include pdbs, and some don't, with no indication given in the name. And in what sense are "managed runtime assemblies" not the same as the "resolved assemblies"? At the very least, we should have much more specific names for these groups. - Better still would be eliminating the use of both
@(ReferenceCopyLocalPaths)and@(_BlazorManagedRuntimeAssemby)so we only use@(_BlazorResolvedAssembly)(which has a clear role), and then obtain the extra satellite assemblies from some other source which is actually specific about the fact that its contents really are satellite assemblies, and nothing else.