Omnisharp-vscode: 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. :smile:

[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 [e-mail]
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
https://github.com/OmniSharp/omnisharp-vscode/issues/1100#issuecomment-277207593,
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.

[ErikSchierboom]

Will there be a .NET: Test command added to VS Code, similar to the .NET: Restore Packages command? That would be incredibly useful I feel.

[DustinCampbell]

Eventually. This just tracks getting the CodeLens indicators for "run test" and "debug test" working for .csproj.

[ErikSchierboom]

Ah, I missed that. That would also be brilliant!

[Jonathan34]

ah well, another road blocker with xunit and vscode :(
hope the 1.8.0 is coming very soon to fully support csproj and xunit

[Jonathan34]

as a workaround: you can edit your tasks.json to add the test tasks you want, bind a shortcut like this:

[{
    "key": "shift+cmd+t",
    "command": "workbench.action.tasks.runTask",
    "when": "editorTextFocus"
}]

and select the test task.
if you want to run all the tests, you can create dependencies using the tasks.json v2.0.0 (cf https://code.visualstudio.com/updates/v1_10#_more-work-on-terminal-runner)

alternatively, switch to vs 2017 :)

[DustinCampbell]

Great suggestion!

[eli-ba]

@Jonathan34 Could you please clarify more the procedure that you suggested ? Could you start a debugging session for a specific test method using VSCode's tasks.json/launch.json ?

[gregg-miskelly]

I don't believe it would be possible to do that for debugging - from my understanding all the unit test stuff does the real work in child processes, which makes it incompatible with being launched under a debugger in a normal way.

[eli-ba]

Which means we have to wait for the 1.9 milestone to be released before we can debug tests in csproj build system on Linux and macOS ?

[gregg-miskelly]

Yes, unfortunately for now the only way to debug unit tests is to put it a while (!Debugger.IsAttached) Sleep loop at the start of the test and attach. There is significant work to be done in OmniSharp-Roslyn to make this scenario work the right way and no one has done it yet.

[Jonathan34]

@anass-b this is my tasks.json:

{
    "version": "2.0.0",
    "command": " ",
    "isShellCommand": true,
    "args": [],
    "tasks": [{
            "taskName": "build",
            "command": "dotnet",
            "args": [
                "build"
            ],
            //"isShellCommand": true,
            "options": {
                "cwd": "${workspaceRoot}"
            },
            "isBuildCommand": true,
            "showOutput": "always",
            "problemMatcher": "$msCompile"
        },
        {
            "taskName": "Integration Tests",
            "command": "dotnet",
            "args": [
                "test",
                "IntegrationTests.csproj"
            ],
            "options": {
                "cwd": "${workspaceRoot}/Services/test/IntegrationTests"
            },
            "isTestCommand": true,
            "showOutput": "always",
            "problemMatcher": "$msCompile"
        },
        {
            "taskName": "Unit Tests",
            "command": "dotnet",
            "args": [
                "test",
                "UnitTests.csproj"
            ],
            "options": {
                "cwd": "${workspaceRoot}/Services/test/UnitTests"
            },
            "isTestCommand": true,
            "showOutput": "always",
            "problemMatcher": "$msCompile"
        },
        {
            "taskName": "TestAll",
            "dependsOn": [
                "Unit Tests",
                "Integration Tests"
            ]
        }
    ]
}

then you edit your shortcut to runTask

[{
    "key": "shift+cmd+t",
    "command": "workbench.action.tasks.runTask",
    "when": "editorTextFocus"
}]

and when you use the shortcut:

the codeLens still does not work, use @gregg-miskelly tricks above to debug or use the old way Console.Write()

[eli-ba]

Thanks for all the suggestions.

I'm wrapping up a working intermediate solution based on the comments above.

Tested to be working with

• Unit Test Framework: xUnit
• VSCode: Insiders 1.11.0
• dotnet CLI: 1.0.1
• OS: macOS 10.12 (should work on Linux as well)

VSCode's launch.json file

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": ".NET Core Attach",
            "type": "coreclr",
            "request": "attach",
            "processId": "${command:pickProcess}"
        }
    ]
}

From Terminal

cd /path/to/test/project/
dotnet test --no-build --filter "FullyQualifiedName=MyNamespace.MyTestsClass.MyTestMethod"

In MyNamespace/MyTestsClass.cs file

c# namespace MyNamespace { public class MyTestsClass { [Fact] public void MyTestMethod() { while (!Debugger.IsAttached) Thread.Sleep(500); MyBuggyMethod(); // Put a breakpoint in this line } } }

From VSCode's Debug View

Press the start debugging green arrow, or F5, just make sure the launch config mentioned above is the one that runs.
Make sure you select the item that looks like the one mentioned in the screenshot bellow:

