Summary
Environment variables injected into WebAssembly via MonoConfig.environmentVariables should be automatically available in IConfiguration without requiring an explicit call to AddEnvironmentVariables().
Background
In Blazor WebAssembly, environment variables can be injected via JavaScript initializers into MonoConfig.environmentVariables. These variables are then available via Environment.GetEnvironmentVariable(), but they are NOT automatically included in IConfiguration.
This is problematic for Aspire integration because:
- Service Discovery reads configuration from
IConfiguration (e.g., services:weatherapi:https:0)
- OpenTelemetry configuration comes from
IConfiguration (e.g., OTEL_EXPORTER_OTLP_ENDPOINT)
Currently, developers must explicitly add:
var builder = WebAssemblyHostBuilder.CreateDefault(args);
// Required workaround - environment variables are in Environment.GetEnvironmentVariable()
// but NOT in IConfiguration by default
builder.Configuration.AddEnvironmentVariables();
Current Behavior
// In WebAssembly after JS initializer injects env vars into MonoConfig.environmentVariables:
// This WORKS:
var endpoint = Environment.GetEnvironmentVariable("OTEL_EXPORTER_OTLP_ENDPOINT"); // ✅ Returns value
// This DOES NOT WORK without explicit AddEnvironmentVariables():
var endpoint = builder.Configuration["OTEL_EXPORTER_OTLP_ENDPOINT"]; // ❌ Returns null
Expected Behavior
Environment variables should be available in IConfiguration by default, matching the behavior of server-side ASP.NET Core applications where WebApplication.CreateBuilder() includes environment variables automatically.
Proposed Solution
In WebAssemblyHostBuilder.CreateDefault(), add EnvironmentVariablesConfigurationProvider to the default configuration sources:
public static WebAssemblyHostBuilder CreateDefault(string[]? args = null)
{
var builder = new WebAssemblyHostBuilder(...);
// Add environment variables to configuration by default
builder.Configuration.AddEnvironmentVariables();
// ... rest of initialization
return builder;
}
Impact
This change would:
- Align WebAssembly behavior with server-side ASP.NET Core
- Enable Service Discovery to work out-of-the-box with Aspire
- Enable OpenTelemetry configuration to work without additional setup
- Reduce boilerplate for Aspire integration
Workaround
Until this is addressed, add the following to your Blazor WASM Program.cs:
builder.Configuration.AddEnvironmentVariables();
Note: This requires adding a package reference to Microsoft.Extensions.Configuration.EnvironmentVariables.
Related Issues
Part of .NET 11.0 Blazor + Aspire integration improvements
Summary
Environment variables injected into WebAssembly via
MonoConfig.environmentVariablesshould be automatically available inIConfigurationwithout requiring an explicit call toAddEnvironmentVariables().Background
In Blazor WebAssembly, environment variables can be injected via JavaScript initializers into
MonoConfig.environmentVariables. These variables are then available viaEnvironment.GetEnvironmentVariable(), but they are NOT automatically included inIConfiguration.This is problematic for Aspire integration because:
IConfiguration(e.g.,services:weatherapi:https:0)IConfiguration(e.g.,OTEL_EXPORTER_OTLP_ENDPOINT)Currently, developers must explicitly add:
Current Behavior
Expected Behavior
Environment variables should be available in
IConfigurationby default, matching the behavior of server-side ASP.NET Core applications whereWebApplication.CreateBuilder()includes environment variables automatically.Proposed Solution
In
WebAssemblyHostBuilder.CreateDefault(), addEnvironmentVariablesConfigurationProviderto the default configuration sources:Impact
This change would:
Workaround
Until this is addressed, add the following to your Blazor WASM
Program.cs:Note: This requires adding a package reference to
Microsoft.Extensions.Configuration.EnvironmentVariables.Related Issues
Part of .NET 11.0 Blazor + Aspire integration improvements