CLaSP and Language Server Public API

[333fred]

Today, the public APIs for CLaSP (Microsoft.CodeAnalysis.CommonLanguageServerProtocol.Framework) and the C#-specific LSP (Microsoft.CodeAnalysis.LanguageServer) are either not stable (CLaSP) or not public at all (C# LSP). It is not our intention for these to remain this way; Roslyn has always been an extensible and open ecosystem, and we intend to allow extending both the C# LSP, and using CLaSP to build non-C# servers (as we are already doing with Razor and other internal partners). This is a tracking issue for stabilizing these APIs and making them public.

To help drive this, we need real users of the API. CLaSP already has a few consumers inside Microsoft, including the C# server itself, as well as Razor. We also need a real-world consumer to help drive the design of the C# LSP extensibility story; to help this, I plan on making a compiler developer SDK for VS Code, similar to the one available for VS. We'll be using an ExternalAccess layer for this for now, but this consumption will help drive the API design for later public release.

This is also tracking the public API on the vscode-extension side, as that will need a way to interact with the LSP. We intend to start with a barebones "make an LSP request with a custom command type" API that is specifically not a final, stable API at this time. There have already been a couple of requests for public APIs on that repo: dotnet/vscode-csharp#5805 and dotnet/vscode-csharp#5806. @spouliot, could you elaborate on what your extension does and what data it needs access to to help us drive API design?

[spouliot]

It is not our intention for these to remain this way;

I'm very glad to hear this 😄

could you elaborate on what your extension does and what data it needs access to to help us drive API design?

The Uno Platform has its own VSCode extension that works with the current/stable (1.x) C# extension. It provides XAML (Language Server), XAML snippets, Hot Reload (for both XAML and C#) and debugging (for mobile platforms).

The keyword above is with. There's a limited, but crucial, interaction between the Uno and C# extensions. Basically in order to stay in-sync the Uno extension needs to know

• when a new project is loaded; and
• a few information about the current/active project

I posted details on how things are done today (not very important) and what information we need (most important) in dotnet/vscode-csharp#5805 (comment)

Let me know if/how we can help!

[spouliot]

@333fred now that the experimental extension API are available do you have any pointers on how I can use them to implement the feature we're missing ? thanks!

ref #68696 (comment)

[333fred]

@spouliot I don't yet. We're still in the internal prototype phase: the vscode side of the API exists, but we have not yet made the roslyn side public yet (and indeed, I'll be troubleshooting some loading issues with paths this morning). I don't know whether @dibarbet or @CyrusNajmabadi would be open to allowing Uno to prototype on the roslyn APIs yet: guys, what do you think?

[CyrusNajmabadi]

I'm ok with prototyping, with the understanding that there is zero support/contract, and that any release on any particular day may break things here for any reason. It will be on Uno to have to deal with that. We are beyond capacity with all our existing deliverables, and we cannot spare any additional resources to keep things working, nor can we let new work interfere with existing stuff in any way. :)

[333fred]

@sharwell I know you were experimenting with using ExperimentalAttribute for IDE APIs; do you think that we can use that approach with the LSP apis for now? That would also potentially allow us to remove the compilerdevelopersdk EA.

[spouliot]

@CyrusNajmabadi thanks! I understand your constraints and I'm fine with prototyping [1] using your bleeding edge binaries.

but we have not yet made the roslyn side public yet

Is the Roslyn side public now ?

[1] We'll continue to ship our releases (on marketplace) with the existing O# (not devkit) support.

[333fred]

No, it is still not public. That is why I'm asking Sam about whether he's made any progress with using Experimental

[CyrusNajmabadi]

It is not public, and my personal take is that we would not be likely to have the time to get anything public for many months.

[spouliot]

@CyrusNajmabadi I'm open to prototype with non-released code, but I do need the code to prototype with it 😄

[333fred]

I see 2 possible options:

1. Use ExperimentalAttribute. If it's available, I think this is the preferred option, as there'd be no separate DLL to reference.
2. Rename the CompilerDeveloperSDK dll to something like ExperimentalLSPAccess, and make the implementation types public.

In either case @spouliot or other 3rd parties would need to explicitly opt-in to using an experimental API, which comes with all the caveats of "we'll probably break this at some point", which I think would address Cyrus's concerns.

[francoistanguay]

Do you have an idea of when something could be made available for us to start exploring and experiment with? Thank you!

[dibarbet]

I'll be looking at this most likely in November. Finishing up some other parity issues (e.g. nuget restore) and infrastructure fixes first.