-
Notifications
You must be signed in to change notification settings - Fork 326
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Debugging tests in VS Code no longer works in preview SDKs #2468
Comments
@cvpoienaru could this be caused by the recent child process debugging changes? Only other thing I can think of is that the xunit packages got an update. |
@nohwnd This is dogfood blocking -- could we prioritize looking into it? |
@nohwnd @cvpoienaru I believe this issue is that OmniSharp-Roslyn expects the TestProcessStartInfo as a response to the "TestExecution.GetTestRunnerProcessStartInfoForRunSelected" message (See my comment dotnet/vscode-csharp#3459 (comment)). When we do not receive that message we pass an empty These are the message we are getting in response to "TestExecution.GetTestRunnerProcessStartInfoForRunSelected"
|
@nohwnd @cvpoienaru Is it a valid expectation that when we send the "TestExecution.GetTestRunnerProcessStartInfoForRunSelected" message we will receive a serialized TestProcessStartInfo message in response? |
I would say so, but would wait for @cvpoienaru to confirm. |
@JoeRobich TL;DR: yes, this is a valid expectation indeed. I tested this in VS 2019 and when we receive a I was also able to replicate the issue on VS Code and I'm continuing the investigation. |
@cvpoienaru OmniSharp-Roslyn has always passed DebuggingEnabled when it requested TestProcessStartInfo - https://github.com/OmniSharp/omnisharp-roslyn/blob/master/src/OmniSharp.DotNetTest/VSTestManager.cs#L152-L158 I think the issue is that now causes us to branch around where the CustomTestHostLaunch message would be returned - 3f18c87#diff-92e085e9ec715b8834b83666cd69c365R421-R422 |
@cvpoienaru Verified not setting DebuggingEnabled to true resolves this issue for us. |
@JoeRobich @agocke I think I may have found the root cause for this issue. Long story short, what I previously said about the expectation being valid may no longer hold. Does VS Code use the @shyamnamboodiripad @AbhitejJohn @nohwnd @pavelhorak this issue is related to our TAEF changes (the PR can be found here). I was mistaken at first to think it's not related, but I can now see that We use the new workflow ( This happens primarily because, as expected, the |
@cvpoienaru We implement the second option. For the time being not setting DebuggingEnabled resolves this issue for us. I will open an issue to investigate moving to the new attach debugger workflow, but, with limited resources and debugging working again, it isn't a priority for us. Thanks for your help investigating this issue our users will be very happy to have this resolved. =) |
Description
Up until an SDK update a few days ago, everything worked fine. Now, every time I try to debug a test in VS Code I get the error "Error processing launch options at field: program". I looked through the Omnisharp logs and it looks like they're passing the appropriate path to the target binary through the VS Test manager, and it looks like the arguments are bad when coming into the debugger (path is null). VSTest probably broke something in between and the correct arguments are no longer being passed through.
Steps to reproduce
I created a simple netcore project with a single XUnit test and the appropriate references
Then, click on "Debug test" in the CodeLens window in Omnisharp on any test. A dialog with the error message "Error processing launch options at field: program" will appear.
Diagnostic logs
Can provide more if necessary, but this should be easy to reproduce locally.
Environment
The text was updated successfully, but these errors were encountered: