Omnisharp connects but fails to work

[Mallchad]

Describe the bug
After connecting the omnisharp language server when opening a .cs file, nothing much in it just for test purposes to see if the server worked I always get errors, either System.NullReferenceException or (wrong-type-argument hash-table-p nil) like mentioned in #815
I believe this is purely an lsp-mode problem because standalone omnisharp-emacs (https://github.com/OmniSharp/omnisharp-emacs) works just fine almost out of the box even though they use the same server of omnisharp-roslyn
Flycheck also states that "A suitable syntax checker is not found." despite the connecting to the language server.
To Reproduce
Emacs with lsp mode hooked onto prog-mode.
omnisharp roslyn release or build placed in ~/.omnisharp/omnisharp/omnisharp
empty C# file, hovering over any text will give you the error

Expected behavior
I expected to get either some kind of flycheck error or C# related company popup while typing or manually invoking M-x company-lsp

Which Language Server did you use
Omnisharp-Roslyn, release, manual build using including build.ps1 and through copying over Omnisharp-emacs files
OS
Which os do you use?
WIndows 10
Error callstack
If there is an error please reproduce the issue with toggle-debug-on-error and after setting lsp-print-io to t, and then include the callstack and attach the content of *lsp-log* buffer and the content of the server log(use lsp-workspace-show-log)
LSP Log Error

Failed to handle notification textDocument/signatureHelp - System.NullReferenceException: Object reference not set to an instance of an object.

   at OmniSharp.LanguageServerProtocol.Handlers.OmniSharpSignatureHelpHandler.<Handle>d__3.MoveNext() in D:\a\1\s\src\OmniSharp.LanguageServerProtocol\Handlers\OmniSharpSignatureHelpHandler.cs:line 45

--- End of stack trace from previous location where exception was thrown ---

   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()

   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

   at OmniSharp.Extensions.LanguageServer.Server.Pipelines.ResolveCommandPipeline`2.<Handle>d__5.MoveNext()

--- End of stack trace from previous location where exception was thrown ---

   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()

   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

   at OmniSharp.Extensions.JsonRpc.RequestRouterBase`1.<RouteRequest>d__6.MoveNext()
Finished: Routing Request (6) textDocument/signatureHelp in 23ms

LSP Full Log
(https://gist.github.com/Mallchad/b6c7900b6975d5169826bae963bcf994)
LSP IO Log Error

Params: {
  "message": "Failed to handle notification textDocument/signatureHelp - System.NullReferenceException: Object reference not set to an instance of an object.\r\n   at OmniSharp.LanguageServerProtocol.Handlers.OmniSharpSignatureHelpHandler.<Handle>d__3.MoveNext() in D:\\a\\1\\s\\src\\OmniSharp.LanguageServerProtocol\\Handlers\\OmniSharpSignatureHelpHandler.cs:line 45\r\n--- End of stack trace from previous location where exception was thrown ---\r\n   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at OmniSharp.Extensions.LanguageServer.Server.Pipelines.ResolveCommandPipeline`2.<Handle>d__5.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at OmniSharp.Extensions.JsonRpc.RequestRouterBase`1.<RouteRequest>d__6.MoveNext()",
  "type": 1
}

LSP IO Full Log
(https://gist.github.com/Mallchad/decd44f66df2cc973391aabb5a1201b9)

[yyoncho]

Are you sure that you are using the latest version of the omnisharp? There were a lot of issues fixed in omnisharp regarding lsp support.

[Mallchad]

@yyoncho both tried the one installed from Omnisharp and actual omnisharp-roslyn page but I'll try and see if I can find an unstable branch that works when I get a chance.

[ptdel]

I'm also getting this issue:

Failed to handle notification textDocument/signatureHelp - System.NullReferenceException: Object reference not set to an instance of an object
  at OmniSharp.LanguageServerProtocol.Handlers.OmniSharpSignatureHelpHandler.Handle (OmniSharp.Extensions.LanguageServer.Protocol.Models.SignatureHelpParams request, System.Threading.CancellationToken token) [0x000d1] in <4f606786ff8f4b28a835225ed6e367d1>:0 
  at OmniSharp.Extensions.LanguageServer.Server.Pipelines.ResolveCommandPipeline`2[TRequest,TResponse].Handle (TRequest request, System.Threading.CancellationToken cancellationToken, OmniSharp.Extensions.Embedded.MediatR.RequestHandlerDelegate`1[TResponse] next) [0x000e1] in <12a97e97079c4b10a770c2869fa566a9>:0 
  at OmniSharp.Extensions.JsonRpc.RequestRouterBase`1[TDescriptor].RouteRequest (TDescriptor descriptor, OmniSharp.Extensions.JsonRpc.Server.Request request, System.Threading.CancellationToken token) [0x0038a] in <709d80c63bce4fcd8b1071c79413b97b>:0 ```

followed by:

Error running timer: (wrong-type-argument hash-table-p nil) [4 times]

Omnisharp-Roslyn is on v1.34.7
Mono on 6.4.0
MSBuild 16.3

I can confirm that I don't get this issue with standalone Omnisharp-Emacs

[Mallchad]

I couldn't find a newer version of omnisharp-roslyn. but I tried older versions, namley a 6 month old one, linux vs windows, even gave it a go on msys. I tried an older lsp-mode.el . Couldn't get any of them working. I might have messed up trying an older version of omnisharp-roslyn, but I can only assume that there is something wrong with lsp-mode in my particular configuration.

[yyoncho]

@Mallchad can you try with the latest lsp-mode? It will automatically download and configure omnisharp. In case, it still does not work can you attach a sample project?

[razzmatazz]

The same thing happens to me. However if I refresh the file with C-x C-v AFTER the server has completely finished loading .csproj's then the issue goes away.

The actual issue appears for me to be that omnisharp-roslyn sends a response to initialize too early:

• https://microsoft.github.io/language-server-protocol/specifications/specification-3-14/#initialize

I.e. it sends the response before it has finished loading all the projects on the solution, thus any requests lsp-mode sends before that is done are bound to fail in some way. For some larger solutions it might take a while for all projects to load and for the moment we don't have a way to know when except for watching when these (or similar) lines appear on *lsp-log*:

...
initialized...
(omnisharp/roslyn is still actually loading .csprojs at this point)
...
crashes to textDocument/signatureHelp are logged here
...
Successfully loaded project file '/Users/bob/src/omnisharp/test/test.csproj'.
Adding project '/Users/bob/src/omnisharp/test/test.csproj'
Update project: test
...

There has been a couple of issued registered on omnisharp-roslyn repo on this:

• [LSP] initialized seems to be sent too eagerly OmniSharp/omnisharp-roslyn#1245
• LSP sometimes sends initialized too early and ignore some following events OmniSharp/omnisharp-roslyn#1445
• Early request to /highlight endpoint throws NullReferenceException OmniSharp/omnisharp-roslyn#1521
• Monitoring project state (wait until fully loaded etc.) OmniSharp/omnisharp-roslyn#1580

BTW this same crash appears to be happending for @sebasmonia on #1108 (comment)

[yyoncho]

Thank you @razzmatazz . Do you think we can create a workaround by waiting for "Successfully loaded project file" message or we should close the issue and wait for the upstream?

[razzmatazz]

IMHO fixing this upstream is a better approach, – I will try to register an issue and/or maybe a PR to omnisharp-roslyn once I understand what is actually wrong here..

[yyoncho]

IMHO fixing this upstream is a better approach, – I will try to register an issue and/or maybe a PR to omnisharp-roslyn once I understand what is actually wrong here..

Ok. Then once you have a more details I suggest closing this issue and #1108 and adding a faq entry pointing to the upstream issue(and eventually mentioning that the user should wait for the loaded project message).

[easbarba]

@razzmatazz @yyoncho
Still happening with the latest version(1.34.9), reopening file does, indeed, "fix" the issue!

[yyoncho]

@razzmatazz do you know if the upstream has been fixed?

[razzmatazz]

As far as I know — not yet (tested a couple of weeks ago) Actually I have started writing my own lsp server for C# in the meantime — l as attempting to fix omnisharp is just too much mental load for me, the codebase is rather sophisticated/complicated. https://github.com/razzmatazz/csharp-language-server I forked lsp wiring off https://github.com/fsprojects/fsharp-language-server and things are surprising easy to implement. (I know Pareto rule will show its head eventually) —Saulius Menkevičius

…

Am 22.02.2020 um 15:03 schrieb Ivan Yonchovski ***@***.***>:  @razzmatazz do you know if the upstream has been fixed? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[yyoncho]

@razzmatazz that is cool. Feel free to link it from lsp-mode supported servers if you are looking for more contributors.

[razzmatazz]

It is really too early, basic things don’t work. But definitely will inform once I have something that works somewhat for me, — having something that works is better than nothing.

In the meantime I’m ok with using omnisharp-emacs w/omnisharp (non lsp Setup)

[easbarba]

@razzmatazz @yyoncho

It seems to be fixed in yesterday's release: https://github.com/OmniSharp/omnisharp-roslyn/releases/tag/v1.34.14

At least, it is yet again feeding popup information and company completion correctly.

No need to reopen the file once the project is fully loaded.

Still, I had a few issues that eventually I will be able to reproduce.

---

dotnet --version: 3.1.101
lsp commit: 9f2333b
emacs version: GNU Emacs 28.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.14, cairo version 1.16.0) of 2020-03-12
Debian SID 11

[razzmatazz]

@lxbarbosa great! will take a look to confirm

[easbarba]

Actually it's not working at all. LOL

Once it loads a project it parsers and correctly provides information to popup and company.

Changing the code and it is stuck with early "parsing" state.

eg: changing a string var to char and it still shows the same early information. The same goes for company completions.

As for linting, flymake never "worked"

Well, its almost there :D

[gamedolphin]

It does not work for me either. It connects, but then nothing. Not even a popup or company. :(

[razzmatazz]

Yes, it still does not work.

However, I noticed @david-driscoll and others are still actively working on improving LSP part of Omnisharp so hopefully LSP w/ C# is coming eventually:

• https://github.com/OmniSharp/csharp-language-server-protocol/commits/master

[razzmatazz]

I made a PR for omnisharp-roslyn that upgrades LSP component and doing that fixes some of the issues (at least for me) -- now I have proper autocompletion context, flycheck, go-to-def, lenses and some other things working.

• Upgrade Omnisharp.Extensions.LanguageServer to 0.16.0 OmniSharp/omnisharp-roslyn#1754

[easbarba]

v1.35.1 released.

Most of its feature works correctly once LSP finishes loading it.

But it still unaware of any change in the file is made.

[razzmatazz]

@lxbarbosa yeah, that is because of omnisharp-roslyn LSP file sync issue. My PR to fix this is no longer WIP, -- hopefully maintainers of omnisharp-roslyn will take a look at that.

[easbarba]

For those interested the issue seems to be fixed in OmniSharp/omnisharp-roslyn#1791.

YES!

doomemacs/doomemacs#2448

[sebasmonia]

Using a minimal project to test and building Omnisharp from master, I didn't get the proper list of completion candidates from for the BCL classes. :(

[Mallchad]

I don't know what's wrong on my end but omnisharp has hardly worked for me at all with lsp-mode.
It's showing hardly any capabilities even on the latest everything.

[razzmatazz]

I don't know what's wrong on my end but omnisharp has hardly worked for me at all with lsp-mode.
It's showing hardly any capabilities even on the latest everything.

Thats the features omnisharp exposes over LSP. It is not a configuration issue on your part but rather an issue of incomplete implementation. I have a PR to add support for “textDocument/codeActions” though:

• LSP: wire up handler for codeAction OmniSharp/omnisharp-roslyn#1795

LSP is/was second-class protocol for omnisharp-roslyn, as most of development has until now been focused on exposing features over the native protocol (used by omnisharp-vscode, omnisharp-emacs, omnisharp-atom, etc.)

[razzmatazz]

I have also added a handler for the workspace/symbol request in this PR:

• LSP: wire up handler for workspace/symbol OmniSharp/omnisharp-roslyn#1799

[easbarba]

Pre-release of v1.35.2 with @razzmatazz PRs is out.

https://github.com/OmniSharp/omnisharp-roslyn/releases/tag/v1.35.2

@sebasmonia

[razzmatazz]

Uh, they didn’t merge the code actions and workspace symbols handlers yet.. but the sync issue should be fixed finally though.

[easbarba]

@razzmatazz
That's more than enough to make Emacs my favorite C# IDE :)

[Mallchad]

Can confirm the latest update does solve most issues.
Although...
I found out that part of my problems with due to an sln/csproj (maybe out of date, maybe corrupted? idk) completely blocking any of the other features from working as well, I have no idea what that was all about.
I am happy now, thanks for your hard work guys!

[easbarba]

@Mallchad
Which features are still not working? a new toy project of mine, net core 3.1.4, and lap "is working fine in my computer" :)

[gamedolphin]

This is wonderful. Thank you! It works like a charm. Bye bye omnisharp-emacs? Most probably.

[razzmatazz]

This is wonderful. Thank you! It works like a charm. Bye bye omnisharp-emacs? Most probably.

I am planning to deprecate omnisharp-emacs eventually, but some features are still not working with LSP. At least the ones that I use :) -- e.g. running unit test(s). Thus I am kind of reluctant to declare a victory yet.

I am starting to implement some of those things (unit test running on queue):

• LSP: expose omnisharp/client/findReferences custom command for code lenses OmniSharp/omnisharp-roslyn#1807

[Mallchad]

@razzmatazz I agree it is good but there is still a lot of work to be done.
Especially when you compare the capabilities to clangd (which is feature rich).
Currently I'm not noticing much that I would miss aside from symbol highlighting, I can live without
this though.

@lxbarbosa as to answer your question the one thing that doesn't necessarily work is external libraries, particularly UnityEditor.dll
But this was always problematic.

[sebasmonia]

I am planning to deprecate omnisharp-emacs eventually, but some features are still not working with LSP. At least the ones that I use :) -- e.g. running unit test(s). Thus I am kind of reluctant to declare a victory yet.

To run unit tests I'm using dotnet.el. It's not perfect, and many times I've toyed with the idea of a mega submission or creating a new package. But, it works!

[easbarba]

@sebasmonia
One idea I had, more a wish to be fair, is to bring to Emacs a few essential Visual Studio/Rider features as:

• Method extract,
• Generate Constructor,
• Creating a new method referenced by a new parameter,
• Format document,
• New Classes file creation
• NuGet packages package (Guix.el is a good example)

Those features hardly will be in the scope of LSP servers, though!

I wonder if it would be better a CLI tool instead of an Emacs package.

[Mallchad]

Part of this functionality is already facilitated with packages like yasnippet and the codelens server capability that has been wired up in razzmatazz' PR omnisharp-roslyn/#1799 I think automatic method creation is probably well out of the scope of this project. Formatting document is something that emacs provides in a light way by default, mainly through indentation, but there could be a code formater from omnisharp wired up, but I don't know if that implementation actually existed to begin with.

…

On Fri, 22 May 2020 at 16:23, Alexander Barbosa ***@***.***> wrote: @sebasmonia <https://github.com/sebasmonia> One idea I had is to bring to emacs a few essential Visual Studio/Rider features as Method extract, inserting Constructor, automatically creating method as we add a new parameter, format document... I wonder if it would be better a CLI tool instead of an emacs package. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1125 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK5GWWNXRRJYHOA3Z4PW5ULRS2RI3ANCNFSM4JDROGXQ> .

[easbarba]

@Mallchad

Snippets:
I've PR yasnippets-snippets that add more snippets, clean existent ones after VS/Rider traditional snippets but its maintainer seems to be away lately.
AndreaCrotti/yasnippet-snippets#378

Format Document: Its kinda just indentation, what I mean is following .NET standards as:

• Indentation
  {get; set;} to { get; set; } or foreach (...) to foreach(...)
  or

Method(string param1, string param2, string param3, string param4, string param5)

to

Method(string param1, string param2, 
             string param3, string param4, string param5)

...

Other features that I miss in emacs are:

• Naming conventions Tips
• Refactoring Tips
• Nuget package
• .NET project scaffolding
• .csproj pretty interface UI as Guix.el

[razzmatazz]

@sebasmonia
One idea I had, more a wish to be fair, is to bring to Emacs a few essential Visual Studio/Rider features as:

• Method extract,
• Generate Constructor,
• Creating a new method referenced by a new parameter,
• Format document,
• New Classes file creation
• NuGet packages package (Guix.el is a good example)

Those features hardly will be in the scope of LSP servers, though!

I wonder if it would be better a CLI tool instead of an Emacs package.

Actually, most of the functionality you listed above has already been available in omnisharp-roslyn/omnisharp-emacs and will be available over LSP with the next omnisharp-roslyn release (my code actions PR has been merged already)

So it is closer than you think :)

[easbarba]

@razzmatazz
Awesome. It's been a perfect month, if we ignore that one problem, of course! :)