-
Notifications
You must be signed in to change notification settings - Fork 680
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement VSTest support to enable running and debugging .NET Core tests in .csproj projects #1100
Comments
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. |
+1 |
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 @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 |
OK. I'm making some progress with |
Keep in mind xUnit are looking to make their own command eg/ |
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. |
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>
.
|
I agree, you should. |
Will there be a |
Eventually. This just tracks getting the CodeLens indicators for "run test" and "debug test" working for .csproj. |
Ah, I missed that. That would also be brilliant! |
ah well, another road blocker with xunit and vscode :( |
as a workaround: you can edit your tasks.json to add the test tasks you want, bind a shortcut like this:
and select the test task. alternatively, switch to vs 2017 :) |
Great suggestion! |
@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 ? |
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. |
@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. |
@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). |
@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). |
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. |
OK. Just wanted to check. |
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). |
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? |
Yep, I also uninstalled the previous version of OmniSharp and restarted VSCode as well. |
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. |
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.
Baby steps @richlander. 😄 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. |
For what its worth, this doesn't feel any slower to me than when this was working with project.json projects. |
Thanks @vcsjones: It shouldn't, but I'd still like to make it better. 😄 |
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! 😄) |
Are you referring to the code lens items being out of order? If so, that's tracked with #936. |
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. |
Could you go ahead and file a new issue? |
works fine with 1.9.0 and vscode 1.12.0 and .net core 1.1 |
@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? |
Thanks @powellcj12 I will double check. If the situation persists, I will open a new issue tonight @DustinCampbell. |
Thanks @fedoranimus! |
#1428 Created to address the new issue |
This isn't working yet for MSTest projects. Is that a separate issue, or should that work as well now? |
Separate issue please. Nothing has been done to support MSTest yet. |
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
dotnet --info
output: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:
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
The text was updated successfully, but these errors were encountered: