Omnisharp-vscode: Debugger Fails to start when attempting to debug test

[fedoranimus]

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.1)

Product Information:
 Version:            1.0.1
 Commit SHA-1 hash:  005db40cd1

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.12
 OS Platform: Darwin
 RID:         osx.10.12-x64
 Base Path:   /usr/local/share/dotnet/sdk/1.0.1

VS Code version:
1.11.2 & 1.12.0
C# Extension version:
1.9.0

The following lines are in my .csproj files as well:

<TargetFramework>netcoreapp1.1</TargetFramework>
<DebugType>portable</DebugType>
<RuntimeFrameworkVersion>1.1.1</RuntimeFrameworkVersion>

Steps to reproduce

• Create an test class using xunit with a test
  C# public class UnitTest { [Fact] public void TestFoo() { Assert.True(false, $"{nameof(TestFoo)} was run."); } }
• Place a breakpoint
• Click the "Debug Test" CodeLens link

Expected behavior

The debugger launches, PDBs are loaded, and VSCode hits a breakpoint.

Actual behavior

The first time, the debugger loads, but no PDBs are loaded so VSCode never hits a breakpoint.

The second time, the debugger fails to load and VSCode presents the message: "Failed to start debugger: null"

[gregg-miskelly]

@fedoranimus can you look in the debug console during the first launch, and see if you get a message like:

WARNING: Unable to connect to debuggerEventsPipeName '{0}'. {1}

If so, what is your complete message?

[powellcj12]

I finally tracked down what caused me to encounter this (as mentioned in the previous issue). Possibly somewhat of a different (but maybe related?) issue.

In my test directory, I remove the obj and bin directories from whatever the previous build output was. Then I change to have the TargetFramework in my csproj file:

  <PropertyGroup>
    <TargetFramework>netstandard1.5</TargetFramework>
  </PropertyGroup>

Trying to to dotnet test (after the requisite dotnet restore; dotnet build) will fail, and if I try to use the 'debug test' option in the GUI I get the error message:

Failed to start debugger: null

I consider this "user error" though (after doing a bit of research) so I switch back the TargetFramework to netcoreapp1.1. Now I can get dotnet test to run/succeed but still get the same error trying to use the GUI. Things then go back to normal if I restart VS Code or remove the bin/obj directories and rebuild.

So seems like there's some issue about which build output the extension is using when launching the debugger from the GUI? Again, that's probably different than the core issue going on here - let me know if I should open a separate issue for that.

[fedoranimus]

@gregg-miskelly I do not see that line in the Debug Console, I just see a long list of Loaded '/usr/local/share/dotnet/shared/Microsoft.NETCore.App/1.1.1/System.Private.CoreLib.ni.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.

However, I do get a VSCode error sometimes as well: Debug adapter process has terminated unexpectedly

[gregg-miskelly]

@fedoranimus RE: 'Debug adapter process has terminated' - by chance do you have repo steps? If you can enable logging that might allow us to track down what is going on. Unfortunately you will need the 'full' method for unit test debugging scenarios.

[gregg-miskelly]

I should also say - the 'Skipped loading symbols' messages are normal.

[fedoranimus]

@gregg-miskelly Yup, I expect the 'skipped loading symbols' messages.

I'll enable logging and see what comes up - thanks.

[StephenRedd]

I'm seeing the same problem with xunit tests. Clicking run test works, debug test doesn't... it either dies quietly, or throws up "Failed to start debugger: null". The same project works perfectly in VS 2017 though.

Turning on engineLogging as outlined here does not create a log file when using the codelense links, nor is any error shown in any of the output windows.

In this case, this is a .net core 1.1 class library project with an xunit test project. The csproj settings are identical to the ones in the initial description above.

[fedoranimus]

I can echo what @StephenRedd says. I do not see a log file created and the Debug Console doesn't display any warnings or errors.

My reproduction steps are that I open VSCode, navigate to a test class and press the "Debug Test" codelens link. The first time the debugger will start but not hit anything. All subsequent times I'll get the Failed to start debugger: null.

Is there anything else I can do to provide additional information?

[DustinCampbell]

Could you provide your OmniSharp Log?

[fedoranimus]

Where is that located?

[DustinCampbell]

Sorry, forgot to mention it.

In VS Code, select View->Output. Then, choose "OmniSharp Log" from the combobox in the top-right corner of the Output pane.

[fedoranimus]

Here is my log

I noticed one line in it that may be interesting:
[warn]: OmniSharp.MSBuild.MSBuildProjectSystem Failed to process project file '/Users/timdturner/Github/covalence-server/src/Covalence.API/Covalence.API.csproj'. /Users/timdturner/Github/covalence-server/src/Covalence.API/Covalence.API.csproj(1,1) System.InvalidOperationException: The operation cannot be completed because a build is already in progress.

[DustinCampbell]

Any chance you could share your project?

