Lsp-mode: 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
[Trace - 03:03:33 PM] Received notification 'window/logMessage'. 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:

• https://github.com/OmniSharp/omnisharp-roslyn/issues/1245
• https://github.com/OmniSharp/omnisharp-roslyn/issues/1445
• https://github.com/OmniSharp/omnisharp-roslyn/issues/1521
• https://github.com/OmniSharp/omnisharp-roslyn/issues/1580

BTW this same crash appears to be happending for @sebasmonia on https://github.com/emacs-lsp/lsp-mode/issues/1108#issuecomment-545482410

[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).

[elxbarbosa]

@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 [e-mail]:


@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)

[elxbarbosa]

@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: 9f2333b1d5213f651af643ec5f2876bd987d7ab1
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

[elxbarbosa]

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.

• https://github.com/OmniSharp/omnisharp-roslyn/pull/1754

[elxbarbosa]

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.

[elxbarbosa]

For those interested the issue seems to be fixed in https://github.com/OmniSharp/omnisharp-roslyn/pull/1791.

YES!

https://github.com/hlissner/doom-emacs/issues/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:

• https://github.com/OmniSharp/omnisharp-roslyn/pull/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:

• https://github.com/OmniSharp/omnisharp-roslyn/pull/1799

[elxbarbosa]

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.

[elxbarbosa]

@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!

[elxbarbosa]

@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):

• https://github.com/OmniSharp/omnisharp-roslyn/pull/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!

[elxbarbosa]

@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 [e-mail]
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
https://github.com/emacs-lsp/lsp-mode/issues/1125#issuecomment-632780775,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AK5GWWNXRRJYHOA3Z4PW5ULRS2RI3ANCNFSM4JDROGXQ
.

[elxbarbosa]

@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.
https://github.com/AndreaCrotti/yasnippet-snippets/pull/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

``` c#
Method(string param1, string param2, string param3, string param4, string param5)

``` c#
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 :)

[elxbarbosa]

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