Skip to content

Automatically acquire the .NET 10 runtime via the .NET Install Tool#884

Merged
DavidObando merged 1 commit into
mainfrom
DavidObando/auto-acquire-dotnet-runtime
Jun 17, 2026
Merged

Automatically acquire the .NET 10 runtime via the .NET Install Tool#884
DavidObando merged 1 commit into
mainfrom
DavidObando/auto-acquire-dotnet-runtime

Conversation

@DavidObando

Copy link
Copy Markdown
Owner

Problem

PR #879 made the extension fail gracefully when the bundled net10.0 language server has no compatible runtime to host it: instead of a crash-toast cascade, it detects the missing runtime (via PATH and dotnet.findPath) and shows a single "Install .NET" prompt. But the user still has to go install .NET 10 by hand before the LSP works.

We already take an extensionDependency on the .NET Install Tool (ms-dotnettools.vscode-dotnet-runtime), so we can do better and just acquire the runtime for them — the same thing the C# extension does.

Change

resolveDotnetRuntime now downloads a compatible runtime on demand, mirroring vscode-csharp's DotnetRuntimeExtensionResolver.

New resolution order:

  1. A dotnet already on PATH exposing a Microsoft.NETCore.App >= 10 (no Install Tool round-trip).
  2. An existing runtime located via dotnet.findPath (greater_than_or_equal, rejectPreviews).
  3. New: a runtime acquired on demand via dotnet.acquireStatus -> dotnet.showAcquisitionLog -> dotnet.acquire (mode: runtime, version: 10.0); dotnet.ensureDotnetDependencies is invoked on Linux.
  4. DotnetRuntimeMissingError only when acquisition truly cannot complete (e.g. offline with nothing cached or the Install Tool unavailable).

resolveDotnetRuntime now returns { dotnetPath, env } and pins the host to the resolved/acquired runtime via DOTNET_ROOT / DOTNET_MULTILEVEL_LOOKUP (same as the C# extension), so the server cannot roll forward/back onto a different runtime. serverManager merges that env overlay and the "Install .NET" prompt becomes a last resort, with updated wording noting that automatic acquisition was attempted first.

Tests

  • New dotnetRuntimeAcquire.test.ts covering the PATH fast path, the findPath hit, the acquire fallback (asserting DOTNET_ROOT pinning and the dotnet.acquire call), and both error paths (Install Tool unavailable / acquisition yields nothing).
  • Existing parser/error tests unchanged.

Verification

  • npm run test:unit -> 13 passed
  • npm run lint -> clean
  • tsc --noEmit -> clean
  • npm run compile (esbuild + server build) -> succeeds

Docs

  • README requirement now accurately describes automatic acquisition (with offline-fallback note).
  • CHANGELOG entry added.

Builds on #879 (graceful handling of a missing runtime). Instead of only
detecting a missing runtime and prompting the user to install it manually,
the extension now downloads a compatible net10.0 runtime on demand via the
.NET Install Tool's dotnet.acquire API, mirroring the official C# extension's
DotnetRuntimeExtensionResolver.

dotnetResolver.ts resolution order:
  1. Compatible dotnet already on PATH.
  2. Existing runtime located via dotnet.findPath (>=, rejectPreviews).
  3. Runtime downloaded on demand via dotnet.acquireStatus/acquire
     (mode runtime, version 10.0), with dotnet.ensureDotnetDependencies on Linux.
  4. DotnetRuntimeMissingError only when acquisition cannot complete.

resolveDotnetRuntime now returns { dotnetPath, env } and pins the server to the
resolved runtime via DOTNET_ROOT / DOTNET_MULTILEVEL_LOOKUP. serverManager merges
that env overlay; the missing-runtime prompt is now a last resort.

Adds jest coverage for the PATH / findPath / acquire / error paths and updates
the README requirement wording and CHANGELOG.
@DavidObando DavidObando merged commit 0847c48 into main Jun 17, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant