Published blazor application not able to resolve promises inside blazorwebassembly.js

[rangarks]

Is there an existing issue for this?

• [x] I have searched the existing issues

Describe the bug

Hello All,

I've been using blazor to achieve something very specific. Here's a little context of what I am doing. We have application written in .net mvc with knockoutjs on the front end. This application provides functionality to our users to only "read" the content, off late we started receiving requests to have the content modified by the users, however we started noticing that our existing application was out of date and we did not want to develop on it anymore. That being said we wanted to build some components that would integrate seamlessly with current app, and still allows us to move away from older tech.

That's where I decided to pursue blazor as the "new" tech to move forward. Within Blazor app I started developing one component at a time and then I published the app to the root of existing application and all my blazor code started living under _framework folder. Here's an entire article on how I am doing this - https://medium.com/p/7067ec8c6e7f

Assuming that you now understanding of what I am trying to do, I am now going to jump to the issue I am facing. I updated my .net5 blazor app to .net6 and with it I also updated Microsoft.AspNetCore.Components.WebAssembly package. The update seemed to have no breaking changes when I ran the blazor app individually, however when I published the application into the root of my host application, I started seeing error where blazorwebassembly.js was not able to load blazor.boot.json file.

Upon lot of googling and researching I did not find the cause of it and hence I decided to unminify the complied blazorwebassembly.js and decided to debug it line by line, and I found out that the code that there might be a bug within the js file (I am not sure of it). The code that tries to load blazor.boot.json never really completes the promise

Here's the code that breaks -

I added await on line 1421 in front of function execution "a" and when the function actually resolves it sends a response that looks like this -

The problem code seems to directly send the response instead of the actual url from the response.

Here's the modified version that seems to work -

If I do the above changes, the code works fine and I am able to load the components inside other application successfully.

At this point I am not sure how the blazorwebassembly.js gets generated, so I am not sure, if this is a bug or is it something to do with my approach of using blazor.

Can someone please take a look and guide me, if there's something I need to change in my approach.

I really love the way this has worked out for us, because I am able to write multiple components within same blazor app and load them separately on demand from the old host application.

Here's my program.cs from blazor

`

using Microsoft.AspNetCore.Components.WebAssembly.Hosting;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.JSInterop;
using System;
using System.Net.Http;
using System.Threading.Tasks;
using VMSvNext.Components;
using VMSvNext.Pages.Edit_Content_View.Material_Maintainence.ComplianceControl;
using MudBlazor.Services;

namespace VMSvNext
{
    public class Program
    {
        public async static Task Main(string[] args)
        {
            var builder = WebAssemblyHostBuilder.CreateDefault(args);
            var host = builder.Build();
            var jsRuntime = host.Services.GetRequiredService<IJSRuntime>();
            string component = await jsRuntime.InvokeAsync<string>("GetComponentToLoad");
            if(component != null)
            {
                if (component == "Compliance")
                {
                    builder.RootComponents.Add<ComplianceControl>("#compliance");
                }
                if(component == "StorageExplorer")
                {
                    builder.RootComponents.Add<StorageExplorer>("#storage-explorer");
                }
            }

            builder.Services.AddScoped(sp => new HttpClient { BaseAddress = new Uri(builder.HostEnvironment.BaseAddress) });
            builder.Services.AddMudServices();
            await builder.Build().RunAsync();
        }
    }
}

` Please let me know any more information is required.

Thank you.

Expected Behavior

No response

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

dotnet6

Anything else?

No response

[javiercn]

@rangarks thanks for contacting us.

This goes out of the scope of the issues we deal with here. From what I can tell you are trying to host a Blazor Webassembly app inside an old ASP.NET (full framework app). Am I getting this right?

I don't think we can help you in this case since this is not a scenario we support and it is not fully clear to us what you are doing or how. The best we can do is point you to the JS code for Blazor webassembly which lives here as that might help you with your troubleshooting.

If you deem that you found a bug and are able to succinctly and clearly communicate it to us, we will consider it for evaluation.

[rangarks]

@javiercn Thank you for your reply. Yes I am loading blazor app inside an mvc application using Blazor.start() method. I have written a component in blazor app, I then publish the application and then copy the _framework folder into the root of the .net mvc application and then I refer the blazor.webassembly.js in .mvc index.html and from within it I call blazor.start to start the blazor app, I guess Blazor.start will load all the files it needs from _framework folder. Up untill .net5 it was able to load everything fine and blazor app loaded completely fine, but ever since I updated to .net6 I started running into error upon calling blazor.start like here -

Not exactly sure what is going on inside of blazor.webassembly.js but it did seem like some piece of code was not await a network call to complete , and here's where I am lost. :(

[ghost]

This issue has been resolved and has not had any activity for 1 day. It will be closed for housekeeping purposes.

See our Issue Management Policies for more information.