After that, VSCode's debugger will break in the line mentioned in the C# code above.

Hope this helps.

[DustinCampbell]

FYI that I'm working on getting this implemented in OmniSharp right now. Hopefully I should have something early next week.

[richlander]

Was just creating a simple sample that I want to be usable in VS Code. All is great, but did run into this issue. Looking forward to being able to try the new csproj support for this.

I didn't use the p.j test launch experience in VS Code before, so I'm new to this experience. From a UX standpoint, it is a little odd that there are two disjoint activation experiences:

• Launch/attach to app via the Debug tab, as configured by launch.json and tasks.json.
• Launch tests via the CodeLens experience, as offered by an opaque mechanism.

Ideally, the CodeLens launcher would be just a convenience experience over the Debug tab configurations. It would be nice to have a CodeLens launcher for Main entry points, too, to make it quicker to launch into debugging w/o switching tabs.

[gregg-miskelly]

@richlander I can see why you would want to unify the experiences, but I don't know how naturally this really works. This is also the same as VS --

• Debugging tests via launch.json - unfortunately the .NET CLI doesn't make this an easy feature to implement. The other downside is that you would wind up debugging all you tests this way (or need to select which test every time you launched) so I am not sure how ideal this really is.
• Debugging non-tests via CodeLens: I don't see anything wrong with this, but I am not really sure I see the need either -- we would wind up needing to reinvent all of VS Code's launch logic, and as long as one has launch.json setup, this will happen automatically if you hit F5 or click the play button. So you don't actually need to switch to the debug tab.

[richlander]

Point taken on your first point (Debugging tests via launch.json). You are saying "it's different" and I can see that it is.

On your second point (Debugging non-tests via CodeLens), I'm not seeing how I launch my app w/o switching to the debug tab. F5 doesn't work by default. I'm the Explorer tab most of the time (which I assume is typical). That said, I realized that my idea doesn't make sense for another reason. I was thinking about putting the codelens launcher on the Main method. That's kinda useless given that most of the time that's not the file you are working in. So, we're now getting a ways away from the core issue. I think this all comes down to wanting a way to start a debugging session w/either one mouse click or a keystroke combination, just like in VS.

[gregg-miskelly]

@richlander can you clarify what you mean by 'F5 doesn't work by default'? Are you talking about the fact that MacOS defaults to not using the F-keys as F-keys? Or are you actually seeing that F5 works in the debug tab but doesn't work in the explorer tab?

If the later I am confused -- on all of my machines, F5 works regardless of what the active tab is, and I didn't change anything to make this so (aside from enabling function keys on my Mac) so I don't know why this would be. Does it matter what has the focus?

[richlander]

@gregg-miskelly - F5 only works for me on macOS when I'm in the Debug tab. It works great on Debug but not on others. I have version 1.8.0 of the C# extension.

[DustinCampbell]

@richlander: Does F5 work for you in a node.js project? My expectation is that this isn't related to C# for VS Code.

[richlander]

Good q.

I'm not an expert on node.js development, but the desired behavior appears to work for node.js in my VS Code install. I cloned this repo as my test.

[DustinCampbell]

In that case, I'd recommend filing a separate issue since it's well outside of the scope of this one. Could you provide your project as well? I have sneaking suspicion that the problem might lie in your launch.json file.

[richlander]

K. Agreed.

[DustinCampbell]

FYI to all watching this issue that I have things working on machine. There's probably a day or two of getting my changes both omnisharp-roslyn and omnisharp-vscode into shape for merging.

@gregg-miskelly: As part of this change, I'm planning to switch over to attaching the debugger to the test process for .csproj projects. The VS Test protocol makes launching the test process under the debugger problematic. The biggest issue with this that I can see is that the user is presented with a "disconnect" button rather than a stop button. Do you foresee any other problems?

[gregg-miskelly]

@DustinCampbell do you know if they do anything like while (!Debugger.IsAttached) { Thread.Sleep(...); }? If not, the potential issue is that the test could wind up running before the debugger finished attaching. We could possibly fix that by having the debugger do something after the attach is complete (ex: resume a thread, send a message back to some pipe, etc).

[bradwilson]

You mean this? https://github.com/xunit/xunit/blob/d0708c55b70d5cfa5d6f534706b19cc075f3f0b5/src/xunit.console/Program.cs#L68-L69

[DustinCampbell]

@gregg-miskelly: The VS Test protocol requires sending a message to start running the tests after the debugger is attached, which is what I'm doing. It works fine if I launch the testhost process myself, attach the debugger to the process ID and then send the confirmation message. However, if I launch the testhost process with the debugger, it runs to completion before I can send the confirmation message.

[gregg-miskelly]

@DustinCampbell do you have a contact with the VS Test folks so we can understand why it is running to completion? I don't have a problem figuring out a way to have the debugger resume the process when its ready. But it seems like it might be worth understanding why the process is running to completion as it could be some sort of timing problem or maybe some sort of debugger problem if we are somehow spawning the process 'wrong'.

[xcellsoft]

FYI, I have the same problems in vs 2017 with csproj projects, it will run the entire test file and not just the highlighted test

---

From: Gregg Miskelly [e-mail]
Sent: Thursday, April 6, 2017 12:03:50 PM
To: OmniSharp/omnisharp-vscode
Cc: Chris Baird; Manual
Subject: Re: [OmniSharp/omnisharp-vscode] Implement VSTest support to enable running and debugging .NET Core tests in .csproj projects (#1100)

@DustinCampbellhttps://github.com/DustinCampbell do you have a contact with the VS Test folks so we can understand why it is running to completion? I don't have a problem figuring out a way to have the debugger resume the process when its ready. But it seems like it might be worth understanding why the process is running to completion as it could be some sort of timing problem or maybe some sort of debugger problem if we are somehow spawning the process 'wrong'.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/OmniSharp/omnisharp-vscode/issues/1100#issuecomment-292222331, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AYEOwJrBcqP-KRCmeHN2U3cgZxRg9fb1ks5rtQzmgaJpZM4LYSEd.

[DustinCampbell]

@gregg-miskelly: I do have a contact with the VS Test folks. Mostly, I've been talking with @singhsarab.

I've just submitted OmniSharp changes to add the add/update the necessary endpoints to make this work. Once that's merged, I'll submit a PR to C# for VS Code with changes to update OmniSharp and use the new end points. Once that's in, it'll be easier for everyone else to look for improvements.

[rafamerlin]

After downloading the csharp-1.9.0-beta2-private.zip that @gregg-miskelly added on https://github.com/OmniSharp/omnisharp-vscode/issues/1323#issuecomment-293938786 the run tests option is working for me.

So before installing the run option and the debug option would give me the Failed to start (test/debugger): null errors, now just the debugger returns this null error, the runner is working fine.

I am using Manjaro XFCE and I configured the fallback debugger to use ubuntu.16.04-x64, during my previous attempts to make it work I've also installed icu54 and icu55, not sure if they influence the tests to work, but maybe there's something there.

Cheers

[sakra]

csharp-1.9.0-beta2-private.zip is not working for me. I still get the "Failed to run test because null" message upon trying to run xUnit tests. The OmniSharp Log shows:

[fail]: Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware
        An unhandled exception has occurred: Value cannot be null.
Parameter name: path1
System.ArgumentNullException: Value cannot be null.
Parameter name: path1
  at System.IO.Path.Combine (System.String path1, System.String path2) [0x00006] in <12e050e5b3d34326a1b4e2e7624e75da>:0 
  at OmniSharp.DotNetTest.Helpers.ProjectPathResolver.GetProjectPathFromFile (System.String filepath) [0x0001b] in <c2d39b60719d4237ab66a682dcda30ff>:0 
  at OmniSharp.DotNetTest.Services.RunTestServices.GetResponse (System.String filepath, System.String methodName, System.String testFrameworkName) [0x00000] in <c2d39b60719d4237ab66a682dcda30ff>:0 
  at OmniSharp.DotNetTest.Services.RunTestServices.Handle (OmniSharp.DotNetTest.Models.RunDotNetTestRequest request) [0x00013] in <c2d39b60719d4237ab66a682dcda30ff>:0 
  at OmniSharp.Middleware.Endpoint.Exports.RequestHandlerExportHandler`2[TRequest,TResponse].Handle (TRequest request) [0x00000] in <68b821bbbf434ab18ac832b96792da40>:0 
  at OmniSharp.Middleware.Endpoint.EndpointHandler`2+<HandleSingleRequest>d__18[TRequest,TResponse].MoveNext () [0x00092] in <68b821bbbf434ab18ac832b96792da40>: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 <68b821bbbf434ab18ac832b96792da40>: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 <68b821bbbf434ab18ac832b96792da40>: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/runtest: 500 0ms

[gregg-miskelly]

@sakra to be clear - the unit test support is still in flight.

[DustinCampbell]

OK. This should be working in the latest beta: 1.9.0-beta3. Please try it out!

Please use the instructions for Installing Beta Releases.

[powellcj12]

@DustinCampbell generally seems to be working for me on Mac (10.12.5 beta)!

When I initially installed the beta extension, I was still seeing various errors about not being able to attach the debugger, sometimes the test would never actually run, and one time even a message from VS Code that it was corrupt which linked me here. After reinstalling the app though (I'm running the 1.12.0-Insider Mac build), haven't run into any of those issues since.

[achimschrepfer]

@DustinCampbell seems to work on Mac VSCode 1.11.2 and OmniSharp 1.9.0-beta3 - I had the same experience as @powellcj12 when I first started the debugger. But after then it worked like a charm (without reinstall).

[DustinCampbell]

@powellcj12, @achimschrepfer: Did you uninstall your previous version of C# and restart VS Code before installing the new beta? If not, that would explain why the debugger didn't work immediately (sometimes, VS Code likes to run an older version of an extension if it's still on disk).

[powellcj12]

Yes, I uninstalled the previous extension (which was the previous v1.9 beta), VS Code prompted me to reload (which I did), and then installed the new extension.

[DustinCampbell]

OK. Just wanted to check.

[richlander]

I wasn't able to get this to work on Windows. I installed the beta VSIX and uninstalled the prod one first. I found that the the extension was doing more than before but not the whole job and not reliably. It sometimes ran the test and sometimes gave me the error message that it currently does with the prod version. I can share my code with you if you'd like to try it (private repo).

[DustinCampbell]

Hey @richlander. any chance you'll be in the office tomorrow? If so, maybe we can connect I can take a look at your machine?

[achimschrepfer]

Yep, I also uninstalled the previous version of OmniSharp and restarted VSCode as well.

[richlander]

Interesting. Just tried on my work PC (both "run" and "debug"). Works! Yeahh! Last night, I was using my machine at home. I'll try again tonight. Maybe it needs a harder kick.

Thanks for getting this working!

What do you think on performance? The VS experience (unscientifically) feels significantly faster for running single tests.

[DustinCampbell]

I'll try again tonight. Maybe it needs a harder kick.

Check your %UserProfile%.vscode\extensions folder. I've seen situations (though rarely) where VS Code leaves old extensions lying around and they still get loaded.

What do you think on performance? The VS experience (unscientifically) feels significantly faster for running single tests.

Baby steps @richlander. :smile: VS does a significantly amount of caching (and has an entire team devoted) to making the test experience good. Everytime we run a test, we need to shell out to the .NET CLI to build (with no fast up-to-date checks like VS), and shell out to the .NET CLI again to go through the "test discovery" phase and then do the actual running of the test once it's discovered. I have some ideas to improve this in the future, but getting it working is the high-order bit for 1.9.

[vcsjones]

For what its worth, this doesn't feel any slower to me than when this was working with project.json projects.

[DustinCampbell]

Thanks @vcsjones: It shouldn't, but I'd still like to make it better. :smile:

[DustinCampbell]

OK. A release candidate for 1.9.0 is built and ready for testing. Once we feel good about this build, we'll push it to the marketplace (hopefully tomorrow -- we'll see! :smile:)

[fedoranimus]

I'm able to test now using the debugger and the launch tasks generated by VSCode.

However, when using the "debug test" option, I'm still seeing this issue.

Using 1.9.0 version of this plugin.

[DustinCampbell]

Are you referring to the code lens items being out of order? If so, that's tracked with https://github.com/OmniSharp/omnisharp-vscode/issues/936.

[fedoranimus]

No, while that is annoying, I'm referring to clicking the CodeLens "debug test" item and then receiving the message: "Failed to run test because null" as described in this issue originally.

The "run test" item works fine.

I'm running 1.9.0 of the omnisharp extension, 1.11.2 of VSCode.

[DustinCampbell]

Could you go ahead and file a new issue?

[Jonathan34]

works fine with 1.9.0 and vscode 1.12.0 and .net core 1.1
thanks!

[powellcj12]

@fedoranimus I saw the same thing temporarily - can't seem to hit it any more, but my initial suspicion was that it was related to the specific .NET runtime I was targeting...

.NET Core 1.1 worked fine. I changed it to target .NET Standard 1.4 which resulted in some errors restoring packages, so I subsequently changed it to .NET Standard 1.5. At this point the 'debug' option in the extension wasn't working. I restored to .NET Core 1.1 and things started working again, but now everything works regardless of if I target .NET Core 1.0 or .NET Standard 1.4-1.6 so not really sure what might be happening. Still, might be worth checking the runtime you're targeting?

[fedoranimus]

Thanks @powellcj12 I will double check.

If the situation persists, I will open a new issue tonight @DustinCampbell.

[DustinCampbell]

Thanks @fedoranimus!

[fedoranimus]

1428 Created to address the new issue

[jmezach]

This isn't working yet for MSTest projects. Is that a separate issue, or should that work as well now?

[DustinCampbell]

Separate issue please. Nothing has been done to support MSTest yet.