-
Notifications
You must be signed in to change notification settings - Fork 417
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
[LSP] languageserver not working with vim/neovim+lsp plugins #1191
Comments
There is a change that hasn't been implemented that lets null through correctly, however I don't think we're using that version of the library yet. I'm going to try and take some time this weekend and finish up my changes on the library and roll them back into omnisharp. |
Recently I switched to vim-lsp and tried the latest version of omnisharp-roslyn, and it doesn't work either. Here is the log:
|
I see a few similar errors in handling notification messages like Editor: Monaco v0.13.0
|
@patilarpith, did you figure out the issue? I am seeing similar errors as well. I guess it could be that the sln or csproj path is not set up correctly, but I am unable to fix these. Anyone have an idea? Thanks! |
@hifall Highly doubt if the error is with project setup. I picked up HelloWorld project from the Omnisharp's test-assets folder for my testing. Is there an editor plugin which uses omnisharp-roslyn in LSP mode? I've only seen plugins use the HTTP mode |
@patilarpith, have you had any progress on this? Does this System.ArgumentOutOfRangeException look like an omnisharp-roslyn issue? |
I've been using omnisharp-node-client for awhile in order to get some form of LSP working with omnisharp. It's buggy, slow, but atleast it works some of the time. Would be nice to get it working through the omnisharp server itself |
I believe most of the problems mentioned in this issue are caused by the out-dated csharp-language-server-protocol on Nuget. Therefore I hope you to merge the latest LSP library to omnisharp-roslyn, or at least make a new branch to work on this. After half a year I am so sad to see the software still refuses to work just because of some stupid negligence. I modified multiple places in the codebase to try to make the LSP mode work properly. So far the LSP mode just basically works with LanguageClient-neovim, launched, at least, and did some completion for me. This took me most of the spare time in the last week studying the code.
To build omnisharp-roslyn with csharp-language-server-protocol, clone the two repos into the same directory, and checkout v0.7.0 of csharp-lsp. Now (un)comment some lines in
Then we are done. |
Is this issue still active? I am experiencing this issue in Neovim 0.5 using the built-in LSP framework. Here is my configuration (in Lua, since that is how it must be configured): local exe = vim.fn.environ()['HOME']..'.cache/omnisharp-vim/omnisharp-roslyn/omnisharp/OmniSharp.exe'
local nvim_lsp = require('nvim_lsp')
local nvim_lsp_defaults = require('nvim_lsp/configs')
if not nvim_lsp_defaults.omnisharp then
nvim_lsp_defaults.omnisharp = {
default_config = {
filetypes = {'cache', 'cs', 'csproj', 'dll', 'nuget', 'props', 'sln', 'targets'},
root_dir = nvim_lsp.util.root_pattern('.git', '.sln') or vim.loop.os_homedir(),
}
}
end
nvim_lsp.omnisharp.setup{
cmd = (vim.fn.has('win32') == 1) and {exe, '-lsp'} or {'mono', exe, '-lsp'}
} Whenever I enter a
(The message actually is output twice.) Edit: I omitted settings that were irrelevant to the error's occurance. Edit 2: This problem has been resolved by neovim/nvim-lspconfig#296 |
I don't know about neovim's built-in LSP framework. I do use neovim 0.4.3 with the Since you are getting a "client has shut down after sending the message" error, it seems to me like the LSP server isn't running at all. Is there any way you can get the stdout/stderr output for the child process that runs the LSP server? That would likely help you debug that issue. |
@luizribeiro I am seeing that others are also having difficulty configuring OmniSharp-roslyn for Neovim's LSP framework, so I am beginning to believe it is an issue on that side of things. Thanks for the pointers! Hopefully the collective can get this one resolved. |
I did find the reason. It's a "bug" on the For now my workaround is to use like that:
Just put a A better approach is to make |
Do you have any issues with the integration between omnisharp and nvim LSP or does it work perfectly? On ale, I've been noticing that when I fix the last error on a file, |
I am experiencing exactly what you describe. I thought it might be |
Yes. This also occurs for me. I still don't understand why. Others language servers do work fine for this. Also notice with coc.nvim some time ago, but I don't use it anymore. I changed to use with nvim-lsp. |
I think it's something on omnisharp's LSP server. Maybe it's not sending a message to the client when it should be or something similar. The way to debug this would likely be to look at the messages that are exchanged between vim and the LSP server (and maybe compare it against a LSP server which you know doesn't have this issue). You can generally do this by replacing the LSP binary you are using on vim with a bash script that wraps around the omnisharp LSP server, but also writes the stdout/stderr/stdin to files that you can upload. I'm probably not going to have time to debug this in the next few days, but I think this would be the way to go. |
I have some time today so I'll give that a shot and report back. |
Do you guys have
Also as promised I've attached results for three different contexts, which should hopefully help us here.
I will look over them in the coming days but I figured I'd upload them in the meantime. |
Yes. All my configs for .NET are within this function for ZSH: function dotnet-set-vars {
DOTNET_BASE=$(dotnet --info | grep "Base Path" | awk '{print $3}')
DOTNET_ROOT=$(echo $DOTNET_BASE | sed -E "s/^(.*)(\/sdk\/[^\/]+\/)$/\1/")
export MSBuildSDKsPath=${DOTNET_BASE}Sdks/
export DOTNET_ROOT=$DOTNET_ROOT
export PATH=$DOTNET_ROOT:$PATH
# dotnet tools dir
export PATH=~/.dotnet/tools:$PATH
}
I notice this problem even with just one version installed. I'm using .NET Core 2.2.
Thanks. This will help. |
From a quick look at the logs, it seems like Could that be the issue? |
I'm not sure… However, If you're still having the issue with diagnostics not updating, can you verify I know @adelarsq also has As for why my current error might be happening, I see this message:
@adelarsq It looks like it's trying to find the dotnet version inside of the |
Appears that is trying to access two directories. Which environment variables do you have for .NET? |
I only have one: export PATH="$PATH":"$HOME/.dotnet/tools" I use that for I have a roslyn extension in the folder |
These directories exists: For some reason the paths are been merged in one. So the path isn't valid.
Is this dotnet/vscode-csharp#2369 related? |
Yeah. I notice that the first part of the path (
I don't think so… Roslynator has worked for me in VSCode and still works in If that's true, it would also explain why it can't find the Edit: I discovered a workaround. I discovered my error before was a red herring because
|
To be clear, the diagnostics update just fine for me - with the exception when I remove the very last error on the file. In those cases I need to restart the LSP. I do have I feel like we're mixing a few different issues on this issue. Should we split them into a few separate issues with more concise bug reports and close this one? |
The version I use is the prebuilt binary package downloaded from github release page, v1.30.1 omnisharp-mono.tar.gz. linux-x86_64 package behaves exactly the same. Here is the relevant configurations in my .vimrc:
And here is the relevant log when error occurs:
I noticed the key "protocolVersion", which is usually "jsonrpc" in many other LSPs. Is it the reason why LanguageClient failed to deserialize it?
Another problem causes the server crashing. I believe this is about what's been mentioned and solved in OmniSharp/csharp-language-server-protocol#75. If that's true please merge them.
Thank you for your great work.
The text was updated successfully, but these errors were encountered: