Support for roslyn.nvim?

[acikgozb]

Hello, first of all let me thank you for creating such a plugin. For me, it's an amazing coincidence to encounter this because nowadays I am in the middle of switching to Nvim from Rider for C# development.

While I was searching for LSP's, I first used omnisharp but then later on found out that it is a bit slow in large projects. And when I searched for it, I saw other people mentioning the same as well.

Then I found out about roslyn.nvim which seems faster than omnisharp.

Right now I'm using roslyn.nvim along with a manual setup of netcoredbg, but the basic configuration of netcoredbg results in a really sub-optimal debugging experience compared to what this plugin provides.

So my question is, is it possible to plug different LSP's to this plugin?

I'd love to use this with roslyn.nvim and have a nice LSP along with a much, much better debugging experience.

I can work on it but I'd probably need some help regarding where to touch (if its possible of course).

[iabdelkareem]

Hello, Thank you so much. I'm glad you find the plugin useful. You're right omnisharp is generally slow, especially when dealing with big solutions; it's also now thought of as a legacy after the newer LSP powering roslyn.nvim was developed. I actually learned about this new LSP fairly recently from someone on Reddit.

I looked into it, and it seems possible to integrate the plugin with it while retaining the same features. However, it's a big, breaking change because the new LSP isn't backward compatible with Omnisharp.

I'll start working on integrating it into the plugin soon, I hope. Probably I'll roll out the features gradually, as it'll be hard to migrate everything in one patch, but definitely in the first release I aim to include the code runner and debugger support.

It's great that you want to help. I'd love to get some extra hands. What I'm thinking about to move forward with this is:

• Suggest and implement the installation of the new language server in mason.nvim The reason is that mason.nvim is a great plugin that handles the installation and updates of almost every language server, debugger, and other tools.
• Provide opt-in option to attach the new language server instead of Omnisharp to buffers, and disable csharp.nvim features that don't support it at the moment.
• Support the endpoint(s) that provide solution information in order to run the debugger.

[iabdelkareem]

I tried to integrate the new roslyn LSP but can't get it to work. I pushed my attempt to this PR. Please have a look if you wish to contribute and let me know if you managed to get it to work.

[acikgozb]

Thanks a lot for the draft! Really appreciated.

I'm looking into it, it might take some time though, can barely find some spare time to work on things. Will let you know when I have some updates 👍

[BurkeStrang]

Have you seen this repo built off Roslyn? Maybe it would help? https://github.com/jmederosalvarado/roslyn.nvim

[iabdelkareem]

@BurkeStrang Yes I saw it. For some reason I never managed to get roslyn.nvim plugin to work either.

[BurkeStrang]

@iabdelkareem Interesting I had a similar experience as well but I am new to neovim. I assumed it was something I was doing wrong. I know in order to use the c# dev kit in vscode I had to sign in with my visual studio credentials.

[Issafalcon]

@iabdelkareem - I spent a bit of time trying to do what you've been doing in this plugin (nice work by the way!), but I never followed through because I was working on a couple of other plugins and they took up my "plugin dev" time.

My plan was to make several related, but separate plugins that could all be pluggable modules onto a "base" csharp-in-neovim plugin with common functionality (UI elements, pickers etc.).

As a suggestion, based on the concept above, you could take certain features or groups of features in Rider and VS IDE's and split them out into separate smaller plugins for Neovim.

For example, if you split out the functionality around selecting launch profiles, running and debugging (i.e general dotnet CLI functionality), into one plugin, and all the LSP related stuff into another, you could keep the separation of concerns, and allow users to optionally use something else for the LSP side (your LSP wrapper functions on top of omnisharp or roslyn.nvim, or csharp_ls etc.)

I say this selfishly, because I use roslyn.nvim, but I'd really like to have some of the features like selecting launch profiles and debugging that this plugin also offers.

[iabdelkareem]

Thank you for your feedback, @Issafalcon ! I'm really happy to hear that you find the plugin useful. 😊 I actually had a similar idea during development: offering a range of optional functionalities that aren't necessarily dependent on one another. Instead of creating several smaller plugins, however, I chose to consolidate everything into one plugin with various opt-in/out features. This design allows users to toggle individual features on or off as needed.The goal was also to have general features, such as the code runner and debugger, independent from omnisharp. However, I see that I didn't follow this goal, and those features depend on having Omnisharp.

It should be simple to enable plugin users to use the code runner and debugger without having omnisharp and without using the LSP feature of the plugin (which can be turned off by setting enable = false in the config) by implementing a fallback for the workspace-information feature to use filesystem lookup instead of calling o#/projects to get the list of projects if it can't find omnisharp attached to the current buffer. I'll try to find time to implement this feature this week.

[iabdelkareem]

The plugin now supports roslyn.nvim. Thanks to @jonny64bit