StaticWebAssetBasePath not taken into account with JavaScript module initalizer

[rogihee]

I'm trying out the new experimental package (to circumvent firewalls blocking dlls) to customize the blazor webassembly loading process. I have multiple hosted apps and use the StaticWebAssetBasePath project property to set a custom root path per app, and use a custom setup as described in the section Hosted deployment with multiple apps. Sample here: https://github.com/rogihee/BlazorAppBundle

Without the MultipartBundle package everything is published to the correct wwwroot/firstapp path. After adding the package, the blazor boot.json is copied to _framework and the javascript module initializer to _content/package. These files should be in the firstapp directory, though:

Note that the sample does not run out of the box. If I publish and merge the files / folders to /firstapp manually, everything works. Apparantly, whenever there is an extension of Javascript module initializer, the StaticWebAssetBasePath is not taken into account anymore.

To Reproduce

Download the source and run the project, it fails: https://github.com/rogihee/BlazorAppBundle

Publish the FolderProfile and merge the folders in wwwroot into firstapp subdir and dotnet run the project it works.

Exceptions (if any)

Further technical details

• ASP.NET Core version: 6.0.100
• The IDE (VS / VS Code/ VS4Mac) you're running on, and its version: VS2022

[ghost]

Thanks for contacting us. We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[javiercn]

There seems to be a configuration issue in the app.

The server needs to be configured to serve the files from the base path, which is not currently doing. It can be done either with //needs app.UsePathBase("/firstapp"); or using app.Map("/firstapp") which I believe does the same.

app.MapWhen(ctx => ctx.Request.Path.StartsWithSegments("/firstapp"), first =>
{
    //needs app.UsePathBase("/firstapp");
    first.UseBlazorFrameworkFiles();
    first.UseStaticFiles();

    first.UseRouting();
    first.UseEndpoints(endpoints =>
    {
        endpoints.MapControllers();
        endpoints.MapFallbackToFile("firstapp/{*path:nonfile}", "firstapp/index.html");
    });
});


app.MapGet("/firstapp/app.bundle", (HttpContext context) =>
{
    string? contentEncoding = null;
    var contentType = "multipart/form-data; boundary=\"--0a7e8441d64b4bf89086b85e59523b7d\"";
    var fileName = "app.bundle";


    var acceptEncodings = context.Request.Headers.AcceptEncoding;
    if (StringWithQualityHeaderValue.TryParseList(acceptEncodings, out var encodings))
    {
        if (encodings.Any(e => e.Value == "br"))
        {
            contentEncoding = "br";
            fileName += ".br";
        }
        else if (encodings.Any(e => e.Value == "gzip"))
        {
            contentEncoding = "gzip";
            fileName += ".gz";
        }
    }


    if (contentEncoding != null)
    {
        context.Response.Headers.ContentEncoding = contentEncoding;
    }
    return Results.File(
        app.Environment.WebRootFileProvider.GetFileInfo(Path.Combine("firstapp", fileName)).CreateReadStream(),
        contentType);
});

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[mkArtakMSFT]

Hi. Thanks for contacting us. We're closing this issue as there was not much community interest in this ask for quite a while now. You can learn more about our triage process and how we handle issues by reading our Triage Process writeup.