[.net 10 Preview 5] Blazor wasm stand-alone app HostEnvironment is "Production" in development mode
Is there an existing issue for this?
- [x] I have searched the existing issues
Describe the bug
Kestrel doesn't seem to be setting the Blazor-Environment header for stand-alone blazor wasm apps in .net 10. It works fine in .net 8 and 9.
Expected Behavior
We expect that kestrel will somehow get the Environment name into the blazor app. The console statement that logs to the browser should show the very same environment that is logged to the host console as kestrel launches.
It seems there should be a Blazor-Environment header on one of the blazor files, but I couldn't find any that had it. In .net 8 and .net 9 for example, blazor.boot.json has this header set on it. In .net 10 preview, I didn't actually see this file at all.
Steps To Reproduce
Using VIsual Studio 2022 or 2022 preview, create a blazor standalone wasm app using the template. Accept the defaults (no auth, etc) to keep it simple.
In Program.cs, after the line:
var builder = WebAssemblyHostBuilder.CreateDefault(args);
Place:
Console.WriteLine($"Client Hosting Environment: {builder.HostEnvironment.Environment}");
Use dotnet run to launch the app. In all 3 .net versions, it will log to the console:
"info: Microsoft.Hosting.Lifetime[0] Hosting environment: Development"
But when you open your browser and look at its console, this value carried over only in .net 8 and .net 9.
In .net 8 and .net 9 apps, "Development" is logged to the browser console. In .net 10 preview 5 apps, it's "Production" that is logged.
Exceptions (if any)
No response
.NET Version
10.0.100-preview.5.25277.114
Anything else?
No response
@cda-1 thanks for contacting us.
We've changed the way this works, and it's done via an MSBuild setting as of 10 as we switch to generate and inline the config during the boot process for speed.
/cc: @maraf
Thanks for the quick response! Does "the new way" work yet or do I need to wait for final release?
@cda-1 it works, but I don't remember the exact setting.
@maraf knows the details
@cda-1 The msbuild property is WasmApplicationEnvironmentName, docs at https://learn.microsoft.com/en-us/aspnet/core/blazor/fundamentals/environments?view=aspnetcore-10.0#set-the-environment
The default seems to be "Production" in development. Even though the local webserver that serves the stand-alone blazor wasm app logs the environment as "Development", logging builder.HostEnvironment.Environment in Program.cs shows Production.
I tried placing <WasmApplicationEnvironmentName>Staging</WasmApplicationEnvironmentName> at the top, like this:
<PropertyGroup>
<TargetFramework>net10.0</TargetFramework>
<Nullable>enable</Nullable>
<ImplicitUsings>enable</ImplicitUsings>
<WasmApplicationEnvironmentName>Staging</WasmApplicationEnvironmentName>
</PropertyGroup>
Is that correct? It didn't work for me. The wasm app seems to still think it's Production, and the server logs still show the environment as Development.
@maraf can you take a look?
@cda-1 There is an issue with the parameter flow in Blazor app. Unfortunately, it seems we don't have an end-to-end test. We will it in Preview 7. Until then the best option to pass the parameter is using javascript.
<script src="_framework/blazor.webassembly#[.{fingerprint}].js" autostart="false"></script>
<script>
Blazor.start({ environment: "Staging" });
</script>
@maraf understood!
"_framework/blazor.webassembly#[.{fingerprint}].js" didn't seem to be valid when the browser requested it, but the below solution works, which I got from the docs you linked previously.
<script src="_framework/blazor.webassembly.js" autostart="false"></script>
<script>
if (window.location.hostname.includes("localhost")) {
Blazor.start({
environment: "Development"
});
} else {
Blazor.start();
}
</script>
Thank you for your quick responses!
"_framework/blazor.webassembly#[.{fingerprint}].js"
It's coming from the update in .NET 10, where we can fingerprint all blazor framework assets https://learn.microsoft.com/en-us/aspnet/core/release-notes/aspnetcore-10.0?view=aspnetcore-9.0#client-side-fingerprinting