omnisharp 1.36.1 fails to analyze my solution (1.35.3 does not fail) #1889
Comments
|
Is it possible to get a copy of the solution or a solution that repro's the issue? Looks like it might be the entity framework analyzers, perhaps we can build some tests around them. |
|
Gonna ask the stupid question -- if I am not using Entity Framework (I am using strictly Dapper) -- does that change your thought process, or do you mean something else by "entity framework analyzers"? If I get the OK to share the solution, how would we go about doing that privately? |
|
Keybase is probably the best way to do so: https://keybase.io/daviddriscoll you can send messages and files end-to-end encrypted. |
|
As far as EF is concerned I'm just wondering if there is some new analyzer or something there that is conflicting. You may not be using it, but it is being loaded. |
|
" is is " -- invites reminiscences of how Bill Clinton would analyze this sentence... I will see if I can get a small public solution that reproduces the problem. |
|
lol, or I just can't type! |
|
OK, now I'm desperate... getting this error while I hunker down in 1.35.3 Downloading package 'OmniSharp for Linux (x64), Version = 1.35.3' Failed to download from https://roslynomnisharp.blob.core.windows.net/releases/1.35.3/omnisharp-linux-x64.zip. Error code '404') Help? While I wait desperately, I will see if I can produce a small project that produces the error with 1.36.1 |
|
I think the problem is that I had allowed VSCode to update. It is now on 1.23.0 as of today, and now I've lost this folder which had 1.35.3 in it. Is there a way to regain all this easily? I'll see about restoring a backup. Sigh. |
|
I have posted a repository here that produces the same error message. Because I have removed basically everything, the failure to analyze documents doesn't happen -- there are none to analyze. But hopefully the presence of the error message is enough? https://gitlab.com/brian.wells/omnisharp Omnisharp log: |
Oops just saw this. Anyway, what I shared is bereft of code, so I guess we're fine. |
|
I'm watching 1890 with keen interest... just saying... 😬 |
|
Sorry to bother, two quick questions. Was my shared project helpful in demonstrating what's not working for me? Is work on 1890 related to this issue here? |
|
To be honest I didn't get around to looking at it because I was working on that other issue all weekend. I'll try and make time tonight to see if I can figure it out. Sorry! |
|
ok, np thx -- just confused because issue 1890 makes references to this one. Let me know if the shared project is not sufficient to crack open what's going wrong in my actual one. Thx again! |
|
I just now followed guidance given for similar issue 1890. The errors at the top of the log have gone away, but Omnisharp still fails to get through analyzing the documents. 1.37.1 log (errors out)Starting OmniSharp server at 8/18/2020, 8:49:07 PM OmniSharp server started. Starting OmniSharp on ubuntu 18.4 (x64) 1.35.3 log (it does complete successfully after a minute or two)Starting OmniSharp server at 8/18/2020, 8:50:48 PM OmniSharp server started. Starting OmniSharp on ubuntu 18.4 (x64) |
|
Actually, it seems (?) 1.35.3 just fails less frequently and less rapidly. I'm sometimes seeing the timeouts with 1.35.3, too. Just a lot less frequently. Keeping an eye open. Part of the problem is that I have to reload the VSCode window constantly because of 1794, which just exacerbates the situation. When working my way through unit tests, I will reload VSCode easily 10 to 30 times in an hour. |
|
Any thoughts on this issue? I've got a temporary work-around in that I'm sticking to 1.35.3 but that's not a long-term solution. Thanks much in advance. If necessary, I may be able to simply share my entire project, if that's what it takes to make the issue reproducable. |
|
The import issue you had has been resolved already - however it has nothing to do with analyzer behavior. In fact, the analyzer logic has not changed for a long time. The only thing that you must be experiencing is that certain performance characteristics in the Roslyn compiler, as we moved to 3.8.x generation, must have changed (worsened). The best solution to this would be to increase the analysis timeout, which is by default set to 10 seconds. See here for the relevant setting https://github.com/OmniSharp/omnisharp-roslyn/wiki/Configuration-Options#roslyn-extensions-options |
|
Yes, i glommed onto the fact that the fix was for something that wasn't the root cause of my own woes. Your point about performance degradation makes sense, and I was not aware I could change the timeout. Thank you for alerting me to the setting. I had no idea that was within my control. I added a zero to it and the errors have gone away. I was about to humorously point out that the trade-off is that the analysis doesn't fail... it just doesn't finish! But it just did finish (taking maybe 5 minutes total time?) and I'm very thankful for your help, here! Very, very thankful! |
If I allow ominsharp.path to be "latest" and get 1.36.1, my vscode load produces the following:
Further down analysis of documents fail...
However if I revert to
"omnisharp.path": "1.35.3"
I receive no errors at all.
The text was updated successfully, but these errors were encountered: