Localization: Avoid satellite assembly probing under non-English cultures - #13466
Conversation
…ures The built-in English resources are looked up under the ambient CurrentUICulture. MudBlazor ships no satellite assemblies, so a non-English culture makes ResourceManager probe for a missing MudBlazor.resources satellite and throw a first-chance FileNotFoundException on every fresh lookup. That is mostly invisible at runtime but severely slows the Blazor WebAssembly debugger, where each caught exception stalls the debugger agent (a small MudDataGrid takes ~14-15s vs ~100ms). Pin the built-in resource lookup to the invariant culture so the embedded neutral resource is returned with no satellite probing. Only CurrentUICulture is pinned, so argument formatting still honors the user's culture, and custom IStringLocalizer or MudLocalizer sources keep the app's current UI culture. Fixes MudBlazor#13461
mudbot
Bot
added
bug
|
The transient lifetime of the interceptor/localizer still builds a fresh |
There was a problem hiding this comment.
Pull request overview
This PR prevents repeated MudBlazor.resources satellite assembly probing (and the resulting caught FileNotFoundExceptions) when the app runs under a non-English CurrentUICulture, by forcing lookups of MudBlazor’s built-in neutral English LanguageResource.resx to resolve under InvariantCulture.
Changes:
- Wrap the built-in
ResourceManagerStringLocalizerwith anIStringLocalizerimplementation that temporarily pinsCultureInfo.CurrentUICulturetoInvariantCulturefor each lookup. - Materialize
GetAllStrings()results inside the pinned-culture scope to avoid deferred enumeration after the culture is restored. - Add a regression unit test ensuring a non-English UI culture does not trigger
MudBlazor.resourcessatellite probing (viaAppDomain.AssemblyResolveobservation).
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| src/MudBlazor/Services/Localization/AbstractLocalizationInterceptor.cs | Wraps the default LanguageResource localizer so built-in English resources resolve under InvariantCulture, avoiding missing-satellite probing. |
| src/MudBlazor.UnitTests/Services/Localization/DefaultLocalizationInterceptorTests.cs | Adds a regression test asserting no satellite probing occurs under sv-SE while still returning the expected English fallback. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
I would prefer more if that was created once via additional service that is registered as singleton, then it would be rather a one time thing. |
The built-in English resources are looked up through a
ResourceManagerStringLocalizerthat resolves under the ambientCurrentUICulture. MudBlazor ships only the neutralLanguageResource.resx(no satellite assemblies), so a non-English culture makesResourceManagerwalk the fallback chain (sv-SE→sv→ invariant) and probe for a missingMudBlazor.resourcessatellite, throwing a caught first-chanceFileNotFoundExceptionon each fresh lookup.MudDataGridrenders in ~14-15s instead of ~100ms.ResourceManagerand re-probes; the cost scales with the number of localized components.en-US(which probesen-USanden).Fixes #13461 by wrapping the built-in localizer in
DefaultLanguageResourceReaderso its lookups resolve underInvariantCulture, which reads the embedded neutral resource with no satellite probing.CurrentUICultureis pinned, synchronously with noawaitgap, soCurrentCulturestill formats arguments in the user's culture.IStringLocalizer(other constructor) and a customMudLocalizerkeep the app's current UI culture.