search

microsoft / vscode-dotnettools

This is a feedback repository to capture issues logged for the C# Dev Kit and related extensions from Visual Studio Code
Other
210 stars 7 forks source link

[BUG] Extension includes other extension that may automatically install separate versions of dotnet sdk/runtime without user input #1021

Open SRNissen opened 3 months ago

SRNissen commented 3 months ago

Describe the Issue

One of the dependencies of C# Dev Kit is the .NET Install Tool

As the name implies, this tool installs dotnet

As the name perhaps does not imply: This means that C# Dev Kit may, under some circumstances, install dotnet despite never, at any point, being asked to do this.

Here, .NET Install Tool has a descriptive section:

Troubleshooting

I already have a .NET Runtime or SDK installed, and I want to use it

Try adding the requesting extension (...)

That should probably be done automatically by C# Dev Kit, which knows this extension exists, rather than by end users who get surprise behavior by a dependency they never deliberately installed.

As a separate note: Uninstalling C# Dev Kit did not remove the extraneous dotnet package, it's still hanging around on my disk so I'm going to have to go remove it manually - hoping I don't miss something else given the god-knows-which other changes this extension might have made to my machine without being asked to do it.

Steps To Reproduce

Not sure, it happened automatically.

Expected Behavior

Don't install sdks and runtimes unless the user asks for them.

Environment Information

phil-allen-msft commented 3 months ago

Seems similar in request #953

webreidi commented 3 months ago

What would it take to "remove" the version of the SDK we install for C#DK's use upon request to remove C#DK?

baronfel commented 3 months ago

The 'local' versions of the runtime are stored in 'private' extension state directory for the vscode-dotnet-runtime extension, but I don't believe these installs are keyed by the requesting extensions - this means that other extensions that also depend on vscode-dotnet-runtime may be using those runtimes, so they are not always safe to delete.

Broadly though I think @nagilson and I can work to spec out an uninstall capability for that extension and then C#DK could just call it when uninstallation occurs, and we can handle the book-keeping to see what runtimes could be removed. I expect this might become less necessary when C#DK moves to global SDK/Runtime installations, though.

nagilson commented 3 months ago

RE the users top comment, CDK already tries to find a runtime and SDK on the machine first but if it doesnt match what it needs to run then it will go ahead and download. CDK cannot run without this runtime so presumably if you install CDK you want it to be able to function whatsoever, so it would need to download the runtime. The alternative in asking for consent is going to be missed by a lot of people, then nothing will work until they consent, and so even more people will then say, why does C#DK not work/ if it needs it to run, why don't you just install for me automatically?!

What would it take to "remove" the version of the SDK we install for C#DK's use upon request to remove C#DK?

I thought we had the ability to uninstall just 1 local runtime but it turns out we only have the ability to uninstall all of them which would be not too much work to add.

Broadly though I think @nagilson and I can work to spec out

To uninstall a global SDK that would be a separate feature and somewhat more complicated but also not that much work to add. The hardest part might just be to know when to uninstall, if we want to do it without people asking us to.

RE it becoming less necessary I disagree, since the global installs affect machine state Id imagine its actually more important for us to allow users to uninstall them.

nagilson commented 3 months ago

Anyway I understand the op's concern, it may make them feel better to know that if they remove that .NET folder, then yes everything the extension could have possibly added will be removed ;)

SRNissen commented 3 months ago

To be honest I have any number of concerns but I was pretty emotional when I wrote the report so I didn't think to write them all down.

With regards to:

CDK cannot run without this runtime so presumably if you install CDK you want it to be able to function whatsoever, so it would need to download the runtime.

No. Not like this.

There are three paths forward.

Either take full responsibility for the necessary maintenance, including whatever steps are necessary to either hide this from- or fully integrate this with- other components, or don't, and if you don't, be clear about which parts you are not handling so I can ensure they are handled.

D2 extension page:

image

nagilson commented 3 months ago

You raise some very valid points. :) Thank you. I will answer this from an engineering side. PM side may have more. There are several things the .NET Install Tool installs, so its a bit complicated to answer your questions.

There are 2 things, 1 is that it installs a local, private runtime. This is what C#DK needs to run itself. These are local zip folders of .NET that do not impact the rest of the machine state. The 2nd thing it does, which we are just about to release, is optionally (with user consent) install a system wide, non private, global SDK.

dotnet 10 is landing at some point. Assuming these automated systems keep operating under the same policy, they'll install dotnet 10 too - will they then get rid of dotnet 8? Or will there be an ever-growing hidden folder with unknown binaries?

Both of these tools will install the newest stable version of .NET that is in support when they are asked to do an install which in this case should be when vscode is loaded. The folder can be cleaned up, but I honestly need to check in with some other teams to make sure we are doing that and we should develop features that make this easier to do per @baronfel's concerns.

If dependency management is handled by VSCode rather than my normal package manager, assuming I don't use vscode for a while (very realistic, e.g. I typically dev in jetbrains products and hadn't used vscode for a while when this happened) will I have an old, un-updated, possibly vulnerable, dotnet sdk installed?

For the SDK component on Linux, we actually do use the distro oriented package manager! (e.g. apt-get or yum.) For the runtime component, you would have a local private older runtime there, but it would not be used by C#DK or any others with a dependency on the install tool, as by the time you would open vscode, it should initiate the process to download a newer .NET.

If this is available to other vscode plugins and they start taking advantage of it but I, personally, don't know about it and eventually install dotnet 8 myself, how does that get deconflicted?

In general installing a newer SDK or Runtime on top of an older one will not break the older one given it still remains on disk, which it would without user invention. But to me it seems we should remove them from disk if we manage them (but not if the user does.)

The same cannot be said for the opposite direction of downgrading, which we block people from doing. There are a few more nuances there depending on the install.

With that said, we have been planning to map out the uninstall story a bit better and your comment is very helpful in pushing us to go do that. I can tell you that it is not acceptable for us to leave stuff behind that is out of support on the machine (or leave stuff behind in general.) And that we are on the path towards transitioning to 'vendor responsibility.'

SRNissen commented 3 months ago

Thank you.

Speaking of the uninstall story: I notice that I now have a folder ~/Library/ that appears to contain exclusively files related to this project, apparently some telemetry:

nagilson commented 3 months ago

I also forgot to mention that for global SDK, on Windows, MU (or Microsoft Update) generally keeps SDKs on the machine up to date, and with linux they are kept up to date by the package feed.

For the local runtimes I am working on a change now to remove those, but its a bit tricky because we dont know who could still be using the old ones and we need to balance breaking those things vs fixing them

nagilson commented 3 months ago

Thank you.

Speaking of the uninstall story: I notice that I now have a folder ~/Library/ that appears to contain exclusively files related to this project, apparently some telemetry:

  • /home/srnissen/Library/Application Support/Microsoft Visual Studio
  • /home/srnissen/Library/Application Support/Microsoft Visual Studio/prpbg.dat
  • /home/srnissen/Library/Application Support/Microsoft Visual Studio/prpbg.dat.bak
  • /home/srnissen/Library/Caches/Microsoft
  • /home/srnissen/Library/Caches/Microsoft/CSDevKit
  • /home/srnissen/Library/Caches/Microsoft/CSDevKit/Pending
  • /home/srnissen/Library/Caches/Microsoft/CSDevKit/Sent
  • /home/srnissen/Library/Logs/Macson
  • /home/srnissen/Library/Logs/Macson/Microsoft.VisualStudio.Reliability.Monitor-2024-02-24-14-55-59-4f24586.log

I'm not aware of those files, are you indicating they are still there post uninstall? @webreidi Do you know who might be aware of these?

SRNissen commented 3 months ago

Not impossible that these are general vscode files and not specific to this extension - taking a look in that log:

[2024-02-24 14:55:59Z][01] INFO   : Starting report manager sender thread
[2024-02-24 14:55:59Z][11] INFO   : Starting report sender main loop
[2024-02-24 14:55:59Z][01] INFO   : Queuing watson report from file:
[2024-02-24 14:55:59Z][01]        :   -- file: /home/srnissen/.cache/Microsoft/csdevkit/dumps/Microsoft.Visua.1080619.dmp
[2024-02-24 14:55:59Z][01]        :   -- kind: Crash