Debugging Unit Test loses codelens Run Test / Debug Test - DebugSessionManager does not stop

Related to #1743

Environment data

dotnet --info output:

.NET Core SDK (reflecting any global.json): Version: 2.1.301 Commit: 59524873d6

Runtime Environment: OS Name: Windows OS Version: 10.0.17134 OS Platform: Windows RID: win10-x64 Base Path: C:\Program Files\dotnet\sdk\2.1.301\

Host (useful for support): Version: 2.1.1 Commit: 6985b9f684

.NET Core SDKs installed: 1.0.4 [C:\Program Files\dotnet\sdk] 2.0.2 [C:\Program Files\dotnet\sdk] 2.0.3 [C:\Program Files\dotnet\sdk] 2.1.2 [C:\Program Files\dotnet\sdk] 2.1.3 [C:\Program Files\dotnet\sdk] 2.1.4 [C:\Program Files\dotnet\sdk] 2.1.100 [C:\Program Files\dotnet\sdk] 2.1.101 [C:\Program Files\dotnet\sdk] 2.1.102 [C:\Program Files\dotnet\sdk] 2.1.103 [C:\Program Files\dotnet\sdk] 2.1.104 [C:\Program Files\dotnet\sdk] 2.1.105 [C:\Program Files\dotnet\sdk] 2.1.200 [C:\Program Files\dotnet\sdk] 2.1.201 [C:\Program Files\dotnet\sdk] 2.1.300 [C:\Program Files\dotnet\sdk] 2.1.301 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed: Microsoft.AspNetCore.All 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All] Microsoft.AspNetCore.All 2.1.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All] Microsoft.AspNetCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 2.1.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.NETCore.App 1.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 1.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 2.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 2.0.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 2.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 2.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 2.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 2.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 2.1.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs: https://aka.ms/dotnet-download PS D:\CBRock\XCellorator>

VS Code version: 1.24.1 C# Extension version: ms-vscode.csharp-1.15.2.omnisharp\1.30.1\OmniSharp.exe

Steps to reproduce

Create a TestServer that has a IHostedService with dependencies and do not perform a graceful close on the TestServer using the following code: this.testServerIam.Host.StopAsync().GetAwaiter().GetResult();. The OmniSharp.DotNetTest.DebugSessionManager will never report “Debug session ended”, it will be stuck with “Debug session started.”, even though the .NET Test Log says Debugging complete. The extra host process not being cleaned up / shutdown must be confusing omnisharp. In some cases the codelens may appear on a fresh restart but clicking the debug again will just hang with the debug starting in the output window (it will never start).

Expected behavior

Omnisharp debug session stops, codelens run/debug appears and a subsequent debug can be performed.

[schaveyt]

Still exists as an issue for me as well.

[seesharper]

@rchande @akshita31 @vhetet

I discovered something that might be useful.

In the repro project https://github.com/seesharper/Omnisharp-WebApi

If I run the test with the solution loaded, meaning both the test project and the webapi project, the test causes death to OmniSharp. Note that the test project does not even reference the web api project.

Now, If I open ONLY the test project, the test runs fine in debug mode.

So maybe it is related to what assemblies are being fed into the debugger or something in that direction?

When I think about this, the problem has been mostly prominent on project involving AspNetCore

UPDATE.

I managed to get it to fail even when loading just the test project, but I had to run the test(debug) like 20 times for it to fail. Could it be a memory thing? Or simply a timing issue somewhere?