[fedoranimus]

I cannot, sadly.

[StephenRedd]

You can fork the NullMailer repo to reproduce

• Open vs code for the the repo root folder.
• Pick a test in the "NullDesk.Extensions.Mailer.Core.Tests" project
• Debug test

Attached is the omnisharp log when I do the exact steps listed. In this case, the debugger just didn't start, but it did not give the pop-up error... when this happens there is no indication if anything is happening outside of the output windows.

nullmailer-omnisharp-debug-log.txt

[DustinCampbell]

@StephenRedd:

[StephenRedd]

Can I borrow your computer for a few weeks while we work on our other projects having this problem?

I have two systems where this doesn't work, but I'll verify by going to one of our servers where none of this is installed --then installing fresh VS Code, the dotnet SDK, and clone this repo to see how it behaves in a vanilla environment.

It is sorta re-assuring that it does work somewhere.

[DustinCampbell]

Could you share your OmniSharp Log from one of those systems? Just open the project, wait for OmniSharp to finish loading (i.e. the "run/debug test" adornments appear) and click "debug test". Provide the log after the error appears.

[StephenRedd]

I attached the log for one in the above comment, but I'll get some more logs for you from the other systems and projects too.

[DustinCampbell]

Sorry, I missed that. It doesn't look it hit the failure in your log.

Out of curiosity, have you tried waiting a bit longer? There are a couple of things that happen under the hood (for which there's no currently UI feedback) which might take awhile before the debugger spins up. Most importantly, it builds the project, which might take awhile.

[DustinCampbell]

If it's still spinning up the debug session and you click the "debug test" annotation again (#1421), it would explain why you get that error.

[StephenRedd]

I'll test waiting a while before trying to launch the test as well and capture the log, but generally speaking I have waited a while. If you take that log above, wait on the same system for 5 minutes, then click debug again here is what the next messages will look like:

[fail]: Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware
        An unhandled exception has occurred: Debug session already started.
System.InvalidOperationException: Debug session already started.
   at OmniSharp.DotNetTest.DebugSessionManager.VerifySession(Boolean isStarted)
   at OmniSharp.DotNetTest.DebugSessionManager.StartSession(TestManager testManager)
   at OmniSharp.DotNetTest.Services.DebugTestService.Handle(DebugTestGetStartInfoRequest request)
   at OmniSharp.Middleware.Endpoint.EndpointHandler`2.<HandleSingleRequest>d__18.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at OmniSharp.Middleware.Endpoint.EndpointHandler`2.<Process>d__16.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at OmniSharp.Middleware.EndpointMiddleware.<Invoke>d__7.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.<Invoke>d__6.MoveNext()
[info]: OmniSharp.Middleware.LoggingMiddleware
        /v2/debugtest/getstartinfo: 500 6112ms
[info]: OmniSharp.DotNetTest.VSTestManager
        read: {"MessageType":"TestSession.Connected","Payload":null}
[info]: OmniSharp.DotNetTest.VSTestManager
        read: {"MessageType":"ProtocolVersion","Payload":1}
[fail]: OmniSharp.DotNetTest.DebugSessionManager
        Debug session not started.

[DustinCampbell]

Yeah, so something's failing before the debug session kicks off. 5 minutes is a pretty long time.

I'm going to planning to push out the first beta of our 1.10 release later today, which should have more reporting during that time when you're just waiting. Hopefully that will reveal something.

[fedoranimus]

I'm seeing the same issue as @StephenRedd when I debug a second time. This occurs only a couple seconds after I click the CodeLens link.

[fail]: OmniSharp.DotNetTest.DebugSessionManager
        Debug session not started.
[fail]: Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware
        An unhandled exception has occurred: Debug session already started.
System.InvalidOperationException: Debug session already started.
  at OmniSharp.DotNetTest.DebugSessionManager.VerifySession (System.Boolean isStarted) [0x00055] in <7124f501081e464b97067a98f0b0e806>:0 
  at OmniSharp.DotNetTest.DebugSessionManager.StartSession (OmniSharp.DotNetTest.TestManager testManager) [0x00011] in <7124f501081e464b97067a98f0b0e806>:0 
  at OmniSharp.DotNetTest.Services.DebugTestService.Handle (OmniSharp.DotNetTest.Models.DebugTestGetStartInfoRequest request) [0x0000d] in <7124f501081e464b97067a98f0b0e806>:0 
  at OmniSharp.Middleware.Endpoint.Exports.RequestHandlerExportHandler`2[TRequest,TResponse].Handle (TRequest request) [0x00000] in <30afbacdd97f44c59c542cdbc3e6fa9a>:0 
  at OmniSharp.Middleware.Endpoint.EndpointHandler`2+<HandleSingleRequest>d__18[TRequest,TResponse].MoveNext () [0x00092] in <30afbacdd97f44c59c542cdbc3e6fa9a>:0 
--- End of stack trace from previous location where exception was thrown ---
  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in <12e050e5b3d34326a1b4e2e7624e75da>:0 
  at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Threading.Tasks.Task task) [0x0004e] in <12e050e5b3d34326a1b4e2e7624e75da>:0 
  at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Threading.Tasks.Task task) [0x0002e] in <12e050e5b3d34326a1b4e2e7624e75da>:0 
  at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd (System.Threading.Tasks.Task task) [0x0000b] in <12e050e5b3d34326a1b4e2e7624e75da>:0 
  at System.Runtime.CompilerServices.TaskAwaiter`1[TResult].GetResult () [0x00000] in <12e050e5b3d34326a1b4e2e7624e75da>:0 
  at OmniSharp.Middleware.Endpoint.EndpointHandler`2+<Process>d__16[TRequest,TResponse].MoveNext () [0x0025e] in <30afbacdd97f44c59c542cdbc3e6fa9a>:0 
