Debugger Fails to start when attempting to debug test

fedoranimus commented 7 years ago

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

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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

fedoranimus commented 7 years ago

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

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

StephenRedd commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

Could you provide your OmniSharp Log?

fedoranimus commented 7 years ago

Where is that located?

DustinCampbell commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

Any chance you could share your project?

fedoranimus commented 7 years ago

I cannot, sadly.

StephenRedd commented 7 years ago

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 commented 7 years ago

@StephenRedd:

StephenRedd commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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

StephenRedd commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

And running the test works, right?

DustinCampbell commented 7 years ago

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

eamodio commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

DustinCampbell commented 7 years ago

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 commented 7 years ago

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

StephenRedd commented 7 years ago

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 commented 7 years ago

That's great to hear @StephenRedd.

fedoranimus commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

I'll take a look after work, thanks.

fedoranimus commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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.

dotnet / vscode-csharp