Maybe better to setUpperLimit to 9.0.0? We will be safer for next year.

/azp run

/azp run

@sergey-tihon potentially, but I'd rather have a reason to come back and check on this project. Also for the 8.0 release we're hoping to have SDK management CLI commandsin the SDK CLI, so we'll see if this project is still needed as much.

It appears the changes here got approved. Is there something else that needs to be done to get this complete, something I could help with? TheMSDN docs still show this as the way to uninstall .NET Core and for everythingnot Windowsthis is the only way shown to do the uninstall.

The tests need to pass, which is where I'm currently stumped.

OK, I haven't worked on this project but maybe I can chip in a little later this week/early next. I have a Mac and a Windows machine so... maybe all that together will help. If I figure it out I'll add suggestions in here to indicate potential changes.

/azp run

@baronfel I made some changes based on my best guess as to what needed to be fixed here. That fix then broke a bunch of different tests. The main problem failing tests initially is the logic to prevent the uninstall tool to run against sdks/runtimes that VS needs to run (basically, it was bucketing everything from 3 through 7 together and just ensuring 7 was still installed which was flagged by two tests). I updated to create a new band for 2019 at least that will ensure that 5.0 is still needed. However, this whole thing makes me a bit uneasy as the tests are super finicky for what those values are. Also, I'm not sure how much we should prevent customers from uninstalling these things just because VS needs them as there is a lot of logic trying to handle that.

Something to consider if we do invest here of making this a bit more flexible. The tests are also pretty difficult to read and understand.

Also, I'm not sure how much we should prevent customers from uninstalling these things just because VS needs them as there is a lot of logic trying to handle that.

While I think it's aninteresting use case, there's definitely a non-zero population (like me) using this entirely without Visual Studio at all, so that restriction is more an annoyance than anything helpful. But I get it, I may not be in the majority, just voicing support for the case where removing that logic could make things easier here.

While I think it's aninteresting use case, there's definitely a non-zero population (like me) using this entirely without Visual Studio at all, so that restriction is more an annoyance than anything helpful. But I get it, I may not be in the majority, just voicing support for the case where removing that logic could make things easier here.

I think we just don't know how customers are using the tool and in what contexts. My assumption is that while plenty of people may use it on a machine with VS, they are using it to specifically remove a version of .NET that they want gone, regardless of VS. VS repair would also fix things if the tool were too aggressive. Looking at the code, the VS tracking was the most complicated part and what limited our ability to get this PR in quickly.

I will try to improve the discusion about this talking about how i use this tool: My use of the DotNet Core Uninstaller is for servers only, i don't have Visual Studio installed on these servers, don't use SDKs, i'm only on the infrastructure side.

I manage some IIS servers clusters to hosting DotNet Core (and DotNet) systems, APIs, services, etc. So each month i have to update the servers to Windows Servers patches and download the latests Hosting Bundle for each DotNet version to install/update all my IIS servers to enable the newer applications to ran fine (and patch the older versions).

After the discover that i can update the DotNet from WSUS, I asked the WSUS team to include the DotNet Core and DotNet to update apps (ex: last month i asked then to enable DotNet 7 updates so these months the patches came with Windows Update).

So now i just ran Windows Update to update all the DotNet versions installed (3.1, 5.0, 6.0, 7.0)

I have two types of clusters:
Cluster A: all apps use the server shared DotNet. In this case i need the latest Hosting Bundle and the latest Runtime, and the server has all the DotNet versions (on latest versions) to be able to ran everything.
Cluster B: each app put your own DotNet built-in. In this case i only need the latest Hosting Bundle pack.

In an ideal world (example of the launch of the 7.0), i downloaded the 7.0.0 Hosting Bundle only, install everything on Cluster A and set a parameter to install only the Hosting Bundle on Cluster B. However, for some reason (i opened an issue, have to find the number), Install everything AND remove the Runtimes isn't the same that install only the Hosting Bundle. Seems like the IIS don't register the files, or something happens.

So basically i discovered and have been using the DotNet Core Uninstaller to do this:
Cluster A: Install the Full Hosting Bundle
Cluster B: Install the Full Hosting Bundle and after that, run "dotnet-core-uninstall remove --runtime --all --force --yes"

Addind to this, when the Windows Update updates the DotNet version, it install again the Runtimes, so each month now i have to install the Windows Update patches and after reboot, ran the "dotnet-core uninstall remove --runtimes" to clean all the runtimes.

So each time a new DotNet launches i came to the Github page to update my DotNet uninstaller to keeping work as i expected.

Sorry for the wall of text, but i think that could be a good thing to show why, where and how i use this software.

@baronfel Hi, about this question, the package seems to be unsigned (#253)
I'm posting here as the latest version is listing this "issue" as a reason to exist.