Automatic Update / Management of Runtimes - Breaking 3.0.0 NET Install Tool Change

[nagilson]

Scenario Today

The dotnet.acquire API for downloading a local .NET runtime is designed in such a way that it:

• Always downloads the latest runtime of the specified major.minor
• Will use existing local installs it's already created if they exist
• Shares installs across extensions
• Always checks for a runtime update before doing anything, which requires pinging the releases.json manifest

The time to ping the releases.json manifest varies and is generally short but for the worst case of users it can take many seconds. (7 seconds for the percentile of 5% worst, 16 percent for the top 1%) - This runtime is needed to resolve any C#DK dotnet logic for code written in C# like the language server processes.

We have decided to pivot for the new version.

Breaking Change for 3.0.0

The dotnet.acquire API will still download the runtime of the major.minor, but it will not check for updates every single time. The .NET Install Tool will periodically try to update and replace that runtime.
We will provide the option forceUpdate : boolean = false in the context API object call to revert to the prior behavior.

The update check will now run sometime (Say, 5 minutes) after VS Code startup to prevent slowdown of other essential components, unless the force mode is used. The check will run based upon the update schedule of .NET and within the confines of the proper SDL update requirements, which we have discussed with the security team. A message should be displayed if the user has not restarted code within some time to receive the update.

The older runtimes will be uninstalled if they are no longer in use to prevent deleting the runtime from under other extensions, and only upon the next time when a newer runtime is installed. Typically, this would happen upon the next session.

The dotnet.findPath API will become aware of local .NET Runtimes. Those runtimes will also become managed and automatically update. This feature will be disable-able in the lookup via a flag disableLocalLookup : boolean = false in the API call's context object. We do not plan on giving extensions an option to pin a version where we would not try to auto-update it. Callers would not need to change to rely on this behavior if they are calling findPath unless they always want the latest runtime no matter what.

This design decision I believe was an artifact of the prototype.

cc @JakeRadMSFT @claudiaregio @baronfel @blowdart @lifengl @dibarbet

[dibarbet]

The dotnet.findPath API will become aware of local .NET Runtimes. Those runtimes will also become managed and automatically update. This feature will be disable-able in the lookup via a flag disableLocalLookup : boolean = false in the API call's context object.

Local .NET runtimes being ones from the global.json path? Or local in some other way?

Otherwise generally the proposal seems reasonable to me.

[nagilson]

Great feedback - Local as in the ones managed by the extension and installed by it. Global.json path support should be added, though I didn't include that here and am not assuming that will be added yet as of this issue. The local runtimes managed by the extension would get updated without intervention from the calling extensions, so it wouldn't remain in an out of date state like this.

[nagilson]

In the case of a break due to the runtime and an update is required, I imagine extensions would temporarily add the forceUpdate option which would also apply to the local paths from findPath. However, findPath can accept a min runtime patch version, so I dont think that is necessary in hindsight.