Clarify configuration providers for Blazor WASM

[guardrex]

.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 7367a651-2b27-0a57-e7d0-95686cc97f1c
• Version Independent ID: 8c769648-728d-72ce-ebf6-2a06e5076aa2
• Content: ASP.NET Core Blazor configuration
• Content Source: aspnetcore/blazor/fundamentals/configuration.md
• Product: aspnet-core
• Technology: aspnetcore-blazor
• GitHub Login: @guardrex
• Microsoft Alias: riande

[guardrex]

@captainsafia ... I've looked over the ASP.NET Core Configuration topic to see what we might need to call out that isn't appropriate for Blazor WASM apps. It looks like we should mention that the following aren't appropriate ...

• Azure Key Vault configuration provider for the managed identity and clientId/clientSecret scenarios. OAuth should work, and I think certificate auth would still be permitted, including with the new Azure.Extensions.AspNetCore.Configuration.Secrets bits. Ordinarily, we wouldn't even mention the clientId/clientSecret approach because our Key Vault config topic totally avoids it. However given that WASM apps are running on the client, it's probably prudent to remind devs never to put any kind of secret or password in a WASM app again here to reinforce the point.
• Azure App configuration provider
• Custom config provider based on EF Core

... and we'll include ...

ASP.NET does not require that you can SetBasePath on the ConfigurationBuilder before requesting files via a relative path, so our configuration differs in this way.

... but perhaps writing it out a bit more (with an example perhaps) to make the scenario clear.

[captainsafia]

Custom config provider based on EF Core

I'm not so sure about this one. @mkArtakMSFT who would be the best person to help us figure out if this is expected to work in Blazor WASM?

[guardrex]

My concern on that one is WRT the implementation that doesn't meet the guidance for EF Core and Blazor to use OwningComponentBase or DbContextOptions<TContext>. It looks we'd need to call out that the approach can't be used in its present form.

I think this is one that even a Blazor Server app would need a mention on for the same reason.

[guardrex]

@captainsafia I'm up to working on this one today. I should have the state management doc work done and up in the PR soon, and I should have enough time left today to knock this out (... or tomorrow morning 🏃🏃🏃🏃😅). UPDATE: tomorrow ... ran out of hours today.

I think that I'm right about the EF Core config provider for WASM ... that's not going to work without more work to deal with the concurrent dB context problem.

I see what you mean now. The config provider scenario seems like it may not have a concurrency problem IF the Load method of the provider is only called once at app start. I'll try running a test locally to at least see how that method behaves; but Yes! on asking Artak, Hao, or Jeremy for assistance.

UPDATE ... We might be ok. It looks like Load is only called once at app start to load config using the approach shown. I see some nits to fix with the coverage tho:

• Namespaces need to be added to the code examples.
• Adding the config is slightly different (i.e., builder.Configuration.AddEFConfiguration(...);

I think it's probably more important to get this coverage in now before deciding to make an EF Core config provider for WASM. I think I'll open a new issue on hold to collect ideas for future updates where I don't really want to put up in a new issue ... a "nice to have" issue to collect ideas. UPDATE: Done!