Issue with static web asset fingerprinting

[ysmoradi]

V3.1.0

V3.2.0

[IvanJosipovic]

Please provide more detail like version of.net, type of Blazor you're using etc.

Does the issue occur with any of the samples?

[ysmoradi]

Samples are referencing the actual project, not the nuget package, so I didn't pay attention to them regarding this issue. It's happening on Blazor Auto, Server, Wasm and Hybrid (I've already spent time to make this project working on Blazor Hybrid as well 😅 so not kidding) .NET 9 with all packages set to the latest stable versions.

[ysmoradi]

<script src="_content/BlazorApplicationInsights/BlazorApplicationInsights.lib.module.js"></script>

Such a file does not exists in your nuget package anymore, that's the issue (":

[IvanJosipovic]

Looks like something changed in .net9 when the NuGet is published and breaks:

https://github.com/IvanJosipovic/BlazorApplicationInsights/blob/73792de43fc3fde5b4974c67efb34064a458ff9d/src/BlazorApplicationInsights/Components/ApplicationInsightsInit.razor.cs#L48

@ArcadeMode

[ArcadeMode]

Hey all,

This is a great .net 9 feature and imo should remain enabled. Look into adding .MapStaticAssets to your program.cs and refer to the js file through the ComponentBase.Assets property (in your app.razor). If the file ever changes the fingerprint is automatically updated and our blazor clients will fetch the new files.

[IvanJosipovic]

I agree that this is useful, however this call is being called within the library, and we have to make sure it supports older versions of .net. I will disable this feature for now until we figure out how it works and make it backwards compatible.

[ArcadeMode]

Ah good old backward compatibility.. Fair point. I will test how this behaves in my project that targets net9 and report back.

[IvanJosipovic]

One more things we should fix is the CI/CD pipeline, currently I do a dotnet run and run the tests against the wasm version. However, it won't exhibit the problem as it only appears on publish.

The pipeline should be updated to:

• dotnet publish
• dotnet tool install --global dotnet-serve
• Navigate to Publish Folder
• dotnet serve --port 5000
• dotnet test

[ArcadeMode]

I have noticed in my net9 migration that only project files present in the wwwroot at the start of the build are included in the fingerprinting process. It might be an idea to keep the wwroot files separate and add a before/after build hook that moves the files into the wwwroot. e.g. MudBlazor seems to be unaffected by this issue and their js files are generated as part of the build (and so the fingerprinting build step does not recognize their wwwroot files as project files). My own project has suffered from this exact thing where I was missing files that were supposed to be fingerprinted, but on a second build the fingerprinting would work..

Actually, my project was deployed with fingerprinted mudblazor files. (oddly enough, the files on disk are untouched, but there is a json file with a mapping of the fingerprints to the actual files and resolving them on the fly, so i am confused as to why the fingerprinted file ends up on disk in this particular case).

Anyway, the build step might fix some issues in a cheap way.

[ArcadeMode]

Regarding backwards compatibility, perhaps we could update the init.razor to something like:

@namespace BlazorApplicationInsights

@if (!IsWasmStandalone)
{
    @((MarkupString)script)

    <script src="GetScriptSrc()"></script>
}

@code {
    private string GetScriptSrc()
    {
        string src = "_content/BlazorApplicationInsights/BlazorApplicationInsights.lib.module.js";
#if NET9_0_OR_GREATER
        src = Assets[src];
#endif
        return src;
    }
}

I havent figured out how to do this on the fly for the IsWasmStandalone case, but with the no-fingerprinting-in-nuget fix, that should keep working as is I think.

[github-actions[bot]]

:tada: This issue has been resolved in version 3.2.1 :tada:

The release is available on GitHub release

Your semantic-release bot :package::rocket:

[ArcadeMode]

@IvanJosipovic It seems like v3.2.1 fixes the issue described by @ysmoradi. However fingerprinting is now being opt-out entirely, meaning even when included in another project (net9+) fingerprinted urls are not being generated for the js bundle. This does work for other libraries (like MudBlazor).

I think its worth trying to relocate the js file to a separate directory and adding a build step that moves the file into wwwroot during build + revert #352. This will result in a non-modified file name in the NuGet package, but allow consuming projects to generate fingerprinted urls for it by themselves.

[IvanJosipovic]

Is there any guidance from MS on how to deal with this?

[ArcadeMode]

There appear to be some issues with the fingerprinting feature, I am unsure what is the point of exporting fingerprinted files in a nuget package in the first place, that may be worth opening an issue for. Furthermore there seems to be little guidance on usage of this stuff.