search

dotnet / aspire

An opinionated, cloud ready stack for building observable, production ready, distributed applications in .NET
https://learn.microsoft.com/dotnet/aspire
MIT License
3.61k stars 401 forks source link

Aspire project with Blazor WASM/server project opens by itself #3145

Open NicoVermeir opened 5 months ago

NicoVermeir commented 5 months ago

I believe this started happening since Preview 4

Steps to reproduce:

This only happens with the Blazor template that gives you the WASM and Server projects, not when you selected either WASM or Server

davidfowl commented 5 months ago

@timheuer putting this on your radar.

timheuer commented 5 months ago

I think in this case the launching of the separate browser for Blazor is actually by-design with the way we have to wire up the wasm debugger. Will need @BillHiebert to comment if there is any more silent ways of doing it but I think we need the client running (an instance of chrome/edge) to have something to attach to.

BillHiebert commented 5 months ago

@timheuer - the separate browser is expected when using F5 since we need to configure the browser for WASM debugging. The 2nd part of this I am not sure about. The browser appears to have the proxy port, but the dashboard has the port from launchsettings.json. Not sure why that is.

ciaranodonnell commented 4 months ago

I am also experiencing this happening with now way to control it. The problem I have is that it fails to launch Chrome for some reason and gives a dialog about Puppeteer troubleshooting. If I hit ok on that model dialog then debugging ends. So far I can only see this happening with one project in my solution, although I have 2. The other doesnt seem to support WASM debugging which is really annoying, but better then only getting 60 seconds of debug time per run. Workaround is to make debugging use firefox which launches successfully.

It would be really nice to have some kind of indication that this is going to happen or to be able to toggle the behavior. I am on preview 5 as of this evening and the problem persists

timheuer commented 4 months ago

@NicoVermeir @ciaranodonnell Right now this is how the Wasm debugging works. Since it uses JavaScript debugging there needs to be a defined process to attach to and one that is also configured for remote debugging (--remote-debugging) (which likely any default browser instance isn't). So when we have a Blazor Wasm project we launch an instance of the browser with these settings and the debugger can attach to.

You can disable the auto launch by modifying the launchSettings.json in the Wasm project and setting launchBrowser:false there -- but then you won't get the Wasm debugging experience...maybe a mitigation to use and turn it on when you want to debug Wasm as well.

ciaranodonnell commented 4 months ago

Appreciate the response. The reason I think its a challenging developer experience is that I have 3 blazor wasm projects in my solution that all have that launchBrowser:true and it only launches it for one of the projects. The newest one. The others have been in there for months and other than a period a few weeks ago where it did this for an afternoon, they've never had the second browser launch. I was having to launch my own debug browser and debug the C# in the chrome dev tools (Which was a terrible experience of its own). I want the WASM debugging, but I want it to actually launch the browser successfully, and if it cant I don't want it to model over my VS and then tear it all down when I dismiss the error.

timheuer commented 4 months ago

@ciaranodonnell the multiple wasm apps is an interesting scenario. Well check it out. Are they all hosted in the same server app? Can you describe that config a bit more and what the apphost looks like. Better if you can mock a sample repo?

timheuer commented 4 months ago

@ciaranodonnell I just tried two Wasm projects (hosted in two indepdendent server projects, which are added to Aspire apphost). Indeed only one client app launched. I wanted to make sure this matches your same configuration:

mtbayley commented 4 months ago

I am noticing this issue as well. It makes it difficult to debug my blazor webassembly application from Aspire.

miegir commented 2 months ago

I first experimented with Aspire and noticed this issue. And, maybe the entire AppHost project can be launched in that browser instance set up for WASM debugging when there is at least one WASM project exist?

Matthewsre commented 1 month ago

Ran into this problem today as well. I have both Server and WASM Blazor projects that were updated to .net 8 (without using the new stuff, just version bump approach until Azure auth for Web App is sorted out).

I finally was able to get my Blazor Server and WebAPI projects working today with Aspire after having a tough time dealing with the ports. I finally figure out that the applicationUrl in the launch profile only works if you have a single port (For example, this works: "https://localhost:44373", but this was not working: "https://localhost:44373;http://localhost:44374").

The dashboard is finally reflecting the port from the launch profiles, but it always pops up a new browser with the blazor window using a random port. The port used in the new window is also displayed on the Structured logs tab: "Now listening on: https://localhost:64318". When debugging, I just close this window and use the link from the Dashboard (Not a great experience, but it at least works!).

Throughout this whole process it felt like there is a huge gap regarding Blazor WASM standalone and I was really disappointed to learn it isn't supported. I couldn't find anything in the documents regarding that and only discovered it wasn't supported until after searching through github issues. I couldn't figure out why I would right click => Add => .Net Aspire Orchestration Support for my WASM standalone project and it was saying it succeeded, but nothing changed.

Matthewsre commented 1 month ago

@timheuer - the separate browser is expected when using F5 since we need to configure the browser for WASM debugging. The 2nd part of this I am not sure about. The browser appears to have the proxy port, but the dashboard has the port from launchsettings.json. Not sure why that is.

Not sure if this helps for your scenario (or if you already solved it), but today I was able to get the browser for WASM debugging to use the port from the launchsettings.json by disabling the proxy using .WithEndpoint("https", endpoint => endpoint.IsProxied = false); when adding the project with .AddProject in the AppHost Program.cs (example from docs)