Multiple Local Targets for same LSP method?

[CalvinAllen]

In VS2022, I have a custom LSP using Microsoft.VisualStudio.LanguageServer.* interfaces, etc.

What I've come across is that Visual Studio is registering a local method for window/logMessage. Interestingly, I can register for it as well using a CustomMessageHandler, and JsonRpc seems to show that two methods are mapped (inspecting targetRequestMethodToClrMethodMap at runtime), but mine never gets called.

Will JsonRpc call multiple methods when they're mapped, or just the first? A further question may be whether Visual Studio is responding to the message and then 'doing something weird' to stop further handlers from being called?

[AArnott]

StreamJsonRpc will never dispatch a request to two methods. It will take the first match whose signature is compatible with the request. If you want to override or otherwise add your functionality to a method that already has a handler via the VS LSP library, you'll need to contact the VS LSP team to request that feature (assuming they don't already provide a means for that).

[CalvinAllen]

That's what I kinda figured after digging through it. VS doesn't have a way to hook into it, unfortunately. I'm toying with the idea of removing our usage of all the VS Language Client stuff and handling it all via JsonRpc "manually". It's a bit of work, but our backend isn't really proving language services, more that we're using it as an OOP "agent" for code reuse across IDE extensions.

Anyway, thanks for the follow up!

[tinaschrepfer]

@CalvinAllen - can you clarify what you mean by removing your usage of all VS Language Client stuff and handling it all via JsonRpc "manually"? Are you hosting an LSP server? Or are you looking for a way to develop a generic extension that works across multiple IDE platforms? If so, which platforms are you targeting and what functionality are you looking to provide?

[CalvinAllen]

Hi, @tinaschrepfer - let me try to clarify

We do host an LSP Server, which we also use across IDE platforms (VS, VSCode, JetBrains). In VS (at the very least, maybe the others), we're using the extensibility points and utilizing our LSP through a Language Client.

The interesting part is that our LSP is mostly just an out-of-proc agent that just so happens to utilize messaging LIKE an LSP. Most of the messages back and forth are custom, and we're NOT actually providing a service for a language itself.

Since the backend is still technically a proper LSP, we can still respond to standard LSP messages (window/logMessage, for example). However, in this specific case (and others), VS won't let me receive this message because its already handling it.

My point about removing "VS Language Client" stuff and handing it with JsonRpc manually is based around all those facts. I can spawn our LSP manually, set up the Rpc connection, and write the necessary handlers for our custom messages, but also handle the standard LSP messages - VS won't know its an LSP in this case (and it really doesn't need to)

Hope that helps - its a very hybrid scenario where we're using LSP, but not implementing actual language services.