[Pre3] Blazor WASM fingerprinting and environment property

[guardrex]

Fixes #35023
Addresses #34948
Addresses #34437
Fixes #35075

Covering two Blazor WASM features now on this PR ...

• Fingerprinting
• <WasmApplicationEnvironmentName> to set the environment

---

Internal previews

📄 File	🔗 Preview link
aspnetcore/blazor/components/built-in-components.md	aspnetcore/blazor/components/built-in-components
aspnetcore/blazor/fundamentals/environments.md	aspnetcore/blazor/fundamentals/environments
aspnetcore/blazor/fundamentals/static-files.md	aspnetcore/blazor/fundamentals/static-files
aspnetcore/fundamentals/map-static-files.md	aspnetcore/fundamentals/map-static-files

[guardrex]

@maraf ... To avoid a merge conflict in the What's New file, I'll just combine the coverage here. This PR now covers for Blazor WASM ...

• Fingerprinting
• WasmApplicationEnvironmentName for environment control

I think I'm going to need more information tho ... what's happening with the Blazor-Environment header for >=10.0? Is that still how server-side is communicating the environment to the client-side?

[maraf]

I think I'm going to need more information tho ... what's happening with the Blazor-Environment header for >=10.0? Is that still how server-side is communicating the environment to the client-side?

That header doesn't exist any more, because of the blazor.boot.json => dotnet.boot.js we don't have a way to read it.
In server-side scenario, the value is part of the initial document response, encoded as HTML comment dotnet/aspnetcore#60714 (I think is kind of internal thing as it shouldn't effect users by any means).
In standalone scenario, we don't have a way to read the value that is part of the launchSettings.json and that was used when launching DevServer. So instead we have the MSBuild property.

[guardrex]

I'm working on this now, and it's a bit tricky to explain without getting into implementation details. AFIACT, "hard" and "soft" fingerprinting aren't industry concepts. They seem to be convenient ways to describe implementation details of the framework. I'm trying to write this up without referring to them.

Hopefully, I'll have this updated shortly, and then we can see just how badly 🙈 it has turned out 😆 ... and then try to fix it from there.

[guardrex]

The Blazor-Environment header aspects have been addressed, and that's looking good thus far. I'll double-check the updates on the last commit on Monday morning.

[Removed remarks]

🤔 I think I was overthinking what this needs to say. On the last commit, I placed my current understanding. See if that's at least headed in the right direction for module fingerprinting.

... actually the last two commits because I had to go back into the CSR reference docs and describe CSR for BWAs and CSR for standalone Blazor WebAssembly .......... well ...... my interpretations on them. We'll see where it's all going sideways when you look at it 🙈😆.

[guardrex]

@maraf ... I only found NIT updates to make this morning.

AFAICT, we can avoid "hard" and "soft" fingerprinting details.

I'm 👂 to learn if what's here is accurate.

[maraf]

A rename is coming your way dotnet/sdk#47915

[guardrex]

Update made. Let me know as soon as we can merge this. It's blocking other work just a little bit in terms of the What's New INCLUDE. Javier's Declaratively persist state updates are next and will touch the INCLUDE file.

[maraf]

Now that I see the docs, the property WasmApplicationEnvironmentName should actually be WasmApplicationEnvironment, am I right?

[guardrex]

Now that I see the docs, the property WasmApplicationEnvironmentName should actually be WasmApplicationEnvironment, am I right?

I'll check it.

[guardrex]

Looks like it has "Name" on it ...

https://github.com/maraf/runtime/blob/main/src/mono/nuget/Microsoft.NET.Sdk.WebAssembly.Pack/build/Microsoft.NET.Sdk.WebAssembly.Browser.targets#L333

[guardrex]

btw ... There are 41 references to blazor.boot.json around the docs. I have a way to address them uniformly that might work with a section that calls out the name of the boot file and cross-links to that section for devs to get the right file name.

The problem with versioning all of the content for the boot file name change is that our versioning tools are weak for these types of large-scale changes (i.e., we don't have Version-by-file versioning 😢). It's best to take care of this on a different PR, so I've opened #35125 to address it after this PR is merged.

[guardrex]

This has the updates on it now.

I split the BWA guidance from the standalone WASM guidance.

[maraf]

Looks like it has "Name" on it ...

https://github.com/maraf/runtime/blob/main/src/mono/nuget/Microsoft.NET.Sdk.WebAssembly.Pack/build/Microsoft.NET.Sdk.WebAssembly.Browser.targets#L333

Yes, it has and I'm questioning my choice :) It looks like all other places in Blazor don't have it

Update made. Let me know as soon as we can merge this. It's blocking other work just a little bit in terms of the What's New INCLUDE. Javier's Declaratively persist state updates are next and will touch the INCLUDE file.

The rename will be preview4

[guardrex]

I'm questioning my choice

😆

I was wondering why you were asking me ... a goober docs dinosaur 🦖🙈🤣. I'm not much help when it comes to framework design.

Having "Name" on it seems to line up OK with ...

https://learn.microsoft.com/en-us/dotnet/api/microsoft.extensions.hosting.ihostenvironment?view=net-9.0-pp

However, "Name" wasn't used for the environment property here ...

https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.components.webassembly.hosting.iwebassemblyhostenvironment?view=aspnetcore-9.0

And, it wasn't used for the Blazor-Environment header, which could've been the "Blazor-Environment-Name" header.

And, it wasn't used for Blazor.start() ... { environment: "..." }, which could've been { environmentName: "..." }.