LSP - 'textDocument/publishDiagnostics' to a virtual editor

Question

LSP - 'textDocument/publishDiagnostics' to a virtual editor

Sajith 66

I am working on a Visual Studio extension that

Opens Code editors using IVSUIShell.CreateDocumentWindow.
Implements a Langauge Server (LSP) which is associated to these code editors

'textDocument/publishDiagnostics' that are sent from Language Server to these code editors are not working. (Errors sent are not getting added to error list).

But the errors sent from Language Server for local files work fine and the errors get added to error list.

Seems there is an issue when the errors are for a virtual document.

2 answers

Your answer

Answer 1

It seems that you are encountering an issue with the textDocument/publishDiagnostics method when working with virtual documents in your Visual Studio extension. While errors from local files are being processed correctly and added to the error list, the same does not occur for virtual documents.

This behavior may stem from the fact that support for Language Server Protocol (LSP) in Visual Studio is designed to work primarily in open folder/file scenarios. If your virtual documents are not being treated as standard documents by the LSP implementation, this could lead to the diagnostics not being published correctly.

To troubleshoot this issue, consider the following steps:

Ensure Proper Document Handling: Verify that your virtual documents are being recognized correctly by the LSP and that they are associated with the appropriate content type.
Check LSP Implementation: Review your implementation of the language server to ensure that it correctly handles diagnostics for virtual documents. You may need to adjust how diagnostics are published or how the virtual documents are registered.
Debugging: Utilize debugging tools to trace the flow of diagnostics from the language server to the Visual Studio environment, checking for any discrepancies in how virtual documents are processed compared to local files.
Consult Documentation: Look into the Visual Studio extensibility documentation for any specific notes regarding the handling of virtual documents with LSP.

If the issue persists, consider reaching out to the Visual Studio community or forums for additional support, as there may be others who have encountered similar challenges with virtual documents and LSP.

Answer 2

Susmitha T (INFOSYS LIMITED) 1,305 Microsoft External Staff

Thanks for reaching out!

When textDocument/publishDiagnostics messages are received by the Visual Studio LSP client, the diagnostics are normally routed through the Error List and editor Squiggle providers using the document URI as a key.

If your editor window hosts a virtual document (for example, a file opened via IVsUIShell.createDocumentWindow with an in-memory buffer and no actual file path), Visual studio doesn't know how to associate the diagnostics with that buffer.

Since the URI does not map to a real file on disk or to a workspace-registered text buffer, the diagnostics are silently ignored.

To enable diagnostics:

Register the virtual document's text buffer with the visual studio LSP Client so it's recognized as part of the workspace, or
Use a temporary (shadow) file with a valid file:// path or
Manually forward diagnostics to the error list using visual studio "ErrorListProvider"

Reference: Language Server Protocol Overview - Visual Studio (Windows) | Microsoft Learn

Let me know if you need any further help with this. I will be happy to assist.
If you find this helpful, Kindly mark the provided solution as "Accept Answer", so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

Sajith 66 Reputation points

2025-11-10T09:03:07.4666667+00:00

Hi @Susmitha T (INFOSYS LIMITED) ,

Thanks a lot for answering. Could you kindly elaborate this -

"Register the virtual document's text buffer with the visual studio LSP Client so it's recognized as part of the workspace"

I think this will be the most relevant work around in my case. Can you kindly provide details on how to register virtual document? Will registering virtual document ensure that the errors are routed correctly?

When I debugged this-

Microsoft.VisualStudio.LanguageServer.Client.Utilities.GetLocalUri

is what parses the virtual document uri incorrectly. In my case the virtual document uri is in format

mycompany:document1

And GetLocalUri() parses this to -

C:\work\ExtApp1\bin\Debug\2022\document1
Sajith 66 Reputation points

2025-11-10T09:19:54.6233333+00:00

Hi @Susmitha T (INFOSYS LIMITED) ,

To add to this- I am already setting ContentType of virtual document's text buffer to the content type of LSP. All other LSP messages work fine like 'textDocument/didOpen', 'textDocument/hover' etc. Uri passed to these requests is coming correct as 'mycompany:document1' which is id with which the document is opened (pszMkDocument parameter of IVsUIShell.CreateDocumentWindow)
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Susmitha T (INFOSYS LIMITED) 1,305 Reputation points Microsoft External Staff

2025-11-10T12:25:33.59+00:00

Thanks for reaching out!

