Blazor: Static assets not found when using server/client projects at publish. [Includes workaround]

[Bartmax]

Describe the bug

referencing a file like <img src="/images/test.jpg" /> will work on development but not when publishing.
This means that you cannot dev and publish your project and reference the same files using the same request path, making the dev experience and publishing a pain.

To Reproduce

Steps to reproduce the behavior:

1. Use preview-6
2. add img tag on a .razor component that points to image on wwwroot at client project
3. run app in development and go to said component
4. See image is displayed correctly.
5. Publish project dotnet publish -o {destinationFolder}
6. Run published app
7. See 404 when requesting the static asset.

Expected behavior

Both in development and publish the reference URL should match via the UseClientSideBlazorFiles middleware

Screenshots

Additional context

The problem looks like the static file provider is configured to look into a wrong? dist folder.
Inside the dist folder there are NuGet static assets, so I think this is not wrong but we are missing some glue or consistency.

Workaround

on client project csproj, use the "newer" way to set static file path like this:

<PropertyGroup>
    <StaticWebAssetBasePath 
        Condition="$(StaticWebAssetBasePath) == ''">_content/{PackageId}</StaticWebAssetBasePath>
</PropertyGroup>

Note: PackageId is the name of your client project, something like WebApplication1.Client

UseStaticSideBlazorFiles middleware still fails to find the assets on this location, so you can use another staticfilesmiddleware like this:

On server project:

app.UseStaticFiles(new StaticFileOptions
{
    RequestPath = "",
    FileProvider = 
        new PhysicalFileProvider(
            Path.Combine(Directory.GetCurrentDirectory(), "wwwroot/_content/{PackageId}"))
});

[iAmBipinPaul]

[Blazor] Preview 6 blazorhosted project publish is broken #11185

[Bartmax]

For completeness and to help others with this issue, I include the complete workaround on server Startup.cs file.:

var publishFolder = Path.Combine(Directory.GetCurrentDirectory(), $"wwwroot/_content/{ClientProjectId}");
if (Directory.Exists(publishFolder))
{
    app.UseStaticFiles(new StaticFileOptions
    {
        RequestPath = "",
        FileProvider = new PhysicalFileProvider(publishFolder)
    });
    app.UseEndpoints(endpoints =>
    {
        endpoints.MapDefaultControllerRoute();
        endpoints.MapFallbackToClientSideBlazor<Client.Startup>($"_content/{ClientProjectId}/index.html");
    });
}
else
{

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapDefaultControllerRoute();
        endpoints.MapFallbackToClientSideBlazor<Client.Startup>("index.html");
    });
}

[mkArtakMSFT]

Thanks for contacting us, @Bartmax.
This should be fixed now and will roll out as part of the upcoming Preview 7 release.

[endeffects]

I still have this issue with preview7 when running a blazor client side application in a docker container.

[mkArtakMSFT]

@javiercn do we have a separate issue where we track the Docker specific scenario?

[javiercn]

@mkArtakMSFT No.

We have an issue for static web assets and docker, which partially impacts blazor client-side. The reason is currently blazor client-side uses two ways of bringing assets into the project.

• For the app it plugs in specific providers through UseBlazorClientSideFiles()
• For referenced libraries through static web assets it goes the normal static web assets route.
  • This one should work in preview7 and afterwards. Our own E2E tests use the new way of testing content this way.
  • On docker you need to fix the Dockerfile as described in Error in .Net Core 3 preview 6 with individual user accounts in Linux docker #11609 (comment)
  • For the non static-web assets way, you can probably get away with it if you do Regular mode in the container as it will force a publish on the app.

Publishing was broken for blazor client-side in preview6, but we fixed it in preview7.

I added a tracking issue for blazor client-side specific bits #12588

The staticweb assets piece I consider them tracked by #11609