neovim lsp can not go to the defination of some syntax in the dll reference

[Haale]

If the project has a class named "Form" which in the System.Windows.Form namespace and we click the "go to the defination " context menu in vscode or vs2022, it can jump to the definiation in that namespace even for the other declared syntax in the referenced third-party dll. However,in the neovim lsp, that action fails.

error hint output when I hit the 'gd' key on the "Form":

[mezdelex]

That's a known issue that has a workaround for now.

https://github.com/Hoffs/omnisharp-extended-lsp.nvim

Add this to your mason/mason-lspconfig configuration while adding the dependency mentioned above:

    require('mason').setup()
    require('mason-lspconfig').setup({
        handlers = {
            lspzero.default_setup,
            lua_ls = function()
                lspconfig.lua_ls.setup(lspzero.nvim_lua_ls())
            end,
            omnisharp = function()
                lspconfig.omnisharp.setup({
                    handlers = { ['textDocument/definition'] = require('omnisharp_extended').handler }
                })
            end
        }
    })

ignore the lsp-zero part, is another plugin (recommended btw), but you just need the omnisharp part.

[thomaslaich]

Is there a similar package available for emacs? I tried to find one, but was not successful.

I would like to use csharp-mode and omnisharp-roslyn lsp, but run into the same problem. Currently, I'm thinking of just porting the nvim plugin omnisharp-extended-lsp to an emacs package. Then again, what is the reasoning of not solving this in omnisharp-roslyn directly?

Some related threads:

• https://github.com/emacs-lsp/lsp-mode/issues/4210
• https://github.com/emacs-lsp/lsp-mode/issues/3172

Indeed, the proposed solution in the emacs threads is to use csharp-ls instead of omnisharp-roslyn. However, csharp-ls is not available in the nix package repository for darwin (apple mac), so it is currently not an option for me either.

[mezdelex]

Hi @thomaslaich

Switching to csharp-ls you would encounter the same problem as with omnisharp since both of them require some third party workaround for the #metadata decoding that VSCode handles by itself when going to built in definitions. For csharp-ls there's this extension as well https://github.com/Decodetalkers/csharpls-extended-lsp.nvim which works exactly the same way as in how to setup the config with the respective require changes.

I'm not familiar with Emacs myself so can't help you much more. Hope this problem gets addressed as well.

[thomaslaich]

@mezdelex Thanks for the clarification 🙏