Needs additional commentary regarding the build of a standalone Blazor wasm app

[MarkStega]

Description

As a result of discussion in AspNetCore #64282 I believe that the steps of publishing a standalone wasm app need to have the clarification that you have to disable fingerprinting or build a custom loader as blazor.webassembly.{fingerprint}.js won't directly load dotnet.{fingerprint}.js.

Page URL

https://learn.microsoft.com/en-us/aspnet/core/blazor/host-and-deploy/webassembly/github-pages?view=aspnetcore-10.0

Content source URL

https://github.com/dotnet/AspNetCore.Docs/blob/main/aspnetcore/blazor/host-and-deploy/webassembly/github-pages.md

Document ID

d6757daf-a25a-d46e-332c-cf811379f44c

Platform Id

5b882726-278a-3456-9f74-77a3f563a191

Article author

@guardrex

Metadata

• ID: d6757daf-a25a-d46e-332c-cf811379f44c
• PlatformId: 5b882726-278a-3456-9f74-77a3f563a191
• Service: aspnet-core
• Sub-service: blazor

Related Issues

[github-actions[bot]]

🦃 Happy Thanksgiving! 🍽️

Stand-by! A green dinosaur 🦖 will be along shortly to assist.

[guardrex]

🦖 NOTE TO SELF

... and we need remarks in ...

https://learn.microsoft.com/en-us/aspnet/core/blazor/host-and-deploy/webassembly/github-pages?view=aspnetcore-10.0

... for this.

Thanks @MarkStega ... I'll talk to Marek, and we'll see if we can get the docs on this sorted out today.

[guardrex]

@maraf ... Let's discuss this a bit more in advance of my updating the documentation to resolve the docs issue (dotnet/AspNetCore.Docs #36354), which will include an update to our host a Blazor WASM app on GH Pages article.

I noticed this situation myself when I went to update the XREF generator tooling that we use to produce documentation links, which is hosted by GH Pages ...

• https://dotnet.github.io/blazor-samples/
• https://github.com/dotnet/blazor-samples/tree/main/BlazorWebAssemblyXrefGenerator
• https://github.com/dotnet/blazor-samples/blob/main/.github/workflows/static.yml

In spite of that app being published with the 10.0 SDK via that static.yml file, the fingerprint segment survives the publish and there's no import map in the published index.html file. Blazor fails to start.

Of course, I quickly worked around it by taking the fingerprint segment out of the Blazor script tag. The app runs fine without fingerprinting.

As @davidroth was just asking and going back to the discussion ...

the need for either disabling fingerprint generation or to add a post process step

That part I understand, but WRT this part of your response .....

because there is no place to put importmap to and Blazor part of the application is not post-processed with any JavaScript tooling. We rely on one of these two mechanisms.

... is still a bit confusing to me. Can you explain that piece a bit more fully for the articles? Exactly what server/hosting/publishing conditions lead to this problem?

Also, I see Javier marked that PU issue for 11.0 work, so I assume the plan is that for publish in 11.0 that this problem will be resolved [i.e., the work will result in functional fingerprinting for an app published to GH Pages (for example) following an 11.0 SDK publish]. Is that correct?

[guardrex]

@maraf ... You might be OOF. I'll work on this further on your return if you're out right now.

[maraf]

As a result of discussion in https://github.com/dotnet/aspnetcore/issues/64282#issuecomment-3532754642 I believe that the steps of publishing a standalone wasm app need to have the clarification that you have to disable fingerprinting or build a custom loader as blazor.webassembly.{fingerprint}.js won't directly load dotnet.{fingerprint}.js.

This is true if the application isn't using an HTML document produced as part of the .NET build/publish process. In the original discussion, the situation was about publishing a blazor app and being consumed by other app through custom elements. In that case .NET build doesn't have an HTML document to put importmap to. In that case dotnet.js can have a fingerprint.

In spite of that app being published with the 10.0 SDK via that static.yml file, the fingerprint segment survives the publish and there's no import map in the published index.html file. Blazor fails to start.

That shouldn't be the case if everything is setup correctly. The BlazorWebAssemblyXrefGenerator.csproj doesn't opt-in to override html placeholders.

[guardrex]

The BlazorWebAssemblyXrefGenerator.csproj doesn't opt-in to override html placeholders.

I see. Thanks for clarifying. I should've caught that 🙈, but I'm 🧠-fried the end of every year (no vacation time during the year). Anyway ... I'll update the app and cross-link our GH Pages coverage to our client-side fingerprinting coverage that went up for .NET 10.