vscode-csharp: After single test debug, Omnisharp "crashes" silently
Environment data
dotnet --info output:
.NET Command Line Tools (2.0.0)
Product Information:
Version: 2.0.0
Commit SHA-1 hash: cdcd1928c9
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/2.0.0/
Microsoft .NET Core Shared Framework Host
Version : 2.0.0
Build : e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d
VS Code version: 1.17.2 b813d12980308015bcd2b3a2f6efa5c810c33ba5 C# Extension version: 1.12.1 Xunit: 2.2.0
Steps to reproduce
- Open a solution folder in VSCode
- Navigate to a test in the project
- Choose to
Debug Test - Allow test to execute to finish (F5)
- Attempt to debug or run test again OR attempt to trigger Intellisense
Expected behavior
After test has run, OmniSharp is able to run and debug tests, and provides Intellisense from open project windows.
Actual behavior
After test has run, OmniSharp will no longer be able to run or debug a test, nor provide intellisense until restart of VSCode.
The following is the output in the OmniSharp Debug Log after turning on logging with "omnisharp.loggingLevel": "debug" (note that classnames and file paths were find/replaced, and base 64 removed – can provide if needed):
[dbug]: OmniSharp.DotNetTest.VSTestManager
read: {"MessageType":"TestExecution.StatsChange","Payload":{"NewTestResults":[{"TestCase":{"Properties":[{"Key":{"Id":"TestCase.FullyQualifiedName","Label":"FullyQualifiedName","Category":"","Description":"","Attributes":1,"ValueType":"System.String"},"Value":"MyClass.MyTestMethod (cef3ff6adf55e367891e1369e8ce731ad73a47a7)"},{"Key":{"Id":"TestCase.ExecutorUri","Label":"Executor Uri","Category":"","Description":"","Attributes":1,"ValueType":"System.Uri"},"Value":"executor://xunit/VsTestRunner2"},{"Key":{"Id":"TestCase.Source","Label":"Source","Category":"","Description":"","Attributes":0,"ValueType":"System.String"},"Value":"/Users/greg/Code/MySolution/test/MyTestProject/bin/Debug/netcoreapp2.0/MyTestProject.dll"},{"Key":{"Id":"TestCase.CodeFilePath","Label":"File Path","Category":"","Description":"","Attributes":0,"ValueType":"System.String"},"Value":"/Users/greg/Code/MySolution/test/MyTestProject/EndpointTests.cs"},{"Key":{"Id":"TestCase.DisplayName","Label":"Name","Category":"","Description":"","Attributes":0,"ValueType":"System.String"},"Value":"MyClass.MyTestMethod"},{"Key":{"Id":"TestCase.Id","Label":"Id","Category":"","Description":"","Attributes":1,"ValueType":"System.Guid"},"Value":"ab9c8bad-66f9-eb4d-a7e1-7dde43a5d7cf"},{"Key":{"Id":"TestCase.LineNumber","Label":"Line Number","Category":"","Description":"","Attributes":1,"ValueType":"System.Int32"},"Value":91},{"Key":{"Id":"XunitTestCase","Label":"xUnit.net Test Case","Category":"","Description":"","Attributes":0,"ValueType":"System.String"},"Value":"Xunit.Sdk.XunitTestCase, xunit.execution.{Platform}:`/* SNIP Base64 */`"},{"Key":{"Id":"TestObject.Traits","Label":"Traits","Category":"","Description":"","Attributes":5,"ValueType":"System.Collections.Generic.KeyValuePair`2[[System.String],[System.String]][]"},"Value":[{"Key":"Type","Value":"Not-Unit"},{"Key":"Type","Value":"EndToEnd"},{"Key":"Type","Value":"Not-Integration"},{"Key":"Type","Value":"Not-Performance"},{"Key":"Category","Value":"Purpose-Not-Unit"},{"Key":"Category","Value":"Purpose-EndToEnd"},{"Key":"Category","Value":"Purpose-Not-Integration"},{"Key":"Category","Value":"Purpose-Not-Performance"}]}]},"Attachments":[],"Messages":[],"Properties":[{"Key":{"Id":"TestResult.Outcome","Label":"Outcome","Category":"","Description":"","Attributes":0,"ValueType":"Microsoft.VisualStudio.TestPlatform.ObjectModel.TestOutcome, Microsoft.VisualStudio.TestPlatform.ObjectModel, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"},"Value":2},{"Key":{"Id":"TestResult.ErrorMessage","Label":"Error Message","Category":"","Description":"","Attributes":0,"ValueType":"System.String"},"Value":"Assert.Equal() Failure\nExpected: Accepted\nActual: BadRequest"},{"Key":{"Id":"TestResult.ErrorStackTrace","Label":"Error Stack Trace","Category":"","Description":"","Attributes":0,"ValueType":"System.String"},"Value":" at MyClass.<MyTestMethod>d__6.MoveNext() in /Users/greg/Code/MySolution/test/MyTestProject/EndpointTests.cs:line 96\n--- End of stack trace from previous location where exception was thrown ---\n at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()"},{"Key":{"Id":"TestResult.DisplayName","Label":"TestResult Display Name","Category":"","Description":"","Attributes":1,"ValueType":"System.String"},"Value":"MyClass.MyTestMethod"},{"Key":{"Id":"TestResult.ComputerName","Label":"Computer Name","Category":"","Description":"","Attributes":0,"ValueType":"System.String"},"Value":"am-mbp-016"},{"Key":{"Id":"TestResult.Duration","Label":"Duration","Category":"","Description":"","Attributes":0,"ValueType":"System.TimeSpan"},"Value":"00:00:12.2100000"},{"Key":{"Id":"TestResult.StartTime","Label":"Start Time","Category":"","Description":"","Attributes":0,"ValueType":"System.DateTimeOffset"},"Value":"2017-10-18T14:51:01.246646-07:00"},{"Key":{"Id":"TestResult.EndTime","Label":"End Time","Category":"","Description":"","Attributes":0,"ValueType":"System.DateTimeOffset"},"Value":"2017-10-18T14:51:01.246651-07:00"}]}],"TestRunStatistics":{"ExecutedTests":1,"Stats":{"Failed":1}},"ActiveTests":[]}}
/Users/greg/.vscode/extensions/ms-vscode.csharp-1.12.1/.omnisharp/run: line 44: 16109 Killed: 9 "${MONO_CMD}" --assembly-loader=strict --config "${CONFIG}" "${OMNISHARP}" "$@"
About this issue
- Original URL
- State: open
- Created 7 years ago
- Reactions: 43
- Comments: 83 (16 by maintainers)
@galvesribeiro This is a complicated issue and we’re working with the mono and MSBuild teams to investigate.
Same issue for me as well. As mentioned above, just restarting OmniSharp does not help, but it seems that <kbd>CTRL</kbd>+<kbd>Shift</kbd>+<kbd>P</kbd>
> Reload Windowdoes restore functionality. A little quicker than quitting VS Code altogether and relaunching.Same issue here. It’s a show stopper for me I think. Nothing stands out in omni-sharp logs. I see the test complete, and then all omnisharp functionality is halted. If I restart omnisharp, the status at the bottom will be a flame and say “Running”, usually it will have a flame and the solution file name. Only way to get it running again is to quite vscode.
Is there any news to fix this omnishit bug?
Killed "${mono_cmd}" "${omnisharp_cmd}"This error is happening to me regularly across multiple unrelated tests. I seem to get normal Omnisharp logging until all of a sudden I get this.
VSCode then has to be restarted to get Intellisense and testing back.
I am a “Libre User Worker”. So I use as much as I can Libre and Open source software, and I have contributed in more than 10 projects (bug, codes, doc, etc…).
Microsoft is bigger than any of these enterprises, or volunteers, behind any of these projects in which I contributed, and yet some of them provide support, but here, with Microsoft, there is no support…
You want to use an IDE with a decent support for the C# stack? Well, you have to use Visual Studio on Windows. But wait, Windows 10 is, in itself, a bloatware that spies while annoying you with ads, even if you paid the license…
Not to mention Visual Studio for Mac that is as buggy as MonoDevelop… As to MonoDevelop on Linux, it is almost unusable because of the debugger issue…
And of course, Microsoft do not propose Visual Studio outside Windows (certainly, they develop it deeply coupled with Windows)… I would have bought if only it was available on Linux, but no…
But why and how I get stuck in such wired situation? Well because Microsoft said that you can develop .NET Core and C# apps with Vscode on Linux and Mac… They write this on their website and docs, tell this in a lot of their conferences. But they lied.
But I trusted them, and I start to develop not so big projects (~150 000 lines of code) with Vscode and Omnisharp.
At first, Omnisharp was pretty stable. And I remember when the review of the extension were very positive and the mark was around 4.8/5.
But slowly, I find more and more troubles to develop with Omnisharp, because it became evermore buggy. Welcome OmniBUGs.
At the same time, the mark went slowly from 4.8, to 4.5, to 4, and now 3.5/5 with 10.5M reviews… It sucks for something developed by Microsoft. Even the Python extension developed by Microsoft seems better with a mark of 4.5 for 32.8M reviews.
Insane, Microsoft do a better work with an extension for a dynamic language (that are know to be more difficult) than their own language and stack (Blazor support is very sketchy)…
Even worse, some of the bugs are very old, and prevent you to use Omnisharp.
And now? I have to restart, randomly, Omnisharp, or quit Vscode and reopen it to bring back Omnisharp and the debugger. How many times per day? Well around 20 times…
It takes at every turn minutes to load all my projects. And I remember each time what Microsoft write and say : “You can develop with Linux”, “Cross-platform software”.
Microsoft lied, and put a lot of Omnisharp users in Vscode in troubles. Bugs are not fixed, there is no support, no real alternative and I should not say anything? Well I disagree with this. Sorry, but this Omnisharp is a shame. it shouldn’t even be marked as stable.
@rchande Any word on this? Coming up on 2 years since this was reported now.
This is literally the only issue I have with using C# in VS Code. If you guys manage to fix this then I will not have to reload it every 5 minutes. You will save my life 😃
@vintzl @armitagemderivitec
Generally, I try to stay out of conflict in Github (and the Internet in general), but I feel I need to say something. I, along with many others, get notifications for this particular issue. I am interested in knowing when it’s resolved, but these types of comments that you are making are not in service of that goal.
It sounds like you both have strong opinions about the state of .NET development with macOS. Having and expressing opinions is fine. However, this thread (and rarely Github issues in general) is not the appropriate place for that. I would recommend Twitter, Reddit, blogging, etc. for a long-form discussion of your particular grievances.
Furthermore, please consider the feelings of the many maintainers who contribute to this project and many others you probably use. For example, I would never consider walking into a React thread and saying, “Yeah, this library is unusable. I use Vue; it’s incredible.” That simply shows a disregard for the thankless effort many people put into this software which we often pay $0/year for.
This bug is going to deserve a blog post once it’s fixed.
On Thu, Jun 11, 2020 at 5:59 AM Paul Hannon notifications@github.com wrote:
@akshita31 Thanks! I also experience it on Ubuntu 18.4 but not on Windows.
@rchande I am able to reproduce it on my Ubuntu 18.04 system after clicking the “Debug Test” 2-3 times. Here is the repro project: https://github.com/akshita31/Samples-BankTesting.
Here is my OmniSharp log:
This also happens with me when debugging any test - it doesn’ matter if you stop the debugging session or if you let it continue until the end. Even restarting omnisharp won’t make this work. you have to restart vs code as a whole.
I ctrl+F searched but didn’t see this mentioned, but there is a way to debug from the CLI and still use VS Code while this is being fixed. Setup a debug configuration in your
launch.json:And then from the CLI:
Start the “.NET Core Attach” debugger in VS Code and pick the process number listed in the output from the
dotnet test ...command.And I do understand the whole point of the “click to debug” is that you don’t need this rigamarole, but it helped me enhance my
dotnetCLI-fu and not have to reload the VS Code window every time. (Runexport VS_HOST_DEBUG=0to turn this off).Going on 3 years… 🤦
Can confirm this is still an issue
Same problem happens on OSX.
No doubt! Trust me, I’m going to get carpel tunnel, hitting Ctl-Shift-P and picking that option dozens of times a day.
For the record, I am deeply in love with VSCode. Not trying to be whiny with respect to this awesome OSS tool. This just happens to be my big pain point. Nearly safe to say my only pain point.
Here to report problem still present on Ubuntu 18.04 and (like coronavirus) it does not discriminate between noobs and experts. This noob is thankful to @ethan-deng and @Ghostbird for posting a work-around.
@paulhannon0 None of the people you are messaging work on this area. I will follow up with some folks though and see if I can get this issue some love.
@DustinCampbell @rchande @gregg-miskelly Can anybody shed any light on this? Well over 2 years old now…
@rchande
👍 for getting this fixed. This is a major annoyance. Any additional steps I could run to help debug this?
VSCode 1.27.0ms-vscode.csharp 1.15.2My work around has been to exit the debug session (click the red box) before the unit test completes.
On Sat, Aug 11, 2018, 7:52 AM seanamosw notifications@github.com wrote:
I’m also bumping into this. As others have said, using
Restart OmniSharpfrom the command palette doesn’t get OmniSharp working again. You have to at minimum useReload Windowto get it working again.I tried to track down in what cases it reproduces, but it is kind of random. Sometimes you can debug multiple times in a row and it works just fine. Most of the time, a single debugging session is enough to crash it, especially if you inspect variables.
VSCode 1.25.1ms-vscode.csharp 1.15.2Is there a workaround available for this? I think this issue is causing me problems too. I run an xUnit test from the “debug test” text that appears above the test method. Then after I’ve finished debugging that test, the “debug test” button no longer appears. I have to restart VSCode to debug the test again.
Note: Restarting Omnisharp through <kbd>Ctr</kbd>+<kbd>Shift</kbd>+<kbd>P</kbd>
> Omnisharp: Restart Omnisharpdoes not bring the button back.The Omnisharp log reads:
Lots of lines that seemed irrelevant snipped
EDIT: Just updated the plugin to version 1.14.0, but the problem persists. EDIT: It seems specific to a case like this:
And then only when an exception is thrown in
x(). Whenx()returns null and the.operator throws an exception, omnisharp does not crash.I am experiencing the same issue.
Environment
VSCode: 1.19.3 C# Extension: 1.13.1
Steps to reproduce:
throw new System.Exception("message");Expected behavior
Actual behavior
This useful comment by @BDisp led to this successful workaround…
Kill the current process in the teardown and omnisharp no longer crashes.
This seems to have solved my problem without any side effects
Still same problem, VS Code at Apple M1, for years … Hey developers, please help to us 😃
I would start by verifying that a simple project does not display the bug. Then it’s a matter of figuring out what is going on with the project that does display it.
In my case, it seems like I saw this when there was a task that accidentally got missed for await. Possibly also there may have been an exception on the async thread. Omnisharp would barf in some combination of the foregoing. It may not be the only case that causes this, though.
I would start by proving that the problem does not occur with a simple, non-async project. If that’s the case, then try to find places where tasks might be getting lost (not await-ed). To find the non-awaited task in my case, I had to identify a particular code path where I would see this happening, and then start commenting out sections of code until I located the offending lines. It was a real pain, but it did lead to finding a nasty bug.
On Fri, Aug 28, 2020 at 2:37 PM Brian Wells notifications@github.com wrote:
Boy I’d love to fix that if that is the problem. What sorts of things would I be looking for? I’d be very keen to hunt such things down if it would solve this problem for me.
For what it’s worth, you can use the command palette option “Developer: Reload Window”, so you don’t have to exit all your other VS Code windows/tabs.
On Thu, Aug 27, 2020 at 6:21 AM Brian Wells notifications@github.com wrote:
Reporting same issue ubuntu 18