--- End of stack trace from previous location where exception was thrown ---
  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in <12e050e5b3d34326a1b4e2e7624e75da>:0 
  at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Threading.Tasks.Task task) [0x0004e] in <12e050e5b3d34326a1b4e2e7624e75da>:0 
  at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Threading.Tasks.Task task) [0x0002e] in <12e050e5b3d34326a1b4e2e7624e75da>:0 
  at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd (System.Threading.Tasks.Task task) [0x0000b] in <12e050e5b3d34326a1b4e2e7624e75da>:0 
  at System.Runtime.CompilerServices.TaskAwaiter`1[TResult].GetResult () [0x00000] in <12e050e5b3d34326a1b4e2e7624e75da>:0 
  at OmniSharp.Middleware.EndpointMiddleware+<Invoke>d__7.MoveNext () [0x000d8] in <30afbacdd97f44c59c542cdbc3e6fa9a>:0 
--- End of stack trace from previous location where exception was thrown ---
  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in <12e050e5b3d34326a1b4e2e7624e75da>:0 
  at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Threading.Tasks.Task task) [0x0004e] in <12e050e5b3d34326a1b4e2e7624e75da>:0 
  at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Threading.Tasks.Task task) [0x0002e] in <12e050e5b3d34326a1b4e2e7624e75da>:0 
  at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd (System.Threading.Tasks.Task task) [0x0000b] in <12e050e5b3d34326a1b4e2e7624e75da>:0 
  at System.Runtime.CompilerServices.TaskAwaiter.GetResult () [0x00000] in <12e050e5b3d34326a1b4e2e7624e75da>:0 
  at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware+<Invoke>d__6.MoveNext () [0x00080] in <54abb6e5c34d41e5b18eb3ce35092c5b>:0 
[info]: OmniSharp.Middleware.LoggingMiddleware
        /v2/debugtest/getstartinfo: 500 7686ms

[DustinCampbell]

OK. Yeah, I expected that you're both seeing this on the second click. The problem is figuring out what happened between the first and second click that caused the debugger not to spin up.

[StephenRedd]

@DustinCampbell I can't help but notice that you've been buzy, and there's a LOT of new code in both this and the roslyn projects... I have to wonder if you fixed it by accident with some of that new stuff? Anyway, you drop a new vsix for 1.10.0 and I'll be happy to test it out :) In the meantime, I'll run a few more tests and let you know how it goes.

[DustinCampbell]

I don't think I fixed it by accident, but I'd be happy if that were the case. :smile:

[StephenRedd]

• Same machine as the last log
  
  
  
  • All extensions disabled, except C#
  
  
  • Freshly rebooted system
  
  
• Opened repo root folder in VS Code
• Waited until omnisharp log calmed down (about 10-15 seconds)

    ...
    [info]: OmniSharp.Startup
                Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.CSharpWorkspaceOptionsProvider
    [info]: OmniSharp.Startup
            Configuration finished.

• Waited 1 minute more, just in case
  
  
  
  • no new output in log
  
  
• Got prompted by GUI to restore packages for one of the src projects
  
  
  
  • Closed prompt without letting it restore packages
  
  
• Opened terminal in VS code:
  
  
  
  • ran dotnet restore
  
  
  • ran dotnet build
  
  
• Couple new lines in log output (from the restore/build):

    [info]: OmniSharp.MSBuild.MSBuildProjectSystem
            Update project: NullDesk.Extensions.Mailer.Core
    [info]: OmniSharp.MSBuild.MSBuildProjectSystem
            Update project: NullDesk.Extensions.Mailer.SendGrid

• Waited 10 minutes (browsed the news, cause I wasn't sufficiently depressed)
  
  
  
  • No new lines in omnisharp log
  
  
• Clicked debug test:

    [info]: OmniSharp.DotNetTest.VSTestManager
                read: {"MessageType":"TestSession.Connected","Payload":null}
    [info]: OmniSharp.DotNetTest.VSTestManager
            read: {"MessageType":"ProtocolVersion","Payload":1}
    [info]: OmniSharp.DotNetTest.DebugSessionManager
            Debug session started.

• Waited 10 more minutes (browsed facebook, cause I'm a slow learner)
  
  
  
  • No new lines in omnisharp log
  
  
• Copied log to txt file
• Closed VS Code
• Wrote this update

machine-a-nullmailer-omnisharp-debug-log.txt

[DustinCampbell]

Hmmm... the only different I see between what you did and what I did is that I clicked "Restore" on the dotnet restore prompt and let restore run. I'd be surprised if that made a difference though.

[StephenRedd]

I'm sure the restore and build commands didn't matter... that's not a normal thing I've done in other tests either.

This log looks pretty much the same as they all have and the command line stuff I did this time was just incidental. The common trend, on this system at least, seems to be that nothing suspicious gets caught in the log. I'll run through it on a fresh system and see if I can get something interesting in the logs. Still waiting on a colleague of mine to drop me his logs too.

[eamodio]

I'm experiencing the same issue with my xunit tests, since the conversion from project.json to csproj. When I try to debug a unit test from the code lens, I get Debug adapter process has terminated unexpectedly. Before the csproj conversion test debugging worked perfectly (and the tests haven't changed, though the version of the dependencies did). Also normal debugging works fine.

Here is the debugger output:
vsdbg-ui.log.txt

Here is the omnisharp output:
omnisharp.txt

Here is the project file for the test project:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netcoreapp1.1</TargetFramework>
    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
    <DebugType>portable</DebugType>
    <AssemblyName>Common.Tests</AssemblyName>
    <PackageId>Common.Tests</PackageId>
    <GenerateRuntimeConfigurationFiles>true</GenerateRuntimeConfigurationFiles>
    <PackageTargetFallback>$(PackageTargetFallback);dotnet5.4;portable-net451+win8</PackageTargetFallback>
    <RuntimeFrameworkVersion>1.1.1</RuntimeFrameworkVersion>
    <GenerateAssemblyConfigurationAttribute>false</GenerateAssemblyConfigurationAttribute>
    <GenerateAssemblyCompanyAttribute>false</GenerateAssemblyCompanyAttribute>
    <GenerateAssemblyProductAttribute>false</GenerateAssemblyProductAttribute>
  </PropertyGroup>

  <ItemGroup>
    <ProjectReference Include="../Common/Common.csproj" />
    <ProjectReference Include="../Common.Testing/Common.Testing.csproj" />
  </ItemGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.3.0-preview-20170427-09" />
    <PackageReference Include="xunit.runner.visualstudio" Version="2.3.0-beta1-build1309" />
    <PackageReference Include="Newtonsoft.Json" Version="10.0.2" />
    <PackageReference Include="System.Runtime.Serialization.Primitives" Version="4.3.0" />
    <PackageReference Include="xunit" Version="2.3.0-beta1-build3642" />
  </ItemGroup>

</Project>

[DustinCampbell]

Hi all -- I've just pushed a new beta release of C# for VS Code. I hope this will show a bit more of what's going on, or at least narrow the potential causes down a bit.

The new release is 1.10.0-beta1. To install, use the steps from Installing Beta Releases.

[eamodio]

I've just tried with 1.10.0-beta1, I'm again getting the hanging behavior (its been running going on ~5 mins now).

The only new thing I see in the log is:

{"Type":"System.IO.Directory","Documentation":"Exposes static methods for creating, moving, and enumerating through directories and subdirectories. This class cannot be inherited.To browse the .NET Framework source code for this type, see the Reference Source."}

It appeared after about 30s from when the debugger started.

[DustinCampbell]

That's log entry is from hovering over the Dictionary type in your code. :smile:

What do you see in the .NET Test Log?

[eamodio]

So the hang only seems to happen when the first time all the stuff is downloaded, after a restart I'm back to the error: Debug adapter process has terminated unexpectedly

This is all that is in the .NET Test Log

Debugging method 'Common.Tests.StreamExtensionsTest.IsAnimatedTest'.
Started debugging process #33311.

[DustinCampbell]

And running the test works, right?

[DustinCampbell]

@gregg-miskelly: Do you have any ideas on how to get more information? It seems like the debugger starts and then dies.

[eamodio]

Checking now -- but I've seen this a couple of times now when changing the selector in the statusbar:

[dbug]: OmniSharp.MSBuild.ProjectFile.ProjectFileInfo
        Using TargetFrameworkRootPath: /Library/Frameworks/Mono.framework/Versions/4.8.0/lib/mono/xbuild-frameworks
[ERROR] Error: OmniSharp server load timed out. Use the 'omnisharp.projectLoadTimeout' setting to override the default delay (one minute).

Might be completely unrelated, but wanted to mention it

[eamodio]

Running the test works (well they run, and fail -- but that is because the cwd seems to be different than under project.json, which is why I was trying to debug in the first place)

[DustinCampbell]

I suspect it's unrelated, but it's worth setting "omnisharp.projectLoadTimeout" to a larger number (like 500).

[DustinCampbell]

When we launch dotnet test to run tests, the CWD is set to the project folder. It's possible that the VS Test runner might change that.

[eamodio]

Yeah, under project.json it was the project folder, but now it seems to be the folder where the binary is.

[StephenRedd]

Ok, with 1.10.0-beta1 the problem seems to be resolved in all three repositories. I've gotten them to work on two of the machines I've been testing with.

Probably not an issue, but one of the repositories still behaved the same (hung when starting the debugger) after the update. I removed the obj and bin folders from the test project, restored and rebuilt, then it started working... basically, I had to jiggle the handle a bit on that one repository

I'll play with it some more, checking various tests and a few more projects and let you know if I see anything worth mentioning, but I think this is fixed for us.

[DustinCampbell]

That's great to hear @StephenRedd.

[fedoranimus]

I'm seeing the same issues with 1.10.0-beta1 as before, sadly.

The logs are all identical to what they were before as well.

I tried using the "Run Test" codelens link and am getting double output messages for everything (I saw this in 1.9.0) as well. It's probably unrelated but found it worth mentioning.

Running test Tests.UserControllerIntegrationTests.TestFoo...
Microsoft (R) Build Engine version 15.1.548.43366
Microsoft (R) Build Engine version 15.1.548.43366
Copyright (C) Microsoft Corporation. All rights reserved.
Copyright (C) Microsoft Corporation. All rights reserved.


  Covalence.API -> /Users/timdturner/Github/covalence-server/src/Covalence.API/bin/Debug/netcoreapp1.1/Covalence.API.dll
  Covalence.API -> /Users/timdturner/Github/covalence-server/src/Covalence.API/bin/Debug/netcoreapp1.1/Covalence.API.dll
  test -> /Users/timdturner/Github/covalence-server/test/bin/Debug/netcoreapp1.1/test.dll
  test -> /Users/timdturner/Github/covalence-server/test/bin/Debug/netcoreapp1.1/test.dll


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


Time Elapsed 00:00:05.56
Time Elapsed 00:00:05.56




[xUnit.net 00:00:00.7650034]   Discovering: test
[xUnit.net 00:00:00.7650034]   Discovering: test
[xUnit.net 00:00:00.9091213]   Discovered:  test
[xUnit.net 00:00:00.9091213]   Discovered:  test
[xUnit.net 00:00:00.6951499]   Starting:    test
[xUnit.net 00:00:00.6951499]   Starting:    test
[xUnit.net 00:00:02.9135558]     Tests.UserControllerIntegrationTests.TestFoo [FAIL]
[xUnit.net 00:00:02.9135558]     Tests.UserControllerIntegrationTests.TestFoo [FAIL]
[xUnit.net 00:00:02.9148547]       TestFoo was run.
[xUnit.net 00:00:02.9148547]       TestFoo was run.
[xUnit.net 00:00:02.9149489]       Expected: True
[xUnit.net 00:00:02.9149489]       Expected: True
[xUnit.net 00:00:02.9149992]       Actual:   False
[xUnit.net 00:00:02.9149992]       Actual:   False
[xUnit.net 00:00:02.9160162]       Stack Trace:
[xUnit.net 00:00:02.9160162]       Stack Trace:
[xUnit.net 00:00:02.9169637]         /Users/timdturner/Github/covalence-server/test/UserControllerIntegrationTest.cs(81,0): at Tests.UserControllerIntegrationTests.TestFoo()
[xUnit.net 00:00:02.9169637]         /Users/timdturner/Github/covalence-server/test/UserControllerIntegrationTest.cs(81,0): at Tests.UserControllerIntegrationTests.TestFoo()
[xUnit.net 00:00:02.9327345]   Finished:    test
[xUnit.net 00:00:02.9327345]   Finished:    test

Total tests: 1. Passed: 0. Failed: 1. Skipped: 0

[DustinCampbell]

The double messages is actually super-weird. It might not be related, but it's at least some sort of lead on strangeness happening with your installation.

• Check ~/.vscode/extensions and let me know extensions you have installed there.
• Also, try Toggle Developer Tools from the VS Code menu before loading your project. There might be some helpful information on the Console tab.

[fedoranimus]

I'll take a look after work, thanks.

[fedoranimus]

Extensions:

• Aurelia
• Auto Rename Tag
• C#
• Docker
• Document This
• Git History
• GitLens
• HTML Snippets
• markdownlint
• mssql
• npm
• NuGet Package Manager
• Paste and Indent
• Prettify JSON
• REST Client
• Sass
• TSLint
• vscode-icons
• yo

Dev Tools:

extensionHost.ts:284 [Extension Host] vscode-icons is active!
extensionHost.ts:284 [Extension Host] TextEditor is closed/disposed
extensionHost.ts:284 [Extension Host] TextEditor disposed

[DustinCampbell]

I was hoping for a directory listing. There aren't two ms-vscode.csharp folders are there? I've seen this happen occasionally, which can cause problems.

Also, when you saw doubled-up messages in the .NET Test Log, was that in a fresh start of VS Code? Or, had you already clicked the debug link and seen it fail?

[fedoranimus]

Ah, sorry. Here is the directory:

I just did a "Run Test" immediately after opening and the output messages are as I'd expect:

[xUnit.net 00:00:00.8442879]   Discovering: test
[xUnit.net 00:00:01.0163859]   Discovered:  test
[xUnit.net 00:00:00.7637890]   Starting:    test
[xUnit.net 00:00:03.1290619]     Tests.UserControllerIntegrationTests.TestFoo [FAIL]
[xUnit.net 00:00:03.1305443]       TestFoo was run.
[xUnit.net 00:00:03.1306523]       Expected: True
[xUnit.net 00:00:03.1307273]       Actual:   False
[xUnit.net 00:00:03.1318200]       Stack Trace:
[xUnit.net 00:00:03.1327623]         /Users/timdturner/Github/covalence-server/test/UserControllerIntegrationTest.cs(81,0): at Tests.UserControllerIntegrationTests.TestFoo()
[xUnit.net 00:00:03.1489360]   Finished:    test

Total tests: 1. Passed: 0. Failed: 1. Skipped: 0

After this, if I do another "Run Test", everything is fine. Once I try to do a "Debug Test" (which fails) and then I do a "Run Test", the messages get spit out twice.

[DustinCampbell]

Thanks for the detail. That aligns with my theory about why you were seeing double messages. Essentially, this code isn't disposing correctly when it fails: https://github.com/OmniSharp/omnisharp-vscode/blob/master/src/features/dotnetTest.ts#L299-L306.

[DustinCampbell]

@fedoranimus: Looking through the thread, I can't recall if we've done this yet. Could you try cranking up the logging level for OmniSharp? I'm hoping we'll be able to spot some sort of clue. Here's how you can set the logging level:

1. Open VS Code
2. Select Preferences->User Settings
3. In the settings.json file, add"omnisharp.loggingLevel": "debug".
4. Restart VS Code and open your project
5. Click the "debug test" adornment and get the error message

Now, grab the OmniSharp Log.

[fedoranimus]

Here you go: https://pastebin.com/DvNqF8FU

[DustinCampbell]

Thanks @fedoranimus! From your log, it looks like things are working as expected up until we tell the test process that the debugger has launched it and it's time to actually run the test.

[dbug]: OmniSharp.DotNetTest.VSTestManager
        read: {"MessageType":"TestExecution.CustomTestHostLaunch","Payload":{"FileName":"/usr/local/share/dotnet/dotnet","Arguments":"exec --runtimeconfig \"/Users/timdturner/Github/covalence-server/test/bin/Debug/netcoreapp1.1/test.runtimeconfig.json\" --depsfile \"/Users/timdturner/Github/covalence-server/test/bin/Debug/netcoreapp1.1/test.deps.json\" \"/Users/timdturner/.nuget/packages/microsoft.testplatform.testhost/15.0.0/lib/netstandard1.5/testhost.dll\" --port 62849 --parentprocessid 56040","WorkingDirectory":"/Users/timdturner/Github/covalence-server/test/bin/Debug/netcoreapp1.1","EnvironmentVariables":{},"CustomProperties":null}}
[dbug]: OmniSharp.Middleware.LoggingMiddleware
        ************  Response ************
{"FileName":"/usr/local/share/dotnet/dotnet","Arguments":"exec --runtimeconfig \"/Users/timdturner/Github/covalence-server/test/bin/Debug/netcoreapp1.1/test.runtimeconfig.json\" --depsfile \"/Users/timdturner/Github/covalence-server/test/bin/Debug/netcoreapp1.1/test.deps.json\" \"/Users/timdturner/.nuget/packages/microsoft.testplatform.testhost/15.0.0/lib/netstandard1.5/testhost.dll\" --port 62849 --parentprocessid 56040","WorkingDirectory":"/Users/timdturner/Github/covalence-server/test/bin/Debug/netcoreapp1.1","EnvironmentVariables":{}}
[dbug]: OmniSharp.Middleware.LoggingMiddleware
        ************ Request ************
POST - /v2/debugtest/launch
************ Headers ************
Content-Type - application/json
************  Body ************
{
  "FileName": "/Users/timdturner/Github/covalence-server/test/UserControllerIntegrationTest.cs",
  "TargetProcessId": 56044
}
[dbug]: OmniSharp.DotNetTest.VSTestManager
        send: {"MessageType":"TestExecution.CustomTestHostLaunchCallback","Payload":{"HostProcessId":55995}}

This is identical to the behavior I saw in a log that @eamodio sent me. That's at least _some_ evidence that you two are experiencing the same issue.

[DustinCampbell]

@fedoranimus: We were able to find a crash log for vsdbg-ui containing detailed information on @eamodio's machine using the OSX Console application (located in /Applications/Utilities). Are you able to locate a crash log as well?

[fedoranimus]

I did a search for 'vsdbg-ui' in Console and it was unable to find anything.

[gregg-miskelly]

@eamodio I opened https://github.com/OmniSharp/omnisharp-vscode/issues/1456 to track the issue you are seeing.

[eamodio]

@gregg-miskelly Excellent thank you!

[fedoranimus]

Has there been any progress on this front? This is becoming more and more of a blocking issue, sadly. :(

Is there any more information I can provide?

[DustinCampbell]

@fedoranimus: After screen sharing with @eamodio, we discovered the root cause his issue, which had a similar end result as the one you reported. However, from other information you've provided, it doesn't seem like it's the same thing. Unfortunately, none of our questions have yielded any actionable information.

I'm curious to know if this problem is only occurring with your project or if you see it with a brand new xUnit project. Could you try the following?

1. At a terminal window:
   
   
   
   • mkdir test-xunit
   
   
   • cd test-xunit
   
   
   • dotnet new xunit
   
   
   • dotnet restore
   
   
2. In VS Code:
   
   
   
   • Open the test-xunit folder you just created
   
   
   • Open the UnitTest1.cs file that was generated.
   
   
   • Add a breakpoint on the open curly brace of Test1()
   
   
   • Click debug test
   
   

Does the breakpoint hit?

[fedoranimus]

I am able to successfully debug and hit my breakpoint with this brand new project.

[DustinCampbell]

That's what I hoped. So, it sounds like it has something to do with your project in particular. Without more information about that project, it's very difficult to determine exactly what's causing the issue. Do you have any other projects that exhibit the same problem that you could share?

[fedoranimus]

I do not.

I'm now able to share the project I'm seeing the issue on, however.

Steps to reproduce:

1. Open repo in VSCode
2. Navigate to /test and open AccountControllerIntegrationTests.cs
3. Put breakpoint in CreateAccount()
4. Click debug test
5. Repeat debug test

[DustinCampbell]

Unfortunately, the project you provided doesn't build. It has the following error:

TagTests.cs(20,63): error CS0311: The type 'Covalence.Authentication.ApplicationDbContext' cannot be used as type parameter 'TContext' in the generic type or method 'DbContextOptions<TContext>'. There is no implicit reference conversion from 'Covalence.Authentication.ApplicationDbContext' to 'Microsoft.EntityFrameworkCore.DbContext'. [C:\Projects\covalence-api\test\test.csproj]
TagTests.cs(20,63): error CS0012: The type 'IdentityDbContext<>' is defined in an assembly that is not referenced. You must add a reference to assembly 'Microsoft.AspNetCore.Identity.EntityFrameworkCore, Version=1.1.1.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. [C:\Projects\covalence-api\test\test.csproj]

That said, it doesn't look like this project is set up to work 'dotnet test' as the Microsoft.NET.Test.Sdk package isn't referenced. It looks like you're using it with 'dotnet xunit' instead, which is not something we support.

[fedoranimus]

That's very odd - builds on my system and I have no pending changes. I'll have to dig into that. (I assume you did a dotnet restore)

Oh, I see. I'm able to call dotnet test, but it must just be passing it through to xunit?

[DustinCampbell]

Trying a little harder got it building. :smile:

[DustinCampbell]

OK. I can repro.

[DustinCampbell]

FWIW, the problem with building may be related to me having a different .NET Core SDK installed.

[DustinCampbell]

OK. So, here's what I'm seeing. Please let me know if this is similar to what you see:

1. I open the folder in VS Code and once OmniSharp finishes loading, there's a message that pops up to restore the project.

2. If I click "restore", it runs a dotnet restore but there's an error message in the restore output:

   Errors in c:\Projects\covalence-api\test\test.csproj
       Unable to resolve 'c:\Projects\covalence-api\src\Covalence.API\Covalence.API.csproj' for '.NETCoreApp,Version=v1.1'.
   

3. At this point, I click "debug test" and I get the error you described.

Next I tried the following:

1. Run dotnet restore at the command line, which finishes without errors. (curious)
2. Open the folder in VS Code again and allow OmniSharp to finish loading.
3. When the restore popup appears, don't click anything. Instead, you can press Esc to dismiss it.
4. Without clicking "restore" on that prompt, click "debug test"
5. The debugger fires up and the breakpoint hits.

IOW, what I'm seeing is that the dotnet restore inside VS Code seems to be breaking the project, though I'm not 100% sure why. Honestly, I'm not sure why the prompt is happening at all. That feels like a bug.

Do you see similar behavior?

[fedoranimus]

Similar, but not identical.

Whenever I open the project, it asks me to restore (not sure why, it's super annoying). If I don't restore, I still won't hit breakpoints, but it _will_ try to load the debugger at least.

[DustinCampbell]

I see why the restore prompt is happening. It's because OmniSharp has a case-sensitive match between the package reference and the package dependency. In test.csproj, try changing "Microsoft.testplatform.testhost" to "Microsoft.TestPlatform.TestHost".

[DustinCampbell]

Here it is working on my Windows box as proof that it can work. :smile:

I'll try my Mac tomorrow.

[fedoranimus]

I'm still getting the same "Debug adapter process has terminated unexpectedly" message, but at least it doesn't try to restore each load! So thanks for that.

[DustinCampbell]

Here's the fix for that package restore issue: https://github.com/OmniSharp/omnisharp-roslyn/pull/861.

[gregg-miskelly]

@fedoranimus the "Debug adapter process has terminated unexpectedly" is going to be something different. Can you try installing the 1.10-beta2 release (instructions), setting the "csharp.unitTestDebugingOptions" option (in Preferences->Options) to have debugger logging enabled, and then tell me the last bit of what you see in the debug console?

[gregg-miskelly]

@fedoranimus actually, before you do that, is there anything in crashreporter for vsdbg-ui?

[fedoranimus]

I am seeing crash reports for vsdbg-ui now.

Process:               vsdbg-ui [50855]
Path:                  /Users/USER/*/vsdbg-ui
Identifier:            vsdbg-ui
30  vsdbg-ui                        0x000000010ec5fb21 run(int, char const**) + 2081
31  vsdbg-ui                        0x000000010ec5fc5e main + 158
       0x10ec54000 -        0x10ec70fff +vsdbg-ui (0) <FE919E55-60F5-32B6-93FC-31DDA0A316B0> /Users/USER/*/vsdbg-ui

Edit: Have not yet updated to 1.10-beta2

[fedoranimus]

Updated to 1.10-beta2. I'm still seeing the same issues.

Here is my vsdbg-ui.log

[gregg-miskelly]

@fedoranimus can you send me a bit more of the crash report?

[DustinCampbell]

@gregg-miskelly: I can repro this issue on my Mac. I did the following:

1. Downloaded and installed the latest .NET Core 2.0 SDK from https://dotnetcli.blob.core.windows.net/dotnet/Sdk/release/2.0.0/dotnet-dev-osx-x64.latest.pkg.
2. Cloned the project that @fedoranimus provided from https://github.com/fedoranimus/covalence-api
3. Ran dotnet restore in the covalence-api folder that I just cloned.
4. Typed code . to open the covalence-api folder in VS Code.
5. Opened test/AccountControllerIntegrationTests.cs in VS Code and waited for OmniSharp to finish loading (and the CodeLens adornments to appear).
6. Set a breakpoint in CreateAccount and clicked debug test

Shortly after the debugger starts up, I got the "Debug adapter process has terminated unexpectedly" message.

[DustinCampbell]

Here's the crash log. It looks similar to the heap corruption bug you already looked at.

vsdbg-ui_2017-05-17-100155_Dustins-MacBook-Pro.crash.zip

[gregg-miskelly]

Sorry if this is obvious, but I wrote up some instructions: https://github.com/OmniSharp/omnisharp-vscode/wiki/Diagnosting-%22Debug-adapter-process-has-terminated-unexpectedly%22

[EDIT]: please disregard since Dustin provided the crash report, and anyway the repro project reproduced the crash for Dustin anyway.

[gregg-miskelly]

@DustinCampbell Thanks! Sorry, I thought you couldn't repro the crash Dustin.

[DustinCampbell]

@DustinCampbell Thanks! Sorry, I thought you couldn't repro the crash Dustin.

It works great on Windows, but I hadn't tried it on my Mac yet.

[gregg-miskelly]

Yup, this is a dupe of https://github.com/OmniSharp/omnisharp-vscode/issues/1456. Looks like whatever has embedded symbols isn't in your project. I can build privates so you can work around. But unfortunately our lab infrastructure is all down right now. So I am not sure how long that will take.

[fedoranimus]

Okay, thank you. Sorry, I was away from my system all day.

[DustinCampbell]

It's OK. Thank you for providing that simple project to help us repro. Hopefully we'll be able to get you some private bits to try.

[DustinCampbell]

@fedoranimus: I'm curious to know if the latest update (1.10) fixed the issue for you.

[fedoranimus]

Yes, it does, thank you!

[DustinCampbell]

Excellent! Thanks for confirming. It took a bit to get to the bottom of it, but I think this issue is now fixed.