Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Regression: automatic solution discovery misses .sln/.slnx files after #9286

Aperta Adatta ai principianti
  • Qualcosa non va?
#9,808 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
84/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
csharp, typescript, vscode
Ambito
devtools

Direzione di ricerca

Inizia in src/lsptoolshost/server/roslynLanguageServer.ts, in openDefaultSolutionOrProjects() e nella ricerca di solutionUris intorno alla riga 565. Riproduci i casi di una singola soluzione e di fallback, quindi aggiungi la copertura di regressione per .sln, .slnx e più soluzioni; il lavoro è completato quando entrambe le estensioni vengono individuate e i progetti al di fuori della soluzione selezionata non vengono caricati.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

untriaged

Issue description

Automatic solution discovery in the standalone C# extension misses a workspace's single .sln file. The extension then falls back to loading every .csproj, including projects deliberately excluded from the solution. In my workspace, this causes a project-loading error and a "There were problems loading project" notification for an excluded project.

The regression was introduced by PR #9286: .slnx support, merged on May 22, 2026. The exact change is in roslynLanguageServer.ts, line 565 of merge commit d8833483c84164fe0bfb25695bb1ed8bdd395463:

- const solutionUris = await vscode.workspace.findFiles('**/*.sln', '**/node_modules/**', 2);
+ const solutionUris = await vscode.workspace.findFiles('**/*.slnx?', '**/node_modules/**', 2);

In VS Code glob syntax, ? matches one character; it does not make the preceding x optional. Therefore **/*.slnx? matches neither .sln nor .slnx.

Environment data

  • OS: Arch Linux, x86_64
  • VS Code: 1.139.0
  • C# extension: ms-dotnettools.csharp 2.160.4
  • Mode: standalone C# extension; C# Dev Kit is not installed
  • Installed .NET SDKs: 9.0.318 and 10.0.401
  • dotnet.defaultSolution: unset
  • Workspace: one .sln file under src/, containing 12 projects; one additional .csproj exists outside the solution's project list

C# logs

Relevant excerpts from the affected workspace, with project names and paths anonymized:

2026-09-24 13:09:54.782 [info] Activating C# standalone...
2026-09-24 13:09:57.655 [error] [project/open] [LanguageServerProjectSystem] Error while loading <workspace>/src/ExcludedApp/ExcludedApp.csproj: Project '../Core/Core.csproj' targets 'net10.0'. It cannot be referenced by a project that targets '.NETCoreApp,Version=v6.0'.
2026-09-24 13:09:58.460 [info] [project/open] [LanguageServerProjectSystem] Completed (re)load of 13 project(s) in 00:00:02.8283748

The framework mismatch belongs to a project that is not in the solution. The regression is that automatic discovery loads it anyway.

Steps to reproduce

  1. Use the C# extension in standalone mode, with C# Dev Kit absent or disabled and dotnet.defaultSolution unset.
  2. Open a folder containing exactly one solution, for example src/App.sln.
  3. Have at least one .csproj under that folder which is deliberately not included in App.sln. Keep files from that excluded project closed.
  4. Activate the C# extension by opening a C# file from an included project.
  5. Inspect the C# output: the extension uses project/open to load all discovered projects, including the excluded project, instead of opening the solution. If the excluded project has an incompatible project reference, a project-loading error notification is shown.

Expected behavior

The single solution is discovered and opened automatically. Only its projects and their required references are loaded. Discovery should recognize both .sln and .slnx files.

Actual behavior

The glob finds no solutions. openDefaultSolutionOrProjects() takes its zero-solutions branch and enumerates **/*.csproj, ignoring the intended solution membership.

I verified the installed 2.160.4 extension contains this pattern and that the workspace has only one solution. The same pattern is also present in the upstream source inspected during diagnosis.

Suggested fix

Use a glob that explicitly matches the two extensions:

const solutionUris = await vscode.workspace.findFiles('**/*.{sln,slnx}', '**/node_modules/**', 2);

Regression coverage should check automatic discovery with one .sln, one .slnx, and multiple solutions, and ensure projects outside the selected solution are not loaded by the fallback path.

Workaround

Setting an explicit solution path should bypass the broken discovery branch:

{
  "dotnet.defaultSolution": "src/App.sln"
}

The workaround follows from the loading code; it has not yet been applied or verified in the affected VS Code session.

Lingua principale
TypeScript
Stelle
3.1k
Fork
736
Merge medio
21h 46m
PR unite (30g)
38

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di dotnet/vscode-csharp

Tutte le issue di dotnet/vscode-csharp

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.