2

So I'm taking over a pre-existing installer project but I really don't know too much about Wix and installers in general so I am just asking to get an idea what areas in this installer I should look into.

I have this problem where the .msi generated by my Wix installer installs properly. But on Windows 10, the Apps & Features page shows 2 entries for my app as well both of the entries have the "Uninstall" button greyed out.

I'm pretty lost what part of the .wxs is in charge of what shows up in the Control Panel, any help will be appreciated.

Dylan Riley
  • 409
  • 1
  • 4
  • 14
user1289479
  • 291
  • 4
  • 16
  • First thing to know about WiX is that its main feature is a tool build Windows Installer packages. You can't learn WiX without learning Windows Installer, directly or indirectly, and for some topics directly is better. – Tom Blodget Apr 09 '19 at 08:02

2 Answers2

1

WiX Quick-Start: WiX is not trival to learn - there is a learning curve, but it is not rocket science either. Maybe I can suggest this WiX quick start recommentations piece (chaotic, but upvoted - must be helpful). Particularly the "Hello World" section might be helpful - if you don't know WiX.

Answers: With regards to the specific questions:

  • Failed Major Upgrade: The two entries in Add / Remove Programs generally means a major upgrade has failed so there are now two installed versions of your product instead of one (a major upgrade is technically an uninstall of the old version and install of the new version - under the hood). Here is a long answer on the topic: Doing Major Upgrade in Wix creates 2 entries in Add/Remove Programs.
  • Embedded Setup.exe: It is also possible for an MSI to install a legacy-style setup.exe as part of its own installation. This could lead to several entries in Add / Remove Programs.
  • MajorUpgrade: To fix the major upgrade you need to look in your WiX sources, obviously. Normally people use the MajorUpgrade element to configure major upgrades (there are more detailed options using other elements). See separate section below for more on this.
  • Product Code: Whenever you have two versions of the same product installed, you have different product codes for them. To find the product codes, here are some suggestions: How can I find the product GUID of an installed MSI setup? Once you have the product codes you can uninstall via the msiexec.exe command line.

  • Uninstall: You can uninstall MSI files in a myriad of ways, here is a reference: Uninstalling an MSI file from the command line without using msiexec. Suggest you use msiexec.exe in section 3, as follows:

    msiexec.exe /x {Product-Code}

WiX Major Upgrades: WiX introduced a "convenience element" to control major upgrade quite a while back. The idea was to make implementation easier. Here are some details: Majorupgrade or Upgrade ID which is preferred for Major upgrade?

Inlined:

<MajorUpgrade DowngradeErrorMessage="Can’t downgrade." />

As you can see the newer approach is much simpler to deal with, whilst the old one allows full flexibility. I don't know which approach your sources use.

Major Upgrade Technicalities: The key issues for a major upgrade is that the Upgrade Code remains stable (some ways to do it without, but leaving that for now). In addition you need a new product code, a bumped up product version (one of the first 3 digits) and a new package code. If any of these changes fail to be made you can get two entries in Add / Remove Programs (failed upgrade whilst running).

Some Links:

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
  • Thanks for replying, I'll definitely take a look at that quickstart guide. For this specific problem though, I have gotten the duplicate entries from a clean install (no upgrade). Maybe there's some copy paste code in the .wxs? – user1289479 Apr 04 '19 at 21:17
  • Is it a burn bundle? – Stein Åsmul Apr 04 '19 at 21:17
  • What is a burn bundle? – user1289479 Apr 04 '19 at 21:20
  • A **burn bundle** is a `setup.exe` that may embed several MSI files and other EXE files and some other deployment files. It has the same markup style as a regular WiX XML file (`*.wxs`), but the schema is different and it compiles `setup.exe` files instead of `Setup.msi` files. It is a bootstrapper / launcher / downloader kind of thing. – Stein Åsmul Apr 04 '19 at 21:24
0

Thanks to Stein Åsmul for his link to documentation. I was able to figure out why my msi was doing what it was doing.

The main .wxs was disabling the Remove with the property

<Property Id="ARPNOREMOVE" Value="1" />

So removing that allowed me to Uninstall from the Windows Control Panel again.

The reason why 2 entries were showing up in the Control Panel though was that we were adding a bunch of registry entries in the folder

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\

There's some reasons behind needing some registry entries here, but at least now that I know why I can hopefully work around them. Hopefully this helps anyone in the future that might run into this problem of duplicate entries from clean installs.

user1289479
  • 291
  • 4
  • 16
  • The **`ARPNOREMOVE`** entries are rarely made without reason. Adding stuff directly to that Uninstall registry location is also not good practice. I would try to chat with the people who made those setups to figure out why they have done what they have done. Usually there are some hacky reasons. [Info on ARPNOREMOVE and similar properties here](https://stackoverflow.com/a/55006256/129130). – Stein Åsmul Apr 04 '19 at 22:12
  • I won't get into too much detail, but contractors, they were fired. – user1289479 Apr 04 '19 at 22:28
  • OK, if it is not sensitive you can always put it on github.com for a quick review. Just some advice if it is not too hairy or big. – Stein Åsmul Apr 04 '19 at 22:35
  • 1
    It's hairy, sensitive and big. I'm trying to chunk the entire thing into small problems to tackle one at a time. Hopefully I can refactor it in the future to be proper but for now I just have to put out each small fire. Thank though for all your help. – user1289479 Apr 04 '19 at 22:46
  • OK. My 2 cents for very large setups: comment out most of the component / files from each compile or shim them (replace with 1kb versions) to be able to build quickly if you are testing the setup logic (dialogs and custom actions). Otherwise the turnaround time is very long and few iterations are possible. [Simular answer](https://stackoverflow.com/a/30033958/129130) - with some more details. Most problematic areas of setups tend to be custom actions and weird registry writes and localization issues (language), but there are many pitfalls. – Stein Åsmul Apr 04 '19 at 23:05
  • [Got this answer on deployment complexity](https://stackoverflow.com/a/22737069/129130). Too long, but maybe a skim of the first section. And [the mid-section here](https://stackoverflow.com/a/12101548/129130) (called "The Complexity of Deployment"). – Stein Åsmul Apr 04 '19 at 23:15
  • Man thanks so much for all your links, I'll check those after my current task is done. – user1289479 Apr 04 '19 at 23:20
  • 1
    A "hairy, sensitive and big" problem space can be challenging to navigate one StackOverflow question after another. You do not have to go alone. We list commercial and community-based support options at https://www.firegiant.com/support-options/ that may (or may not) be interesting to you. Setup isn't just xcopy, welcome to the dark side, we have cookies. :) – Rob Mensching Apr 05 '19 at 04:26
  • @user1289479 I agree with Rob, deployment is quite difficult. We struggle to answer in this format. Sometimes our answers become ridiculous check lists for ourselves and fail to be helpful. I also have concerns, however, that [Rob may be affiliated with the Cookie Monster](http://robmensching.com/blog/posts/2012/6/25/b-is-for-bundle-and-thats-good-enough-for-me/) (see the first link). – Stein Åsmul Apr 05 '19 at 23:37