Nimblesite / Nimblesite/SharpLsp
[Bug]: C# Sidecar Initialization Fails Permanently When Opening a Projectless Directory
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 132
- Forks
- 5
- Avg merge
- 6h 24m
- Merged PRs (30d)
- 27
Description
What happened?
Description
When opening a projectless directory in VS Code (like an empty folder or the Desktop) and subsequently creating/opening a .cs file, SharpLsp fails to provide any language features (autocomplete, diagnostics, etc.).
Root Cause
When a folder is opened in VS Code, the Rust host eagerly sends a workspace/open request to the sidecars with the directory path. The C# sidecar attempts to find a .sln or .csproj. Upon finding nothing, it delegates to OpenProjectlessAsync(path) in an attempt to load it as a single-file app.
However, because the path is a directory and not a .cs file, OpenProjectlessAsync correctly rejects it and returns a Failure. Because the workspace/open initialization failed, the Rust host skips starting the health monitor for the sidecar, and the C# sidecar gets stuck in a permanent uninitialized state (_solution = null).
Any .cs files opened afterwards have their edits stashed infinitely in UpdateDocumentTextAsync, rendering the extension broken for that session.
Solution
This can be fixed cleanly inside the C# sidecar without requiring changes to the Rust host's eager-loading logic:
- Defer Initialization on Directories: In
WorkspaceManager.OpenCoreAsync, iftarget is nullbut the path is a directory, set a flag (_isProjectlessDirectory = true) and returnSuccess. This allows the Rust host to successfully boot the sidecar and start the health monitor. - Lazy Load on First File: In
WorkspaceManager.UpdateDocumentTextAsync, check if_isProjectlessDirectoryis true. If it is, intercept the first.csfile opened, clear the flag, and invokeOpenProjectlessAsync(filePath)with the precise file path before acquiring the_solutionMutationLock.
This restores the single-file mode logic exactly as originally designed, building the ad-hoc workspace around the .cs file as soon as the user opens it.
Steps to reproduce
- Install the SharpLsp extension in VS Code.
- Go to File -> Open Folder... and select a completely empty directory (e.g., a new folder on your Desktop) that does not contain any
.csprojor.slnfiles. - Once the folder is open, create a new file named
test.cs. - Type some C# code into the file (e.g.,
Console.WriteLine();). - Expected behavior: The extension provides autocomplete, IntelliSense, and diagnostics for the single file.
- Actual behavior: No suggestions or diagnostics appear, and the extension fails to parse the file because the sidecar initialization has died silently in the background.
Component
C# sidecar (Roslyn)
Language
C#
SharpLsp version
0.16.0
Editor & OS
VS Code, Windows
Relevant logs
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in WorkspaceManager.OpenCoreAsync and UpdateDocumentTextAsync, then reproduce by opening an empty VS Code directory and creating a .cs file. Trace the projectless-directory state and the first document update. Done means the C# sidecar initializes successfully, loads the file lazily, and provides autocomplete and diagnostics.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp, rust, vscode
- Domain
- tooling
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 74/100