0
votes

I'm having a weird problem...

I created a basic WinForms app in C# using Visual Studio 2013, and I added a Setup & Deployment project to the solution to build my .msi installer. For the Setup & Deployment Project's properties, I have the DetectNewerInstalledVersion to true, and the RemovePreviousVersions set to true. Then, with every build, I'll increment the version number and let Visual Studio change the ProductCode. Lastly, I'll make sure that the UpgradeCode stays the same.

In this configuration, if users run the .msi with a previous version installed, then it performs an upgrade. Everything works (as in all files are updated to the new versions, etc.). But, when they open Add/Remove Programs, the icon for the old version(s) is still there, as well as the icon for the new version.

For example, if they used the .msi to install MyApp version 1.1, then used the .msi to upgrade to 1.2, then again to 1.3, then MyApp will correctly update to version 1.3, but the user goes to uninstall it in Control Panel->Programs and Features->Uninstall a program, there will be three MyApp icons (one for each version). And to properly uninstall MyApp, they must right-click/uninstall all three. If I delete the old versions from the registry (the usual fix for stale icons), then MyApp will not uninstall correctly. The uninstall will go through the motions without error, but the program files and icons will remain, and the application will still function like normal. To troubleshoot, I've made a series of builds with sequential version numbers, then opened each build's .vdproj file in a text editor to ensure that the ProductCode and PackageCode have been updated, but the UpgradeCode remains the same. They do, so it's not a problem of the UpgradeCode changing. I've also tried deleting the registry keys for the old icons. This gets them out of the Programs and Features uninstall list, but it prevents the program from being properly uninstalled this way, so this isn't an option.

Anybody have any ideas?

2

2 Answers

1
votes

This will happen when the first install is (say) Everyone and the upgrade is installed Just me (or vice versa). One type will not upgrade the other, so files will be replaced if installed to the same location, but there will be an entry for each in Programs&Features. They all must be Everyone or Just me to replace previous products.

You can install the upgrade with msiexec /I [path to msi file] /l*v [path to a log file] to see what's going on. If you search for occurrences of FindRelatedProducts you should see something about what it found and if it was the right context.

Note that Visual Studio setups can change the context if you do not have administrator privileges. You might specify an Everyone install but Visual Studio will change that to Just me if you don't have the privileges.

0
votes

Ok. Weird...

The issue comes from the way that it's run. Once installed, the program checks the network share for a newer .msi, and if it detects one, it downloads it, then launches it with Process.Start and command-line args. The StartInfo.Arguments string looked like:

startInfo.Arguments = "/i \"[MSIPATH]\" /log \"[LOGPATH]\"  TARGETDIR=\"[APPPATH]\" /qr+";

I guess someone fat-fingered the UI mode switch at the end. The "/qr+" switch should be "/qb!-". When I changed it, the problem stopped. I don't think that "/qr+" is even a valid switch, so I'm not sure why the install didn't just fail outright??? Anyway, that was the problem should anyone see something similar.

Special thanks to PhilDW for pointing me to the logs. :-)