The issue occurs because Visual studio's built-in diagnostic handling expects file:// URIs when processing textDocument/publishDiagnostics. even though your virtual document is correctly opened, and all the other LSP messages (e.g., didOpen, hover) work fine, the diagnostic provider uses Utilities.GetLocalUri(), which fails to resolve your custom URI scheme (mycompany:). As a result, diagnostics are not mapped to the open buffer or the error list.

Resolution: Keep your existing LSP setup but change the only document URI used for diagnostics to a file-based URI (e.g., file:///C:/Temp/VirtualDocs/document1.myext).
Use this same URI for textDocument/didOpen and publishDiagnostics so that the visual studio can resolve it as a valid local file.
This ensures diagnostics are routed correctly to the error list and editor squiggles without affecting other LSP requests.

In Summary: Your LSP setup is correct - only the diagnostic URI scheme needs to be changed to a file:// format or visual studio to display diagnostic properly.

Let me know if you need any further help with this. I will be happy to assist.
If you find this helpful, Kindly mark the provided solution as "Accept Answer", so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.
Sajith 66 Reputation points

2025-11-11T12:19:12.53+00:00
Hi @Susmitha T (INFOSYS LIMITED) ,

Thanks for looking into this issue.

I could not implement this solution -

"Resolution: Keep your existing LSP setup but change the only document URI used for diagnostics to a file-based URI (e.g., file:///C:/Temp/VirtualDocs/document1.myext)."

as the document Uri is tied to many other functionality in the product and cannot be changed.

Instead I tried implementing -

Manually forward diagnostics to the error list using visual studio "ErrorListProvider"

This works fine except that once the error is added to error list and then later removed, it is not getting removed from the document statusbar -

Is there a way to manually remove this from the statusbar when error is removed from errorlist ?
Susmitha T (INFOSYS LIMITED) 1,305 Reputation points Microsoft External Staff

2025-11-12T07:09:58.8933333+00:00

Hi, thanks for reaching out!

Since your diagnostics are manually published, Visual Studio doesn't auto-sync the status bar count.
To fix this, ensure your ErrorListProvider tasks use TaskCategory.Intellisense, and call Task. clear () +Refresh () when clearing errors,s, or force a global refresh via IVsTaskList2.RefreshAllProviders().

Let me know if you need any further help with this. I will be happy to assist.
If you find this helpful, Kindly mark the provided solution as "Accept Answer", so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.
Sajith 66 Reputation points

2025-11-12T10:36:48.7833333+00:00
Hi @Susmitha T (INFOSYS LIMITED) ,

I have tried the following but this did not work. Error count on the status bar is not getting updated.

Have set taskcategory to VSTASKCATEGORY.CAT_CODESENSE. (There is no IntelliSense category on that enum)

IVsTaskItem (or IVsTaskItem2, IVsTaskItem3) does not have Clear or Refresh methods.

Have tried calling IVsTaskList2.RefreshAllProviders(), but error count on status bar is not getting updated
Susmitha T (INFOSYS LIMITED) 1,305 Reputation points Microsoft External Staff

2025-11-13T08:35:44.0433333+00:00

Hi,

After exploring all available options, the only way to update Visual Studio’s built-in status bar error count is by publishing diagnostics through Visual Studio’s recognized diagnostic pipeline (e.g., LSP using file:// URIs). If this approach is not feasible, there is no supported API to modify the status bar count. In such cases, implementing a custom status indicator is the recommended and supported alternative, particularly when working with virtual documents or custom URIs.”

Let me know if you need any further help with this. I will be happy to assist.

If you find this helpful, Kindly mark the provided solution as "Accept Answer", so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.
Susmitha T (INFOSYS LIMITED) 1,305 Reputation points Microsoft External Staff

2025-11-17T08:08:23.3333333+00:00

"Hope you're doing well. We're following up on the thread. Please let us know whether the issue persists or has been resolved. If the issue has been resolved, kindly mark the response as "answered". We'll close this thread by 19th November, so we are hoping for your reply before that".
Susmitha T (INFOSYS LIMITED) 1,305 Reputation points Microsoft External Staff

2025-11-19T05:47:05.63+00:00

Since the thread has been open for a considerable time, we will be proceeding to close the thread. If the issue persists or reoccurs, please feel free to raise a new thread. We’ll be happy to assist you further.

Share via

LSP - 'textDocument/publishDiagnostics' to a virtual editor

2 answers

Your answer