dotnet
Unable to debug Aspire Resource project while testing
Is there an existing issue for this?
- [X] I have searched the existing issues
Describe the bug
When following the docs to create test projects which spin up Aspire services for integration tests, it is not possible to hit a breakpoint and debug the services just like we would when running the Aspire project outside the tests.
Breakpoints on the test code and the AppHost itself are hit just fine. Only the projects orchestrated by the AppHost which are not.
Expected Behavior
To be able to set breakpoints on the downstream Aspire projects and they would be hit while debugging tests, just as in the normal runtime of Aspire apps.
Steps To Reproduce
- Follow the docs and add a test project to an existing Aspire solution: https://learn.microsoft.com/en-us/dotnet/aspire/fundamentals/testing?pivots=xunit
- Put a break point in any place on the downstream projects. It can be on Program.cs or any code that would be otherwise triggered as part of the tests;
- Run the test;
- Observe that the breakpoint is never hit;
I've tested and reproduced on VSCode and Rider. I have no Windows box to test on Visual Studio tho.
Exceptions (if any)
No response
.NET Version info
.NET SDK:
Version: 8.0.302
Commit: ef14e02af8
Workload version: 8.0.300-manifests.e4379c3d
MSBuild version: 17.10.4+10fbfbf2e
Runtime Environment:
OS Name: Mac OS X
OS Version: 14.5
OS Platform: Darwin
RID: osx-arm64
Base Path: /usr/local/share/dotnet/sdk/8.0.302/
.NET workloads installed:
[aspire]
Installation Source: SDK 8.0.300
Manifest Version: 8.1.0/8.0.100
Manifest Path: /usr/local/share/dotnet/sdk-manifests/8.0.100/microsoft.net.sdk.aspire/8.1.0/WorkloadManifest.json
Install Type: FileBased
Host:
Version: 8.0.6
Architecture: arm64
Commit: 3b8b000a0e
.NET SDKs installed:
6.0.417 [/usr/local/share/dotnet/sdk]
7.0.404 [/usr/local/share/dotnet/sdk]
8.0.100 [/usr/local/share/dotnet/sdk]
8.0.101 [/usr/local/share/dotnet/sdk]
8.0.201 [/usr/local/share/dotnet/sdk]
8.0.302 [/usr/local/share/dotnet/sdk]
.NET runtimes installed:
Microsoft.AspNetCore.App 6.0.25 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.14 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.1 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.6 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.25 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.14 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.1 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.2 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.6 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Anything else?
Aspire and ASP.Net on its latest versions.
Rider and VSCode also on its latest stable versions.
Are you using the latest version of vscode and C# DevKit
VSCode and Rider has the same effect on its latest versions.
I haven't dug too much into using vscode and the C# DevKit, but I had the same issue with both, on the same OS. Debugging unit tests in rider is a known issue, with a PR already merged into the EAP release of Rider. Here's the link to the issue: https://github.com/JetBrains/aspire-plugin/issues/185
Technically the PR is for the Aspire Plugin, but the version it was included in is not available in the latest stable release of Rider.
Once I switched to the EAP release, debugging of unit tests started working.
For vscode, not sure. I'd be interested in hearing what you find, if anything.
I don't think so, but step 3 says 'run the test' -- is that 'debug the tests' or just using run (either dotnet test or using the IDE test start points that are non-debug)?
Definitely a difference between IDE and non-IDE launching scenario.
VS:
https://github.com/user-attachments/assets/83eb61ed-661d-44f4-9ac0-ee1437c663ad
even in just 'run' it appears to launch the apphost under a debugger.
Contrast with VSC (and likely any other launcher), it is not and even 'debug test' in VSC is debugging the test, but not launching the apphost in same way that VS doe that gets me to debug it. /cc @AbhitejJohn @tmeschter
@timheuer sorry, I meant "Debug the tests" on step 3. (edited)
@DoubleTK I tried the EAP yesterday which has the Aspire plugin embedded and not as a "3rd party" extension. Still same problem for me.
It appears that somehow the debug session is not attaching the debugger to the orchestrated projects. The breakpoint "red circle" on the left of the line appears empty, as if it were disabled or like if no symbols were available.
@JakeRadMSFT i'm going to mark this as a high priority item for tooling features specific to the VS Code/DevKit side. If there is any additional information you and the team need to get this prioritized and assigned for an upcoming 9.x release please let me know how I can help.
Following up with a video here demonstrating the issue at hand in VS Code. Here you'll see how the breakpoint in the API Service project is unhit, whereas in VS it is hit during a debugging session. cc @JakeRadMSFT
https://github.com/user-attachments/assets/89d8ddfb-3ea9-4e69-a9a2-38f469bfa096
@bradygaster Need more time to investigate, let's move it to the next milestone
@galvesribeiro could you confirm if "C# DevKit - Test Explorer" output channel shows the following exception
========== Starting test run ==========
System.NotImplementedException: The method or operation is not implemented.
at Microsoft.VisualStudio.TestWindow.VSCode.Service.TestWindowCallbackService.LaunchDebugTestHostAsync(LaunchTestHostRequest launchRequest, CancellationToken cancellationToken)
at Microsoft.VisualStudio.TestWindow.Logging.ILoggerExtensions.CallWithCatchAsync[T](IInternalLogger log, Func`1 func, T defaultValue)
System.ArgumentException: Process with an Id of -1 is not running.
at System.Diagnostics.Process.GetProcessById(Int32 processId, String machineName)
at Microsoft.VisualStudio.TestWindow.Internal.RemoteAgent.TestingPlatform.Providers.ClientServerProfileBase.StartProcessWithDebuggerAsync(TestingPlatformLaunchConfig config)
Does C# DevKit has this option checked ?
System.NotImplementedException: The method or operation is not implemented. at Microsoft.VisualStudio.TestWindow.VSCode.Service.TestWindowCallbackService.LaunchDebugTestHostAsync(LaunchTestHostRequest launchRequest, CancellationToken cancellationToken) at Microsoft.VisualStudio.TestWindow.Logging.ILoggerExtensions.CallWithCatchAsync[T](IInternalLogger log, Func`1 func, T defaultValue) System.ArgumentException: Process with an Id of -1 is not running. at System.Diagnostics.Process.GetProcessById(Int32 processId, String machineName) at Microsoft.VisualStudio.TestWindow.Internal.RemoteAgent.TestingPlatform.Providers.ClientServerProfileBase.StartProcessWithDebuggerAsync(TestingPlatformLaunchConfig config)
That issue (GetProcessById not implement) might already have been fixed in the latest released C#DK? Relevant working item: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/2350411. Maybe try update C#DK to the latest and get another try.
Also, here's the log from my test explorer output window for reference
========== Test run finished: 1 Tests (1 Passed, 0 Failed, 0 Skipped) run in 45.4 sec ==========
Log verbosity changed to: diagnostic
========== Starting test run ==========
Debugger attached
[xUnit.net 00:00:00.01] xUnit.net VSTest Adapter v2.8.2+699d445a1a (64-bit .NET 8.0.13)
[xUnit.net 00:00:00.69] Starting: Bug5257
info: Aspire.Hosting.DistributedApplication[0]
Aspire version: 8.2.2+5fa9337a84a52e9bd185d04d156eccbdcf592f74
info: Aspire.Hosting.DistributedApplication[0]
Distributed application starting.
info: Aspire.Hosting.DistributedApplication[0]
Application host directory is: C:\Users\xiaoyuz\source\repo\Bug5257\Bug5257.AppHost
info: Aspire.Hosting.DistributedApplication[0]
Distributed application started. Press Ctrl+C to shut down.
info: System.Net.Http.HttpClient.Default.LogicalHandler[100]
Start processing HTTP request GET http://localhost:54093/weather
info: System.Net.Http.HttpClient.Default.ClientHandler[100]
Sending HTTP request GET http://localhost:54093/weather
info: Bug5257.AppHost.Resources.apiservice[0]
1: 2025-02-12T18:29:22.765Z 2025-02-12T10:29:22.7609096 info: Microsoft.Hosting.Lifetime[14]
info: Bug5257.AppHost.Resources.apiservice[0]
2: 2025-02-12T18:29:22.765Z Now listening on: https://localhost:54094
info: Bug5257.AppHost.Resources.apiservice[0]
3: 2025-02-12T18:29:22.769Z 2025-02-12T10:29:22.7697019 info: Microsoft.Hosting.Lifetime[14]
info: Bug5257.AppHost.Resources.apiservice[0]
4: 2025-02-12T18:29:22.769Z Now listening on: http://localhost:54095
info: Bug5257.AppHost.Resources.apiservice[0]
5: 2025-02-12T18:29:22.770Z 2025-02-12T10:29:22.7706432 info: Microsoft.Hosting.Lifetime[0]
info: Bug5257.AppHost.Resources.apiservice[0]
6: 2025-02-12T18:29:22.770Z Application started. Press Ctrl+C to shut down.
info: Bug5257.AppHost.Resources.apiservice[0]
7: 2025-02-12T18:29:22.771Z 2025-02-12T10:29:22.7720043 info: Microsoft.Hosting.Lifetime[0]
info: Bug5257.AppHost.Resources.apiservice[0]
8: 2025-02-12T18:29:22.771Z Hosting environment: Development
info: Bug5257.AppHost.Resources.apiservice[0]
9: 2025-02-12T18:29:22.771Z 2025-02-12T10:29:22.7720820 info: Microsoft.Hosting.Lifetime[0]
info: Bug5257.AppHost.Resources.apiservice[0]
10: 2025-02-12T18:29:22.771Z Content root path: C:\Users\xiaoyuz\source\repo\Bug5257\Bug5257.ApiService
info: Bug5257.AppHost.Resources.webfrontend[0]
1: 2025-02-12T18:29:23.465Z 2025-02-12T10:29:23.4608146 info: Microsoft.Hosting.Lifetime[14]
info: Bug5257.AppHost.Resources.webfrontend[0]
2: 2025-02-12T18:29:23.465Z Now listening on: https://localhost:54099
info: Bug5257.AppHost.Resources.webfrontend[0]
3: 2025-02-12T18:29:23.468Z 2025-02-12T10:29:23.4692532 info: Microsoft.Hosting.Lifetime[14]
info: Bug5257.AppHost.Resources.webfrontend[0]
4: 2025-02-12T18:29:23.468Z Now listening on: http://localhost:54100
info: Bug5257.AppHost.Resources.webfrontend[0]
5: 2025-02-12T18:29:23.471Z 2025-02-12T10:29:23.4713274 info: Microsoft.Hosting.Lifetime[0]
info: Bug5257.AppHost.Resources.webfrontend[0]
6: 2025-02-12T18:29:23.471Z Application started. Press Ctrl+C to shut down.
info: Bug5257.AppHost.Resources.webfrontend[0]
7: 2025-02-12T18:29:23.472Z 2025-02-12T10:29:23.4727471 info: Microsoft.Hosting.Lifetime[0]
info: Bug5257.AppHost.Resources.webfrontend[0]
8: 2025-02-12T18:29:23.472Z Hosting environment: Development
info: Bug5257.AppHost.Resources.webfrontend[0]
9: 2025-02-12T18:29:23.472Z 2025-02-12T10:29:23.4728296 info: Microsoft.Hosting.Lifetime[0]
info: Bug5257.AppHost.Resources.webfrontend[0]
10: 2025-02-12T18:29:23.472Z Content root path: C:\Users\xiaoyuz\source\repo\Bug5257\Bug5257.Web
info: System.Net.Http.HttpClient.Default.ClientHandler[101]
Received HTTP response headers after 2479.6659ms - 200
info: Polly[3]
Execution attempt. Source: '-standard//Standard-Retry', Operation Key: '', Result: '200', Handled: 'False', Attempt: '0', Execution Time: 2508.3406ms
info: System.Net.Http.HttpClient.Default.LogicalHandler[101]
End processing HTTP request after 2587.5971ms - 200
Test Explorer is for launching the test projects DLL/EXE under the debugger. We observe that the debugger correctly hits breakpoints inside the test.
However, breakpoints in other projects appear to be affected by an issue with the debugger handling debug symbols. It seems there is a mismatch between the .pdb and .dll files.
In the Debug Console, we can see multiple messages like the following:
Breakpoint warning: A copy of Program.cs was found in Bug5257.AppHost.dll, but the current source code is different from the version built into Bug5257.AppHost.dll.
To allow this breakpoint to be hit: Add '"requireExactSource": false' to launch.json and restart debugging. - c:\Users\<User>\source\repos\AspireBug5257\Bug5257.ApiService\Program.cs:7
Despite this warning, we can confirm Program.cs has not changed, yet the debugger incorrectly detects it as modified.
I am seeing this in Visual Studio 2022 on Windows with Aspire 9.3. Breakpoints in integration test code and the app host are hit, but breakpoints in other projects are not hit (the breakpoint dot in the source window says "The breakpoint will not currently be hit").
I have disabled "Just My Code" and set "Require source files to exactly match the original version" to false. I don't see any errors in the debug console.
This is an awful bug that need to be fixed ASAP! Please release a patch with just this bug fixed!!! ASAP
Oh sorry about that it seem to be currently fixed for some reason. Maybe visual studio update fixed this..
Verify the following aspire test project on both VS d17.14.7 and C#DK 1.30.44, both seems working. Since this issue has been there for a while, so maybe update VS/C#DK and give another shot?
Link to repo)
It still doesn't work for me in VS 17.14.9. When I debug an integration test, breakpoints in my Aspire AppHost get hit, but breakpoints in my ASP.NET Core app do NOT get hit.
@chalcolith Can you let us know if debugging in this example repo works for you, that would help us narrow down the possible broken place
@LittleLittleCloud I can debug successfully in your example repo. My actual project is proprietary; I'll try to get a minimal repro for you.
Having this problem in VS 17.14.9 using the JetBrains test runner 243.0.20241111.161023, on Aspire SDK 9.4
Breakpoints in the tests work fine, breakpoints in the fixtured AppHost'd projects are not hit, nor are thrown exceptions caught, but symbols are loaded.
I am able to 'Run Debug' tests then Debugger.Launch() inside the hosted app and force it to attach. Debugger.IsAttached is false when launching the tests in debug mode (which obviously is why we are having this problem).
Launching the test with VS Test Runner does allow the breakpoints to bind, so I'm not completely stuck.
Attempts to fix:
- ❌ My app is running
WithReplicas(3), but commenting this out to a single instance has no effect. - ❌ Updated VS to
17.14.10 - ❌ Updated JetBrains test runner
251.0.20250617.82607 - ✅ Launched with VS Test Runner
@jamescarter-le Does JetBrains test runner support aspire IDE protocol? VS Test Explorer supports IDE protocol by spinning up an aspire server to work with DCP when you launch aspire tests. This enables testing apphost starting aspire resources using IDE instead of CLI and that's why breakpoints can be bound in VS Test runner.
While trying to find out why a co-worker's test debug session wouldn't attach to the ProjectResource, we noticed that on my machine (which works), a TESTINGPLATFORM_EXPERIMENTAL_VSTEST_RUNSETTINGS env var is passed down to the asp.net core project. The env var was not passed on my co-worker's machine. I don't know if this can help the investigation.
On both our machines, the global.json forces 9.0.305. We have VS Pro 17.14.16 with ASP.NET and Web Tools 17.14.122.59099.
