Worklet to Remove .Net Core Server (not SDK)

  • 27 September 2023
  • 5 replies


Has anyone found a good script to uninstall old versions of .NET Core? We’re running through vulnerabilities and we have a lot of servers running older unsupported versions of .NET Core Server Hosting. I’ve been able to upgrade .NET 6.0 without issue but it seems 3.1 versions just won’t update or go away. We have roughly 40+ servers running multiple versions of .NET Core. None are the SDK version so the .NET uninstall tool doesn’t work on them. I’ve tried a script to download the ASP.NET Core Hosting exe and running the uninstall commands from there and, nothing. I’ve tried installing a newer version of 3.1 over the existing version (like I did with 6.0) and didn’t take. How are all of you managing .NET Core versions and eliminating unsupported versions from your environment?

I’m at a loss at this point. There are not SDKs and there is no Visual Studio. So there seems to be no easy way to remove these old .NET versions especially when the uninstaller process via Automox can’t provide any info via the activity log even if I tell it to log and use the Get-Content -Path logfilename option. 

5 replies

Userlevel 4

Hi Josh,

This problem really irked me, so I put everything on the backburner until I could figure out SOMETHING to help you out here and I may have come up with it. It did work as I expected in my testing, but use at your own risk.

Initially I installed an older version of .net core 3.1, desktop runtime in my case.

Stage everything like I would imagine you have it:

I put together a Worklet policy which leverages the installer to do a silent uninstall. Notice my ‘non-compliance’ up in the top right of the first screenshot.


After running the Worklet, Compliance and no more .net core 3.1.26 on this machine:

Initially I was trying to use the uninstall tool, which was completely worthless. No surprise there.


In either case, the resolution I found is this:
EVALUATION CODE (can obviously be whatever you want):

if (Test-Path "C:\Program Files\dotnet\shared\Microsoft.NETCore.App\3.1.26") {
# Directory present
exit 1
else {
#directory not present
exit 0



Start-process -FilePath "windowsdesktop-runtime-3.1.26-win-x64.exe" -ArgumentList "/uninstall /quiet /norestart"


Please ensure you have the installation file for the exact version you need removing as the payload. I dont know if this will actually work for different versions. We may get lucky and it just works, but I did not test that.


Hope that helps.



Thats what I had tried initially with a few minor differences. 

I started with a bit longer list.

This was my initial Eval code I later changed it to just Exit 1 to continue through to focus on Remediation


This was my initial Remediation code which did not work (I forgot to show the attached file but it is there)

I took your approach but slight difference to make sure it was indeed seeing the folder there so it wasn’t just exiting since logging isn’t working. Tried both as "dotnet-hosting-3.1.26-win.exe" and .\dotnet-hosting-3.1.26-win.exe with the same results


As you can see it still remains


Userlevel 4

Any luck if you download the exact file from the dotnet website?


The file I’ve been using is from the dotnet website. Its from here and its the hosting bundle

Userlevel 4


After doing some digging I am fairly certain there are some dependencies preventing removal from happening. When I reinstalled everything with the hosting bundle instead of the single .Net install in my first example, my worklet did not function anymore. There are other dependencies such as core that needs cleaning up as well. 

I’m not certain what the next step would be unfortunately. When manually re-running the bundle install file and selecting ‘Uninstall’ it clearly does not remove much of anything that it had installed. I am not sure if that is the intended behavior (to NOT uninstall anything that it had initially installed) but that is how it is behaving leaving me to manually uninstall everything.

When I re-install with the standalone package, the Worklet functions again as expected. Apologies I don’t have better news here.