Not launching debugger

[teqdruid]

Hi all-

I'm having an issue wherein when I try to debug a test, it just sits there with the waiting animation next to the test name. The debugger doesn't launch. Here's the output in the "Test Explorer" output window:

Test run for Esi.Core.Tests.ToyUnitTest.ReadSchemaTest, expecting 1 test results file(s) in total
Executing dotnet build in c:/code/esi/src/core
Executing dotnet test --no-build --logger "trx;LogFileName=C:\Users\jodemme\AppData\Local\Temp\test-explorer-g26BGW\0.trx" --filter "FullyQualifiedName=Esi.Core.Tests.ToyUnitTest.ReadSchemaTest" in c:/code/esi/src/core
Process 32220 started
Waiting for debugger to attach
Waiting for debugger to attach
Waiting for debugger to attach
Waiting for debugger to attach
Waiting for debugger to attach
Waiting for debugger to attach
Waiting for debugger to attach
Waiting for debugger to attach

This is an nunit test which runs fine with 'dotnet test' at the console. It is in an sln which is not at the root directory. It is targetting dotnetcore3.1 and the csproj has the following references:

    <PackageReference Include="nunit" Version="3.12.0" />
    <PackageReference Include="NUnit3TestAdapter" Version="3.15.1" />
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.4.0"/>

I'm running VSCode version:

Version: 1.42.1 (system setup)
Commit: c47d83b293181d9be64f27ff093689e8e7aed054
Date: 2020-02-11T14:45:59.656Z
Electron: 6.1.6
Chrome: 76.0.3809.146
Node.js: 12.4.0
V8: 7.6.303.31-electron.0
OS: Windows_NT x64 10.0.19041

I think this worked on a difference C# project... Am I doing something wrong? Or is this a bug?

[KevinMallinson]

Same here.

Did you figure it out @teqdruid ?

[teqdruid]

Nope

[skreisoft]

I'm having the same issue. "Waiting for debugger to attach". Any updates on this?

[JohnGalt1717]

Me too.

[stefanforsberg]

Hey guys and sorry for slow updates.

I will take a look at this over the next few days/weeks. I have a feeling that the slightly hacky way we tried to approach this with is no longer working. The debug support was a proof of concept thing so it might be that we remove it all together. Will keep you posted.

[stefanforsberg]

Hello people. I just tried this with the latest version of the extension and I can attach to the debugger and debug via our extension.

How is your experience using the debugger built into the c# extension? It's the one shown in the code lens here

[JohnGalt1717]

Mine still hangs if there are multiple projects especially if there is multiple solutions in the same folder even if you try and debug a test in the project that omnisharp is currently watching.

[stefanforsberg]

@JohnGalt1717 Would it be possible for you to share something that causes this behavior? Much easy for me to troubleshoot then.

[JohnGalt1717]

@stefanforsberg Basically I have multiple test projects in the same SLN. As soon as I have more than one, and go to the .net test icon on the left side and right click on the test and choose debug test, the logs have a ton of "Waiting for attach..." messages and it never does.

The same works fine in VS.net

[JohnGalt1717]

Also for everyone in here I think everyone would benefit from the following being added to vs code so that @stefanforsberg and everyone maintaining this had a full framework for testing in vs code since vs code is a mess right now of multiple test tools stomping on each other etc. (i.e. Angular/jasmine, .net test, etc.)

microsoft/vscode#97919

It would be great to see this project be able to implement a standardized interface within vs code that manages tests etc.

[stefanforsberg]

@JohnGalt1717 Ah, thank your for bringing that discussion to my attention. I'll add a seperate issue for that so we have a more natural place to keep track of it.

[JohnGalt1717]

How's this coming? Looks like the PR doesn't actually fix the issue? This is a blocker for us moving entirely to vs code instead of visual studio.

[stefanforsberg]

@JohnGalt1717 Hey! I’ve not really gotten any feedback from my message here #247 (comment) so at the moment I don’t have much to go on.

What I need to figure out is if people are having issues with the debugger from omnisharp or this extensions debugger. If it’s the omnisharp one it’s hard for us to do anything since our debugger is using the one from omnisharp

[JohnGalt1717]

@stefanforsberg So what happens is that it starts it up, you see the project compile and execute, and you get this:

Build succeeded.
0 Warning(s)
0 Error(s)

Time Elapsed 00:00:05.60

Started debugging process #44528.
MSTest Executor: Test Parallelization enabled for \bin\Debug\netcoreapp3.1\Account.Tests.dll (Workers: 48, Scope: MethodLevel).
Debugging complete.

However, it doesn't return success nor fail in the test tab, and while you can run debug from the test tab, it won't respond to goto test anymore as a result. Only restarting visual studio code fixes it.

In the debug console the last line is: The program '[45204] testhost.exe' has exited with code 1 (0x1).

The test passes in vs .net and if you just run it directly.

[ManfredLange]

In relation to this issue: Output of the extension:

Starting extension
Finding projects for pattern /app/
Found 1 matches for pattern in folder /app
Evaluating match /app/
Adding directory /app/
Executing dotnet test -t -v=q in /app/
Executing dotnet vstest "/app/data/Piranha.Data.NH.Tests/bin/Debug/netcoreapp3.1/RimuTec.Piranha.Data.NH.Tests.dll" /ListFullyQualifiedTests /ListTestsTargetPath:"/tmp/test-explorer-discover-2xt8NA/output.txt" in /app/
Discovered tests with nunit. Found 10 in 1 directories
Could not find test (no symbols found)
Could not find test (no symbols found)
Could not find test (no symbols found)
Test run for RimuTec.Piranha.Data.NH.Repositories.AliasRepositoryTests.SaveGetById_NewAlias_HappyPath
Executing dotnet build in /app/
Executing dotnet test --no-build --logger "trx;LogFileName=/tmp/test-explorer-yPRPvN/0.trx" --filter "FullyQualifiedName=RimuTec.Piranha.Data.NH.Repositories.AliasRepositoryTests.SaveGetById_NewAlias_HappyPath" in /app/
Process 1263 started
Waiting for debugger to attach
Waiting for debugger to attach
Waiting for debugger to attach
Waiting for debugger to attach
Waiting for debugger to attach
Waiting for debugger to attach
Waiting for debugger to attach

In this solution there are two projects. One is targeting netstandard2.0 and contains the code under test. The other project is targeting netcoreapp3.1 and contains all tests. The extsion finds 10 tests, then logs three times that it cannot find the test. Not sure what that means. :-)

My environment:

• VS Code 1.51.0
• Omnisharp, i.e. ms-dotnettools.csharp: 1.23.5
• .NET Core Test Explorer 0.7.4

For information only, as I don't think this matters:

• Dev container with base image mcr.microsoft.com/dotnet/core/sdk:3.1 (this is based on a ubuntu image, so running in a Linux container)
• Docker Desktop 2.4.0.0 on Windows 10 (10.0.18363) using WSL2
• VS Code runs on host (Windows) and connects via extension "Remote Development" v0.20.0

[WaffleBuffer]

Hello, i can add a little thing.
If i try to debug a test via the "Debug Test" option in the test list the test explorer panel i get the same issues as everyone (waiting for debugger to attach).
However if i click the code lense button like shown in @stefanforsberg comment it works fine.

[tolgabalci]

Hello, i can add a little thing.
If i try to debug a test via the "Debug Test" option in the test list the test explorer panel i get the same issues as everyone (waiting for debugger to attach).
However if i click the code lense button like shown in @stefanforsberg comment it works fine.

Ditto. Works fine from the code lens links. But gets hung "Waiting for debugger to attach" if I try to debug from the TEST EXPLORER panel.

[lonix1]

Same here, and I can't repro the problem. Works from the codelens, but not from the panel.

[Kakunas]

Maybe i got some interesing informations for that problem

The Debug Test under the Fact don't work for me because i must use 32bit and omnisharp don' support it till now i think.

To the attach problem.
The debugger want to attach to the cmd process, not to the testhost in my case.
The cmd start the testhost i think and thats the problem

[millionbonus]

Just provide some workaround here

1. code lens
   Launch debug test with code lens
   

2. debug tests in context
   Right click on unitest function then click "Debug tests in Context"
   

3. debug tests in context with Command Palette
   Place cursor in unitest function then use Command Palette to execute "debug tests in context" command