vscode-csharp: XUnit projects cannot be launched under the debugger
The symptoms are related to those described in #1253, but wasn’t solved with the thing the closed that one. Environment info is the same.
λ dotnet --info
.NET Command Line Tools (1.0.0-rc4-004771)
Product Information:
Version: 1.0.0-rc4-004771
Commit SHA-1 hash: d881d45b75
Runtime Environment:
OS Name: Windows
OS Version: 10.0.14393
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\1.0.0-rc4-004771
Do you always see the program has exited with code 0 or is it intermittent? If you always get it –
- What is program set to in launch.json?
- Can you send me the output you get in your console window?
Yes, the issue is 100% repeatable. In this case, the problem is with an Xunit project, called Saddleback.AspNetCore.Features.Test
. The project file as as follows:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFrameworks>netcoreapp1.0;netcoreapp1.1</TargetFrameworks>
<NetStandardImplicitPackageVersion>1.6.1</NetStandardImplicitPackageVersion>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.0.0" />
<PackageReference Include="xunit" Version="2.2.0" />
<PackageReference Include="xunit.runner.visualstudio" Version="2.2.0" />
<PackageReference Include="Microsoft.AspNetCore.TestHost" Version="1.1.0"/>
</ItemGroup>
<ItemGroup>
<ProjectReference Include="../../src/Saddleback.AspNetCore.Features/Saddleback.AspNetCore.Features.csproj"/>
<ProjectReference Include="../Saddleback.Logging.Xunit/Saddleback.Logging.Xunit.csproj"/>
</ItemGroup>
</Project>
The launch.json:
{
"version": "0.2.0",
"configurations": [
{
"name": ".NET Core Launch (console)",
"type": "coreclr",
"request": "launch",
"preLaunchTask": "build",
"program": "${workspaceRoot}\\test\\Saddleback.AspNetCore.Features.Test\\bin\\Debug\\netcoreapp1.0\\Saddleback.AspNetCore.Features.Test.dll",
"args": [],
"cwd": "${workspaceRoot}",
"externalConsole": false,
"stopAtEntry": false,
"internalConsoleOptions": "openOnSessionStart"
},
{
"name": ".NET Core Attach",
"type": "coreclr",
"request": "attach",
"processId": "${command:pickProcess}"
}
]
}
the console output:
Microsoft (R) Build Engine version 15.1.545.13942
Copyright (C) Microsoft Corporation. All rights reserved.
Saddleback.AspNetCore.Features -> d:\Users\ben\proj\sb\SaddlebackFeatures\src\Saddleback.AspNetCore.Features\bin\Debug\netstandard1.4\Saddleback.AspNetCore.Features.dll
Saddleback.Logging.Xunit -> d:\Users\ben\proj\sb\SaddlebackFeatures\test\Saddleback.Logging.Xunit\bin\Debug\netstandard1.4\Saddleback.Logging.Xunit.dll
Saddleback.AspNetCore.Features.Test -> d:\Users\ben\proj\sb\SaddlebackFeatures\test\Saddleback.AspNetCore.Features.Test\bin\Debug\netcoreapp1.0\Saddleback.AspNetCore.Features.Test.dll
Saddleback.AspNetCore.Features.Test -> d:\Users\ben\proj\sb\SaddlebackFeatures\test\Saddleback.AspNetCore.Features.Test\bin\Debug\netcoreapp1.1\Saddleback.AspNetCore.Features.Test.dll
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:07.60
and the debug console output:
--------------------------------------------------------------------------------
You may only use the Microsoft .NET Core Debugger (clrdbg) with Visual Studio
Code, Visual Studio or Visual Studio for Mac software to help you develop and
test your applications.
--------------------------------------------------------------------------------
Loaded 'C:\Program Files\dotnet\shared\Microsoft.NETCore.App\1.0.3\System.Private.CoreLib.ni.dll'. Cannot find or open the symbol file.
Loaded 'd:\Users\ben\proj\sb\SaddlebackFeatures\test\Saddleback.AspNetCore.Features.Test\bin\Debug\netcoreapp1.0\Saddleback.AspNetCore.Features.Test.dll'. Symbols loaded.
Loaded 'C:\Program Files\dotnet\shared\Microsoft.NETCore.App\1.0.3\System.Runtime.dll'. Cannot find or open the symbol file.
Loaded 'C:\Program Files\dotnet\shared\Microsoft.NETCore.App\1.0.3\mscorlib.dll'. Cannot find or open the symbol file.
The program 'd:\Users\ben\proj\sb\SaddlebackFeatures\test\Saddleback.AspNetCore.Features.Test\bin\Debug\netcoreapp1.0\Saddleback.AspNetCore.Features.Test.dll' has exited with code 0 (0x00000000).
About this issue
- Original URL
- State: open
- Created 7 years ago
- Reactions: 6
- Comments: 24 (14 by maintainers)
FWIW, the issue I’m seeing looks like it might be a bug introduced in xUnit. If I use the version of xUnit that
dotnet new xunit
generates (2.2.0), run and debug tests works fine. If I moved to the latest xUnit preview that you’re using (2.3.0-beta4-build3742), it fails withAn exception occurred while test discoverer 'VsTestRunner' was loading tests. Exception: Object reference not set to an instance of an object.
The fact that you can F5 an xUnit project is really a bit strange. To be honest, C# for VS Code really shouldn’t offer to create a launch.json file for them, but xUnit projects are created as “netcoreapp2.0” with no entry point.
The trick to debugging unit tests is to open a file containing unit tests and then click the “debug test” annotation above the method:
Yup, that’s the issue. If I change OmniSharp to pass a run settings file containing
<TargetFrameworkVersion>.NETCoreApp, Version=2.0</TargetFrameworkVersion>
it works fine. I don’t think xUnit is at fault here, but we need to do a bit more work to make it work right. I’ve filed https://github.com/OmniSharp/omnisharp-roslyn/issues/944 to track this work.Any idea when the fix will go live. Unless I’ve misunderstood it’s currently impossible to debug either xunit or mstest test which is a major showstopper.
The latest beta 4 definitely should be much better. IIRC, it fixes issues with running tests in VS. I’m debugging this now to see if I can figure out where the issue might be.
@aggieben: The “Run Test” and “Debug Test” CodeLens links don’t work yet for .csproj-based .NET Core projects. This is tracked by https://github.com/OmniSharp/omnisharp-vscode/issues/1100.
@aggieben I think the issue here is that XUnit projects aren’t runnable in this way – it either doesn’t run your tests at all, or it runs them in a child process. You can confirm or Deny this theory by adding a Console.WriteLine to one of your tests to see if it runs. If it does run have it print its process id and then pause (ex:
Thread.Sleep(10000);
). You can then useps -A
to find out if it is the process that the debugger launched.