vscode-csharp - new lsp server

[titouancreach]

Language server

vscode-csharp

Requested feature

https://devblogs.microsoft.com/visualstudio/announcing-csharp-dev-kit-for-visual-studio-code/

Microsoft released a new version of vscode extension for C# on 06/06/2023.

by a new fully open-source Language Server Protocol (LSP) host, creating a performant, extensible, and flexible tooling environment that easily integrates new experiences into C# for VS Code

Here is the process that run instead of Omnisharp.dll:

79855 ?? Ss 0:41.46 dotnet /Users/redacted/.vscode-insiders/extensions/ms-dotnettools.csharp-2.0.206-darwin-arm64/.roslyn/Microsoft.CodeAnalysis.LanguageServer.dll --logLevel Information --starredCompletionComponentPath /Users/redacted/.vscode-insiders/extensions/ms-dotnettools.vscodeintellicode-csharp-0.1.9-darwin-arm64/components/starred-suggestions/node_modules/@vsintellicode/starred-suggestions-csharp --extension /Users/redacted/.vscode-insiders/extensions/ms-dotnettools.csdevkit-0.1.83-darwin-arm64/components/roslyn-visualstudio-languageservices-devkit/node_modules/@microsoft/visualstudio-languageservices-devkit/Microsoft.VisualStudio.LanguageServices.DevKit.dll --sessionId af60e874-a2e7-41d4-8854-b6e1646b9f601686121999271 --telemetryLevel all

other resources:

• https://github.com/dotnet/vscode-csharp
• An update on the LSP-powered, Visual Studio Code C# Extension dotnet/vscode-csharp#5708

Other clients which have this feature

No response

[glepnir]

I just see this (powered by OmniSharp) .looks like also based on omnisharp?

[titouancreach]

I'm not really sure. The repo is confusing.

In this commit: references to omnisharp has been removed:
dotnet/vscode-csharp@08682dc

In the process I put in the original post, the process is now called LanguageServer.dll and not Omnisharp.dll
But I'm not sure

[mdarocha]

It seems the new dll is part of a new internal Roslyn LSP server:

• Announcement: A roadmap update on the VS Code C# extension dotnet/vscode-csharp#5276 (comment)
• Merge internal fork of LSP tools back into Roslyn dotnet/roslyn#68461.

[bjorkstromm]

Please be aware that it's not really clear whether or not it's allowed to use the new LSP server outside of VS family editors.

dotnet/roslyn#68463

[lawrence-laz]

According to this comment, the intent is that the new LSP server will be part of roslyn and share the same license (MIT), though.

Hopefully this will get sorted out soon.

[ChimpSpin]

Looks to be sorted out. dotnet/roslyn#68942

[jmederosalvarado]

has anyone tried to manually configure the new LSP in Neovim? would the license allow us to integrate it in this repo?

[lawrence-laz]

has anyone tried to manually configure the new LSP in Neovim? would the license allow us to integrate it in this repo?

The license is MIT, so there should be no issues there.

I have not tried to set it up manually though.

[maxle5]

For anyone interested, I was able to set it up manually with this config (using the new LSP installed via the vscode extension):

local lsp_configurations = require('lspconfig.configs')
if not lsp_configurations.roslyn then
    lsp_configurations.roslyn = {
        default_config = {
            name = 'roslyn',
            cmd = {
                "dotnet",
                "c:\\users\\max\\.vscode\\extensions\\ms-dotnettools.csharp-2.0.346-win32-x64\\.roslyn\\Microsoft.CodeAnalysis.LanguageServer.dll",
                "--logLevel=Information",
                "--extensionLogDirectory=c:\\temp\\"
            },
            filetypes = { 'cs' },
            root_dir = require('lspconfig.util').root_pattern('*.sln'),
        }
    }
end

local on_attach = function(client, bufnr)
    -- keymaps
end

require("lspconfig").roslyn.setup({
    on_attach = on_attach,
})

What seems to work:

• Renaming symbols
• Applying code actions
• Code formatting
• Go to definition
• Loading "simple" nvim-cmp LSP suggestions
  • keywords
  • local symbols
  • class properties, etc.

What doesn't work for me:

• Diagnostics or code errors
• Loading "complex" nvim-cmp LSP suggestions
  • symbols from other namespaces
  • etc.
• Applying nvim-cmp suggestions causes the LSP to crash with the following error:

"[LanguageServerHost]System.ArgumentException: The changes must not overlap. (Parameter 'changes')...

[tilupe]

@maxle5 thank you for this input. I could also get it to run, but it was barely usable. For me it seemed that only stuff within the same file worked, but even this wasn't reliable.
I understand to little about language servers, but it seems weird, that it works so badly when this is already usable in vs-code...
I hope there aren't any dependencies to the other tools of Microsoft which aren't open source.

[AnhQuanTrl]

Really love to have this. I think OmniSharp will be deprecated soon. A lot of issues in the github repo have not been resolved for months (for example auto importing not working).

[maxle5]

Just an update, the manual config I posted above no longer works at all... It appears that a change was made to the LSP to use "named pipes" instead of stdout and I can no longer attach to the LSP from nvim.

This is not really something I am familiar with, so if anyone has any experience with this, I could really use some help!

[boost1231]

@maxle5

I have gotten around the pipes issue by making the below modification to program.cs in the Roslyn repo: https://github.com/dotnet/roslyn/blob/main/src/Features/LanguageServer/Microsoft.CodeAnalysis.LanguageServer/Program.cs#L119

    // var (clientPipeName, serverPipeName) = CreateNewPipeNames();
    // var pipeServer = new NamedPipeServerStream(serverPipeName,
    //     PipeDirection.InOut,
    //     maxNumberOfServerInstances: 1,
    //     PipeTransmissionMode.Byte,
    //     PipeOptions.CurrentUserOnly | PipeOptions.Asynchronous);

    // Send the named pipe connection info to the client 
    //Console.WriteLine(JsonConvert.SerializeObject(new NamedPipeInformation(clientPipeName)));

    // Wait for connection from client
    // await pipeServer.WaitForConnectionAsync(cancellationToken);

    using var stdIn = Console.OpenStandardInput();
    using var stdOut = Console.OpenStandardOutput();

    // UTF8Encoding utf8 = new UTF8Encoding();
    // var stuff = "Starting the LSP";
    // var bytes = utf8.GetBytes(stuff);
    // stdOut.Write(new ReadOnlySpan<byte>(bytes));

    // var server = new LanguageServerHost(pipeServer, pipeServer, exportProvider, languageServerLogger);
    var server = new LanguageServerHost(stdIn, stdOut, exportProvider, languageServerLogger);
    server.Start();

That being said, based on the PR you linked, it sounds like they found that a named pipe offers advantages to standard out. If that is the case, I suppose we have to open a feature request to Neovim to allow named pipe communication? Looking at the code this did not look like an option at the moment.

After getting the Roslyn Language Server to attach, I also had to make a "solution/open" notification request to the Language Server in order for things like "Go To Definition" to work. "solution/open" does not appear to be part of the LSP spec. Maybe we could make a custom handler for the "initialize" request response that would fire back a "solution/open" request?

I am currently working on the Diagnostics. In order to get them running at all, I had to use the development release of Neovim. It has support for the textDocument/diagnostic request. It seems to fire it off after it makes textDocument/didChange requests. The diagnostics request seems to work fine given it has the correct text of a ".cs" file. However, that was not always the case. The Language Server's copy of the ".cs" file gets corrupted. This appears to be happening in trying to keep the ".cs" file up to date with the textDocument/didChange requests. I'm trying to figure out if the requests are not being issued properly by Neovim or if they are not being handled properly by the server.

[boost1231]

Looks like an issue was opened up in the Roslyn repo to address the issue with handling textDocument/didChange notifications: dotnet/roslyn#70392

To continue testing, I applied this patch locally to the Roslyn LanguageSever code:

diff --git a/src/Features/LanguageServer/Protocol/Handler/DocumentChanges/DidChangeHandler.cs b/src/Features/LanguageServer/Protocol/Handler/DocumentChanges/DidChangeHandler.cs
index 6a8f66ffbfc..a09b9463de2 100644
--- a/src/Features/LanguageServer/Protocol/Handler/DocumentChanges/DidChangeHandler.cs
+++ b/src/Features/LanguageServer/Protocol/Handler/DocumentChanges/DidChangeHandler.cs
@@ -4,7 +4,6 @@

 using System;
 using System.Composition;
-using System.Linq;
 using System.Threading;
 using System.Threading.Tasks;
 using Microsoft.CodeAnalysis.Host.Mef;
@@ -33,11 +32,12 @@ public DidChangeHandler()
         {
             var text = context.GetTrackedDocumentSourceText(request.TextDocument.Uri);

-            // Per the LSP spec, each text change builds upon the previous, so we don't need to translate
-            // any text positions between changes, which makes this quite easy.
-            var changes = request.ContentChanges.Select(change => ProtocolConversions.ContentChangeEventToTextChange(change, text));
+            foreach (var change in request.ContentChanges)
+            {
+                var textChange = ProtocolConversions.ContentChangeEventToTextChange(change, text);
+                text = text.WithChanges(textChange);
+            }

-            text = text.WithChanges(changes);

             context.UpdateTrackedDocument(request.TextDocument.Uri, text);

Although I have not done extensive testing yet, Go To Definition, Find References, Diagnostics, Completions, etc. seem to be working for me.