Debugging e2e DistributedApplicationTestingBuilder tests with Blazor wasm project times out

[mip1983]

I'm using 'DistributedApplicationTestingBuilder' to spin up aspire to run some e2e tests on my Blazor Web project (which uses wasm client side components).

In normal debugging of this project from visual studio, the Aspire dashboard will open as well as a separate browser window to debug the Blazor Web project (presumably this is some special instance that visual studio can attach it's web assembly debugging to). This was something that was fixed a while ago as for quite a while you couldn't debug Blazor wasm launched from Aspire.

When debugging my e2e Playwright/Specflow/nUnit tests from visual studio, it doesn't open the Aspire dashboard as you'd expect, but it opens a browser that's trying to attach to the Blazor Web project, which initially just stays blank.

The AppHost from DistributedApplicationTestingBuilder seems to spin up things on random ports rather than the one's assigned, so I guess that's why it stays blank, the site isn't there on the port it's expecting. Are these random ports the expected behavior? I don't seem to be able to specify them even if I define the endpoint in the aspire project.

You can debug for a while, but eventually this timeout error occurs:

When it does, it closes the blank browser which terminates debugging, making it hard to troubleshoot e2e tests.

So the primary issue is: Is it possible for VS not to try and launch/attach this browser specifically when it's debugging tests?

Secondarily:
In the longer term, is there a tidier way for VS to attach web assembly debugging without needing to launch this special instance, i.e. attach to tabs/windows opened from the aspire dashboard? It is convenient it opening on debugging, but inconsistent with other projects like blazor server.

[mitchdenny]

@ReubenBond PTAL

[ReubenBond]

Error handling/propagation for this case is improved in main. Until the next release, I can suggest enabling the trapping of all thrown exceptions in VS so you can see if there's an exception.

The version in main also fixes an issue with the launch profile not being set when running under the testing builder, which may be an issue here.

[mip1983]

Ok, so there is a version (main) that will pick up the launch profiles and launch the site on the configured launch profile ports instead of the random ones when testing?

I guess this will help this blank window launch and open the blazor site so the debugger can attach, which will allow the tests to run without being stopped by this timeout. However, I'd suggest this window shouldn't try and open when running under the testing builder. (Playwright launches it's own browser(s) to do it's testing so this window isn't useful as far as I can tell).

When you say 'main' is that your internal working version of Aspire or VS?

[mitchdenny]

The main branch of dotnet/aspire repo.

[kvenkatrajan]

Please try in 8.1 and update with details if still encounter any issues

[attilah]

In our solution with 8.1 we just hit the very same thing, the ports in the launch profiles are not taken into account when running the app through test builder from a fixture.

[ReubenBond]

@attilah are you able to provide any more info, or a repro?

[joperezr]

@ReubenBond can you make sure this is in the right milestone?