Skip to content

Commit 4c33899

Browse files
authored
Document breaking change: dotnet.acquire API no longer always downloads latest (#49618)
1 parent b148702 commit 4c33899

File tree

3 files changed

+80
-0
lines changed

3 files changed

+80
-0
lines changed

docs/core/compatibility/10.0.md

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -89,6 +89,12 @@ If you're migrating an app to .NET 10, the breaking changes listed here might af
8989
|-------|-------------------|--------------------|
9090
| [Environment variable renamed to DOTNET_ICU_VERSION_OVERRIDE](globalization/10.0/version-override.md) | Behavioral change | Preview 1 |
9191

92+
## Install tool
93+
94+
| Title | Type of change | Introduced version |
95+
|-------|-------------------|--------------------|
96+
| [dotnet.acquire API for VS Code no longer always downloads latest](install-tool/3.0.0/vscode-dotnet-acquire-no-latest.md) | Behavioral change | .NET Install Tool 3.0.0 |
97+
9298
## Interop
9399

94100
| Title | Type of change | Introduced version |
Lines changed: 70 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,70 @@
1+
---
2+
title: "Breaking change: dotnet.acquire API for VS Code no longer always downloads latest"
3+
description: "Learn about the breaking change where the dotnet.acquire VS Code API no longer always checks for the latest runtime version before returning a path."
4+
ms.date: 11/04/2025
5+
ai-usage: ai-assisted
6+
ms.custom: https://github.com/dotnet/docs/issues/49127
7+
---
8+
9+
# dotnet.acquire API for VS Code no longer always downloads latest
10+
11+
The .NET Install Tool Extension for VS Code provides the `dotnet.acquire` command to install a .NET runtime for VS Code extensions. Starting in version 3.0.0 of the .NET Install Tool, calling `dotnet.acquire` no longer always checks for the latest runtime version. Instead, it uses existing runtime installations and checks daily for newer versions after a configurable delay.
12+
13+
## Version introduced
14+
15+
.NET Install Tool 3.0.0
16+
17+
## Previous behavior
18+
19+
Up until version 3.0.0 of the .NET Install Tool, or prerelease version 2.4.1, calling `dotnet.acquire` always triggered a check to see what the latest runtime version was, given the VS Code client was online and didn't specify an existing path to `dotnet`. If that latest runtime wasn't available on the machine, it was installed, and the path to it was returned.
20+
21+
This runtime is used by [C# Dev Kit](https://marketplace.visualstudio.com/items?itemName=ms-dotnettools.csdevkit), C#, and other VS Code extensions, both first and third party, to run internal .NET code and processes, such as the language server host. This runtime is generally not used to run user projects, and is a private, user-folder copy on disk. It can be the runtime or aspnetcore runtime.
22+
23+
A similar command, `dotnet.uninstall` exists. Previously, that command uninstalled any .NET runtime or SDK that an extension had requested, if no other extensions depended upon that installation, and decremented the reference count. An extension depended on the installation if the extension had requested that version of .NET in the past. A reference count-based mechanism allowed uninstallation when no further dependent extensions of an install remained.
24+
25+
## New behavior
26+
27+
Starting with version 3.0.0 of the .NET Install Tool, `dotnet.acquire` no longer always checks for a newer runtime version before returning the path to a runtime that matches the `major.minor`. Instead, it uses existing runtime installations it's made and checks daily for a new runtime after `runtimeUpdateDelaySeconds`. The delay setting defaults to 5 minutes and can be changed in the VS Code Extension Settings. After this time, the prior check commences for newer runtime versions, and the new runtime is installed if needed. After this, all remaining .NET runtimes that aren't *in-use* and aren't the latest patch for a specific `major.minor`, `architecture`, and `mode` (runtime or aspnetcore runtime) combo are uninstalled automatically.
28+
29+
*In-use* means that the executable path to that .NET runtime install was:
30+
31+
- Returned by a command through the .NET Install Tool in any session of VS Code, VS Code Insiders, or other VS Code variant that has a currently live, running process. This includes but isn't limited to: `dotnet.acquire`, `dotnet.acquireStatus`, `dotnet.availableInstalls`, and `dotnet.findPath`.
32+
- Part of the `PATH` or `DOTNET_ROOT` environment variable in which VS Code is operating.
33+
34+
In addition, `dotnet.uninstall` doesn't uninstall if the install is considered to be *in-use*. This command already rejected uninstalls that were made while the `dotnet.exe` corresponding to that installation folder had a conflicting file handle that demonstrated it was running or in use. Whether it was in use was determined by trying to open the executable with `O_RDONLY` permissions or `FILE_FLAG_NO_BUFFERING` on windows, and by checking for `EBUSY`, `EACCESS`, or processes via `lsof` on Unix.
35+
36+
## Type of breaking change
37+
38+
This change is a [behavioral change](../../categories.md#behavioral-change).
39+
40+
## Reason for change
41+
42+
This change improves performance and management of the .NET runtime. It speeds up the developer loop by deferring the network call and installation time away from the launch of extensions that utilize .NET. For users in the worst 3% of networks who didn't have their own .NET runtime that matched the requirements of any extension's .NET version, the download time alone created a 9-36 second delay at startup. For the median user, this represented a 287 ms delay.
43+
44+
## Recommended action
45+
46+
If you rely on `dotnet.acquire` and want to enforce that a new runtime is used every single time, use `forceUpdate: true` in your call to `dotnet.acquire`. This is generally not recommended unless a runtime security patch, feature, or bug is dramatic enough to warrant downloading the latest runtime.
47+
48+
Example:
49+
50+
```javascript
51+
const dotnetRuntimePath = (await vscode.commands.executeCommand<IDotnetAcquireResult>(
52+
'dotnet.acquire',
53+
{ version: '9.0', requestingExtensionId, forceUpdate: true }
54+
)).dotnetPath;
55+
```
56+
57+
Make sure you don't cache or reuse any path from the .NET Install Tool without calling `dotnet.availableInstalls` again (to demonstrate that you're using the installation in a given session) if it's not in the `PATH`.
58+
59+
Continue to use `dotnet.uninstall` as you did previously to decrement the reference counts of the installs you own. However, this is less vital since uninstallation happens when the older version is replaced with the newer version.
60+
61+
Customers should avoid relying on hard-coded private runtime installations managed by the .NET Install Tool as that isn't the intended purpose of these runtimes. If you must, set the `PATH` or `DOTNET_ROOT` for your VS Code instances such that the install doesn't get cleaned up automatically.
62+
63+
## Affected APIs
64+
65+
None.
66+
67+
## See also
68+
69+
- [.NET Install Tool for VS Code](https://marketplace.visualstudio.com/items?itemName=ms-dotnettools.vscode-dotnet-runtime)
70+
- [.NET Install Tool commands documentation](https://github.com/dotnet/vscode-dotnet-runtime/blob/main/Documentation/commands.md)

docs/core/compatibility/toc.yml

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -102,6 +102,10 @@ items:
102102
items:
103103
- name: Environment variable renamed to DOTNET_ICU_VERSION_OVERRIDE
104104
href: globalization/10.0/version-override.md
105+
- name: Install tool
106+
items:
107+
- name: dotnet.acquire API for VS Code no longer always downloads latest
108+
href: install-tool/3.0.0/vscode-dotnet-acquire-no-latest.md
105109
- name: Interop
106110
items:
107111
- name: Single-file apps no longer look for native libraries in executable directory

0 commit comments

Comments
 (0)