Nimblesite / Nimblesite/SharpLsp

[Bug]: C# Sidecar Initialization Fails Permanently When Opening a Projectless Directory

Open
#193 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug cluster:csharp-single-file critical
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:

  1. Defer Initialization on Directories: In WorkspaceManager.OpenCoreAsync, if target is null but the path is a directory, set a flag (_isProjectlessDirectory = true) and return Success. This allows the Rust host to successfully boot the sidecar and start the health monitor.
  2. Lazy Load on First File: In WorkspaceManager.UpdateDocumentTextAsync, check if _isProjectlessDirectory is true. If it is, intercept the first .cs file opened, clear the flag, and invoke OpenProjectlessAsync(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
  1. Install the SharpLsp extension in VS Code.
  2. Go to File -> Open Folder... and select a completely empty directory (e.g., a new folder on your Desktop) that does not contain any .csproj or .sln files.
  3. Once the folder is open, create a new file named test.cs.
  4. Type some C# code into the file (e.g., Console.WriteLine();).
  5. Expected behavior: The extension provides autocomplete, IntelliSense, and diagnostics for the single file.
  6. 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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.