CommandNotFoundException

[LostBeard]

OS: Windows 10 64bit

Installer used: dotnet-core-uninstall-1.7.521001.msi

I followed the straightforward instructions on the Releases page. I got to step 5: Run the tool by using dotnet-core-uninstall.. I opened a new elevated PowerShell window and ran .\dotnet-core-uninstall and got the error shown below. I even tried running the command in its own install folder.

PS C:\Program Files (x86)\dotnet-core-uninstall> .\dotnet-core-uninstall
.\dotnet-core-uninstall : The term '.\dotnet-core-uninstall' is not recognized as the name of a cmdlet, function,
script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is
correct and try again.
At line:1 char:1
+ .\dotnet-core-uninstall
+ ~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (.\dotnet-core-uninstall:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

I also tried running dotnet-core-uninstall in an elevated Command Prompt and got a similar error.

'dotnet-core-uninstall' is not recognized as an internal or external command,
operable program or batch file.

I noticed there is no .exe in the install folder named dotnet-core-uninstall.exe. The only exe in that folder is createdump.exe (190 files total.) The file dotnet-core-uninstall.pdb is there though.

I might be missing something simple. Thanks for the help.

[baronfel]

My guess is that you downloaded the macos binary instead of the windows exe. Can you check your download and the releases page again and see if that's the case?

[LostBeard]

As I said, I used: dotnet-core-uninstall-1.7.521001.msi and it installs but without the app exe.

[baronfel]

Apologies - I was responding from my phone. I've now gone to my desk and verified everything you wrote in your initial response. It seems that the windows build is in fact not bundling the application. In fact, I would have expected the MSI to have a single-file install similar to the contents of the macOS tarball. That's not the case, and it points to something that's regressed in our work to get this repo compliant with required DevDiv processes.

[LostBeard]

Thank you. I will try a lower release version or wait until a new version is released.

[baronfel]

I've built a local version of the tool and confirmed that a) the project publish creates the exe (as expected) and b) the built MSI also contains the exe (also as expected). What's confusing the heck out of me is that we had internal testing/validation done with these bits and had no errors reported from our testing team - and this would have failed immediately as you found.

[joeloff]

The EXE is part of the MSI

Let me dig around some more

[joeloff]

Latest release installs fine

@LostBeard can you share the MSI log? I'm guessing you just ran the MSI directly, so it will likely be under your %temp% directory in a file similar to MSI5b82e.LOG. Probably can do something like findstr /snip dotnet-core-uninstall %TEMP%\MSI*.log to find it, though findstr sometimes struggle with encoded files.

Have you tried running a repair?

[joeloff]

I've confirmed, it's a problem with the upgrade. @LostBeard for now, just repair the MSI.

The 1.6.0 build is bad. The file version for dotnet-core-uninstall.exe is 42.42.42.42424 (that's the default for a local build). For 1.7, the version is correct, but when the MSIs are upgrade, it will look the currently installed component, then determine the file on disk is a higher version (versioned file rules apply in this case), so it won't remove the component. It then proceeds with removing the old MSI and when it then installs the new MSI, it skips installing the EXE so you end up with no file on disk.

Below is the longer, more technical breakdown

After installing 1.6 and then installing 1.7, the MSI log will show the following (the 18916... GUID is associated with the component for the dotnet-core-uninstall.exe file)

The RemoveExistingProducts action is scheduled to run after InstallInitialize

During InstallValidate, which include all the costing actions, the service determines that the current copy of the file on disk has a higher version, so it flags the component to no be installed.

MSI (s) (00:C8) [09:31:05:902]: Disallowing installation of component: {18916A78-A167-4AF7-90F5-1BC994789CFE} since the same component with higher versioned keyfile exists

Eventually RemoveExistingProducts runs, which removes the previous MSI and we eventually hit InstallFiles action that skips over the component.

[baronfel]

@LostBeard thanks for raising this - I've added wording to both the current release and the 1.6.0 release warning users about the faulty build and the prereq to remove the 1.6.0 release before installing new releases.

[LostBeard]

I uninstalled via Add or remove Programs and re-installed and it fixed it. There is now 205 items in the install folder including the dotnet-core-uninstall.exe file that wasn't there before. I think the original install had failed but didn't give any indication of the failure.

[LostBeard]

@LostBeard can you share the MSI log? I'm guessing you just ran the MSI directly, so it will likely be under your %temp% directory in a file similar to MSI5b82e.LOG. Probably can do something like findstr /snip dotnet-core-uninstall %TEMP%\MSI*.log to find it, though findstr sometimes struggle with encoded files.

My %temp% folder is C:\Users\Lost\AppData\Local\Temp (just an fyi in case you have another folder I might check.)

I can't find the log file. The findstr command seemed to just hang. I used VS Code to search the %temp% folder and only 4 files contained the dotnet-core-uninstall string and they were just logs from other installers that were writing out the current Path environment variable value and it contained: C:\Program Files (x86)\dotnet-core-uninstall\.

Have you tried running a repair?

I did not. I uninstalled and re-installed, which worked. A repair would likely have worked also. 👍

[LostBeard]

Version 1.7 is the only version I have ever installed and it failed the first time but worked the second. Maybe a registry entry read/write fails the first time but works the 2nd time? (Just a guess, I've created installers before and version checking via a registry entry got me once.)

I used dotnet-core-uninstall-1.7.521001.msi both times.

[joeloff]

MSI logging might be turned off. There's a policy key you can query from a command prompt using reg query HKLM\SOFTWARE\POLICIES\Microsoft\Windows\Installer /s

You should see something like

HKEY_LOCAL_MACHINE\SOFTWARE\POLICIES\Microsoft\Windows\Installer
    Logging    REG_SZ    oicewarmupv

If not, you can create the key and it will enable automatic logging.