.NET 8 migration from WASM to Blazor Web App - environment not set correctly

[Stra1ghter]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

I have followed the migration guide from Blazor WebAssembly to Blazor Web App. After migrating, IWebAssemblyHostEnvironment always returned that I'm running the Production environment.

From what I have tested, I can see that < .NET 8 the response to blazor.boot.json always returned a Blazor-Environment header. With the changes described in the migration guide, this is no longer the case and the client cannot determine its environment.

I propose:

• to include a hint regarding this in the migration guide.
• to add a middleware that sets this header again.

My team is totally dissatisfied with the options in the Blazor environment docs. Because they have big disadvantages:

• setting in startup environment doesn't work as described in the docs with the changed App.razor in the Server project. (It now hase a Routes component on the server and there is no script tag as in the code example.) Additionally, it is just a heuristic based on the URL instead of a correct way of setting the environment.
• setting the environment header via web.config is not dynamic.

Expected Behavior

IWebAssemblyHostEnvironment should return the correct environment after following the migration guide.

Steps To Reproduce

Create a Blazor WebAssembly app that uses IWebAssemblyHostEnvironment on the client and follow the migration guide to a Blazor Web App.

Exceptions (if any)

No response

.NET Version

8

Anything else?

No response

[Stra1ghter]

Setting the environment after src="_framework/blazor.web.js" works, but I would highly emphasize to improve the documentation there.

As discussed above it's also a heuristic and no real solution for our team.

[javiercn]

Just fired up a new version of the template and this seems to work correctly, can you provide a minimal repro project?

Hi @Stra1ghter. We have added the "Needs: Author Feedback" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[guardrex]

BTW @Stra1ghter ... The Environments article was revised for 8.0. Take a look at the guidance there ...

https://learn.microsoft.com/en-us/aspnet/core/blazor/fundamentals/environments?view=aspnetcore-8.0

... especially this section ...

https://learn.microsoft.com/en-us/aspnet/core/blazor/fundamentals/environments?view=aspnetcore-8.0#read-the-environment-client-side-in-a-blazor-web-app

I've opened an issue to add a cross-link that article in that section of the migration article. I don't know if what we have there thus far will resolve the problem(s) that you're facing here, but I'll keep an 👁️ on this issue for further doc update opportunities. For now, at least the cross-link will be present in the migration guidance.

[Stra1ghter]

Sorry for the delay.

@javiercn Here is a minimal repo. The main branch is the .NET 6 WASM template that is correctly displaying the Hosting environment client-side. In the update-branch I followed your migration guide and the environment is always displayed as "Production".

As stated in the issue:
Some middleware of the .NET 6 template (guess UseBlazorFrameworkFiles) provides the Blazor-Environment as a header to blazor.boot.json. This is removed during migration to a Blazor Web App. Hence, the IWebAssemblyHostEnvironment defaults to Production.

Before migration:

After migration:

[Stra1ghter]

@guardrex Sorry for the delay.
I have read the blazor environment doc, I have even linked the article in my report above!
However

1. Even if your specific section reads "Read the environment client-side in a Blazor Web App", it creates a server-side component. At least from my "newbie" .NET 8 Blazor knowledge that was not usable in the client project itself. And prerendering etc. is not discussed in the migration guide itself.

2. The other means discussed in the article such as this is a heuristic and no real solution (setting the environment via URL). I don't like this approach at all, URLs can change.
   I also want to note that I find the src {BLAZOR SCRIPT} in that example rather confusing. Why not name it specifically _framework/blazor.web.js as discussed in the migration guide?

[guardrex]

it creates a server-side component

That section explains how to inject IWebAssemblyHostEnvironment into interactive WASM or Auto components, which can cause failures in those components when the service doesn't exist on the server during prerendering or before the Blazor bundle downloads. I think where you stated "it" in your last remark you were referring to your sample app (and interactive Server components), but I didn't think that your opening post clarified what type of components you were having trouble with. Of course, that section won't help if you discovered a real 🪲 or if we're lacking some piece of important information in the guidance. I'm 👂 here for what the investigation uncovers.

it is just a heuristic based on the URL

That's just an example for a very specific scenario, which is called out in the heading, via startup configuration.

... and this isn't the primary article for setting the environment in a BWA. As the guidance in the opening remarks indicates ...

For general guidance on setting the environment for a Blazor Web App, see Use multiple environments in ASP.NET Core.

I'll highlight that line, possibly in its own new section, because BWA render mode coverage in the introduction that was added for 8.0's release now crowds out that critical point and makes it seem less important. You set the environment for a BWA using the same approaches as you would for any ASP.NET Core app. Again, that might not have any bearing on the issue here, but I'll update the article to make that clearer.

src {BLAZOR SCRIPT} in that example rather confusing. Why not name it specifically _framework/blazor.web.js as discussed in the migration guide?

That migration guide section is specific for a particular type of Blazor app migration scenario ... hosted WASM to BWA. Other places in reference docs must cater to additional types of Blazor apps that don't use the same script or have the same script location, so a placeholder is used with a cross-link to a section that indicates the script name is and where the script is found. Although the reference docs can version the exact names and locations into place, we have a weak documentation versioning system given the amount of churn in the framework, and this approach of calling out the script name and location in a separate section with links to it from around the reference docs is a compromise to make the docs manageable to maintain.