[SUGGESTION] Can we get rid of ".NET Install Tool for Extension Authors"? since it makes this extension unuseable

[NewUserHa]

Describe the feature you'd like

The .NET Install Tool for Extension Authors extension keeps throwing

Downloading the .NET Runtime.
Downloading .NET version(s) 7.0.9 ...................................................................................................................... Error!
Failed to download .NET 7.0.9:
.NET installation timed out.

 Error!
.NET Acquisition Failed: Installation failed: Error: .NET installation timed out.

And that makes this extension totally not working/useless (since it can't start).

There're several similar issues reporting 'failed to download', those are opened for months in that "Install Tool" repo but still remain unsolved or 0 replay or not triaged, eg dotnet/vscode-dotnet-runtime#230, dotnet/vscode-dotnet-runtime#939, #138 (the workaround in this issue dont work) and etc (these are not all).
That "Install Tool" seems to lack maintenance seriously and is also badly rated in the vscode marketplace.

May this extension get rid of that "Install Tool" extension? and use auto-detect or let the users choose dotnet? since this extension is for developers.
just like how any other language in vscode like go or python chooses their binaries, by users.

Alternatives considered

No response

Environment Information

No response

[AArnott]

We have a potential fix queued for publishing as a prerelease next week.

[AArnott]

We have no plans to remove the dependency on the extension that can install .NET runtimes. But we did make a fix in this week's release that we hope will dramatically improve on the experience (by not using the extension for many users).

[ManfredLange]

@AArnott

Why are we forced to have an extension installed that nobody asked for?

We have a dev container that we definitely do not use for extension development. We are very particular about the .NET runtime we want to be present in that dev container. We do this to minimize the variability that otherwise can cause the well-known "works on my machine" effect. We believe this is a quality practice that helps with developer experience (DX) and with developer productivity.

We do not want any other party, e.g. Microsoft, to overwrite that decision and install whatever .NET runtime they deem the right one for us. In essence, by falling back into the dark ages of Microsoft behavior and force-feeding users with what you think is the right choice, you force us to go back on our quality and productivity practices

Not a good move at all, but perhaps I am overlooking something here ....

[AArnott]

VS Code offers extensions the ability to depend on other extensions, and C# Dev Kit depends on the .NET runtime acquisition extension for getting the .NET 7 runtime that C# Dev Kit itself requires. This runtime has no impact on your own code that you build and run. It's only used by C# Dev Kit (and possibly other VS Code extensions that similarly require the .NET 7 runtime).

The alternative to this would be to include the .NET 7 runtime in the C# Dev Kit extension itself. This would remove the dependency on another extension, but it wouldn't reduce the disk footprint, since we need the runtime either way. And it wouldn't impact what runtimes can influence the code you care about, because neither option has any impact on that. Either way, the runtime is in a private, out of the way location that only impacts a VS Code extension -- not your code.
But by relying on another VS Code extension to acquire the runtime, we gain the ability to share that runtime with other VS Code extensions (e.g. the C# extension), reducing overall download time and disk space required on your machine or in your container.

So you see, this isn't about Microsoft force-feeding customers. This is essentially like a C++ program installing the VC runtime as a dependency, except that instead of installing it in windows\system32, we're installing it next to the app that needs it so that it's isolated, having 0 negative impact on the rest of your system.

[AArnott]

I'll add that the recent change with which I closed this issue makes C# Dev Kit first try to use a .NET 7 runtime that it can already find on the box (or your container, in your case) before installing a private copy. That can make your first use a little faster because we don't download an extra copy. We'll still fallback to installing a private, isolated .NET 7 runtime if we can't find a compatible one already on the box.

In the near future though, largely because of the negative impression so many customers have of this pattern (which IMO is partly due to misunderstanding what it is and how it works), and also because of reliability problems with downloading and unzipping an app-local runtime for the extension, we plan to switch our fallback plan to installing a machine-global runtime. That is, if you don't already have .NET 7 installed, we'll install it globally, requiring elevation (n/a in a container, I think). I have mixed feelings about this, because like you, I'd rather we not mess with the machine environment. But we really need to improve reliability and this is the best way we know to get it. I can explain more if you're interested in this.

[NewUserHa]

we plan to switch our fallback plan to installing a machine-global runtime.

Why can't developers take care of their environment by themselves? Adding another black box messing with the env will confuse new beginners even more I think.

This is only a vscode extension (even not a customer/end-user extension) and ppl want just feature "Package Management" and etc. from this extension.

If you want to make new beginners feel better on installing .NET or installing extensions for vscode, in my opinion, a new independent extension can be better. it will let the users choose whether to install the extension. (because all other language extensions don't do this)

[AArnott]

Why can't developers take care of their environment by themselves?

They certainly can. If they already have .NET 7 installed, the plan is to reuse it. If they don't, they'll be told it's required to run the extension, and we'll assist in installing it or the user can opt to install it themselves.

If you want to make new beginners feel better on installing .NET or installing extensions for vscode, in my opinion, a new independent extension can be better

Can you elaborate on this? What would this new extension do? We have C# Dev Kit and the .NET acquisition extension as two distinct extensions, so do you mean we should subdivide it further into 3 somehow?

[NewUserHa]

They certainly can. If they already have .NET 7 installed, the plan is to reuse it. If they don't, they'll be told it's required to run the extension, and we'll assist in installing it or the user can opt to install it themselves.

If it's "if .net7 not found then ask if need help to install" then it looks good to me.

Can you elaborate on this? What would this new extension do? We have C# Dev Kit and the .NET acquisition extension as two distinct extensions, so do you mean we should subdivide it further into 3 somehow?

It was for "if forcing installing globally without asking". Then it could be a bootstrap extension for beginners addition with some tutorials maybe. And non-beginners also can utilize it via a URL in the readme of this extension rather than a bundle if they don't want to install runtime/sdk manually.
But if it asks before to help install then probably ppl is ok with a dependency of install helper.

[AArnott]

Yes, we have a walkthrough that will help users understand what is required and a button that the user may choose to click to start the .NET runtime/SDK installer.