6

I was following the tutorial here to implement an uninstall shortcut in the start menu.

In short, the way to create the uninstall entry is as follows:

 <Shortcut Id="UninstallProduct"             
           Name="Uninstall My Application"
           Target="[SystemFolder]msiexec.exe"
           Arguments="/x [ProductCode]"
           Description="Uninstalls My Application" />

Based on Rob Mensching's suggestion here, if the application is small enough and you don't need to handle small updates and minor upgrades (which I don't), you can force every update to be a major upgrade. This is shown here. I used Rob's suggestion which was this:

<Product Id="*" UpgradeCode="PUT-GUID-HERE" Version="$(var.ProductVersion)">
 <Upgrade Id="PUT-GUID-HERE">
    <UpgradeVersion OnlyDetect="yes" Minimum="$(var.ProductVersion)" Property="NEWERVERSIONDETECTED" IncludeMinimum="no" />
    <UpgradeVersion OnlyDetect="no" Maximum="$(var.ProductVersion)" Property="OLDERVERSIONBEINGUPGRADED" IncludeMaximum="no" />
</Upgrade>

<InstallExecuteSequence>
    <RemoveExistingProducts After="InstallInitialize" />
</InstallExecuteSequence>

Now my question is if Product Id is randomized (*) to allow a major upgrade to take place, is there any other way to add an uninstall shortcut to the start menu or must we do it through Add/Remove programs? I'd prefer to create the shortcut in the start menu since it's just easier for the user. Obviously the way it is now, it won't work because [ProductCode] that is used in the msiexec arguments will change on every install. Thanks.

Community
  • 1
  • 1
Jack
  • 361
  • 2
  • 4
  • 17

1 Answers1

4

Are you saying you've tried it and it doesn't work? How does it fail? What is the shortcut argument? Using Product/@Id="*" sets the ProductCode property, so it should work correctly.

Bob Arnson
  • 21,377
  • 2
  • 40
  • 47
  • Maybe I'm doing something trivial wrong, but it fails in that when you click Uninstall, msiexec seems to be uninstalling the app, but it doesn't do anything, the app is still there, all the shortcuts are still there. I have and defined and am using these as specified in my original post. Both Product UpgradeCode and Upgrade Id have the same GUID but I believe the problem lies in the fact that Product Id=* and msiexec is using Arguments="/x [ProductCode]. Should these be different? – Jack Apr 23 '11 at 13:51
  • Are you saying [ProductCode] = Product Id (*) at compile time? – Jack Apr 23 '11 at 13:52
  • Just wanted to add, I get the same results (uninstall from start menu not working) when I use: instead of Upgrade and InstallExecuteSequence tags. – Jack Apr 23 '11 at 13:56
  • Product/@Id="asterisk" sets the ProductCode property at build time. Again, what's the arguments field of the shortcut? Does the GUID match the ProductCode property? (You can use Orca to open the .msi and get its ProductCode.) Product code and upgrade code GUIDs should be different, but that won't be a problem if you're using Product/@Id="asterisk". – Bob Arnson Apr 23 '11 at 14:33
  • Thanks for the Orca suggestion, just checked and yes, my Uninstall shortcut args match the ProductCode property of the .msi. I think I found the problem. There were two entires in Add/Remove programs for my app and apparently, the only way to fix it was to remove both entries from there first, then rebuild the WiX project, and install again. Now it seems to be uninstalling correctly. How would I prevent it from being installed twice (or having two entires in add/remove programs)? Or how did it happen in the first place if UpgradeCodes stayed the same? – Jack Apr 23 '11 at 14:47
  • I got it Bob, it was a versioning issue. I saw that the AllowSameVersionUpgrades attribute in MajorUpgrade explains the scenario well. I didn't know that MSI treated products as two different products if only the 4th version field changed (even using same upgrade code but different product codes). Thanks for the help. – Jack Apr 23 '11 at 14:58