Implement VSTest support to enable running and debugging .NET Core tests in .csproj projects

[aochsner]

I realize I'm on pretty bleeding edge (.NET Core 1.1.0, .NET CLI 1.0.0 preview 4 (csproj), etc) but wanted to raise this and see if I can help w/ anything.

Environment data

.NET Core version

Microsoft .NET Core Shared Framework Host

  Version  : 1.1.0
  Build    : 928f77c4bc3f49d892459992fb6e1d5542cb5e86

dotnet --info output:

.NET Command Line Tools (1.0.0-preview4-004233)

Product Information:
 Version:            1.0.0-preview4-004233
 Commit SHA-1 hash:  8cec61c6f7

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

VS Code version:
Version 1.8.1 (1.8.1)

C# Extension version:
1.6.2

Steps to reproduce

Create new xunit project
dotnet new -t xunittest

Update references to 1.1.0 in csproj:

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

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp1.1</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <Compile Include="**\*.cs" />
    <EmbeddedResource Include="**\*.resx" />
  </ItemGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.NETCore.App" Version="1.1.0" />
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.0.0-preview-20161123-03" />
    <PackageReference Include="xunit" Version="2.2.0-beta4-build3444" />
    <PackageReference Include="xunit.runner.visualstudio" Version="2.2.0-beta4-build1194" />
  </ItemGroup>

</Project>

Open in VS Code and navigate to Test.cs.
Run Test via Omnisharp

Expected behavior

Test runs

Actual behavior

"Failed to run test because null" error

[vcsjones]

This is the only thing holding me back from adopting the preview4 tooling. While "run test" is a less severe of a problem (I can just do that from the command line...) "debug test" has the same problem, and I don't have a good work around for that.

[VladimirMakaev]

+1

[DustinCampbell]

Upon fixing the null reference (which was due to some ugly code that looked specifically for the presence of project.json), it looks like this might be quite seriously broken. Previously, OmniSharp just called dotnet test with --port and --parentProcessId flags to start communicating with the test framework. However, now that the .NET CLI has moved over to MSBuild (and VSTest), it's not clear whether this is possible any longer.

@piotrpMSFT, do you have any thoughts here? I'm guessing OmniSharp will need to commnicate a bit differently with VSTest using the details from https://github.com/microsoft/vstest. Do we just need to use dotnet vstest?

[DustinCampbell]

OK. I'm making some progress with dotnet vstest using the spec at https://github.com/Microsoft/vstest-docs/blob/master/RFCs/0007-Editors-API-Specification.md. 😄

[jchannon]

Keep in mind xUnit are looking to make their own command eg/dotnet xunit so not sure if that would change how tests are run/debugged in vscode @bradwilson

[DustinCampbell]

I don't think it would. I think we'd still want to go through the VSTest protocol. Otherwise, we'd be writing custom code for every test framework that's supported.

[jchannon]

Exactly, just wanted to make sure that wasn't the case :)

…

On 3 February 2017 at 09:54, Dustin Campbell ***@***.***> wrote: I don't think it would. I think we'd still want to go through the VSTest protocol. Otherwise, we'd be writing custom code for every test framework that's supported. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1100 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGaphHL9WYhCEcgdr0uyBdZbzgiZtLFks5rYvlPgaJpZM4LYSEd> .

[bradwilson]

I think we'd still want to go through the VSTest protocol.

I agree, you should. dotnet xunit is about providing an equivalent to xunit.console.exe for .NET SDK applications. It is not intended to be automated by third parties.