I'm a bit light on detail but I think we have a problem.
Using the copy/paste method of boostrapping an installer project in wix, it appears we seem to have missed updating the UpgradeCode to ensure they are unique...
<Product Id="*" UpgradeCode="SOME-BAD-FOO">
So, it is my understanding that this is "not good" (r)(tm)
At the moment the users of the 2 installers with this issue are unlikely to have installed both, but they may in future.
Looking for ideas on how to fix this issue before it becomes an installed nightmare...
Maybe Windows cannot even install both at the same time?
Is there some way to perform an upgrade install/patch and change the UpgradeCode?
So, it is my understanding that this is "not good" (r)(tm)
That is really not good, you should be careful to not do that in the future as it can give you, and your users, a lot of headaches.
However, the solution is very simple. All you need to do is to change the upgrade code for one of the packages, and to add the current upgrade code in the Upgrade table for the new version, so it removes it, if it is found on the machine.
If you are sure the second version will be installed by all your users that have installed the first one, in the next release you should remove the upgrade code the from Upgrade table, to make sure you don't have any conflicts with the second package, i.e. the still using the first upgrade code.
One question I'd ask would be are you using Major or Minor Upgrades.
If Minor, I've never tried changing the UpgradeCode but not the ProductCode. I think it would be OK but I'm afraid to find out.
If Major Upgrades, do the products use different version number ranges? 1.0-1.9 , 2.0-2.9? If so, it would possible to change the UpgradeCode in both installers ( just leave the 'dirty' guid in your past ) and then use the old guid in your UpgradeTable with a version # as a the key to identifying the correct product codes.
If not, do you know every single ProductCode that was ever released to the wild for both products? A custom action could be used to query MSI for installed ProductCodes and then compare it to a list of known guids to decide whether it applies or not.
You'll have to leave the code in forever though. Old versions of software have a tendency to stick around forever.
Related
I'm still new to the WiX world, this week I discovered the .msp extension used for updating.
I would like to know if I can identify a possible update through (fileexists)
Why that? So I wouldn't have to run the MSI on past machines, only to be able to run the MSP later.
Or if there is any way to start the .msp without having run the .msi before.
Thank you!
Patches don't work that way. To get what you want, use major upgrades -- they work for initial install and later updates. As I said at https://www.joyofsetup.com/2008/12/29/neither-more-nor-less/:
Major upgrades aren’t so limited: They can change anything in a product, but also support as few changes as a small update. So even if you’re changing only a few files, you can still use major upgrades. Think of major as an upper limit on the set of changes, not the lower limit on the type of upgrade you need.
I have a big program in WiX that uses a bunch of MSIs, C# custom action programs, UIs, bootstrapper, you name it, it's there.
I'm having this problem: when I run a major upgrade, the previous version isn't being erased. That is, if I upgrade from version 1.0.0.x to 1.1.0.x, Programs & Features shows that both versions are installed on the machine.
This is a common problem, with many solutions here on SO. None of them are working for me -- if there's a post of SO about this, I've tried it.
I've been told that there's a one-to-one relationship between components in a major upgrade. That is, for every component that is removed, another component has to be added. When it's NOT a one-to-one relationship is when the old version doesn't get removed -- because there are still old components hanging.
Is there a way to determine what components are hanging? Like, in the log files or something? If I could determine what MSI is having the problem I could be far more proactive in solving the issue.
EDIT:
Although I haven't solved the problem, thanks to Mr. Urman's suggestions I may be on the right track.
I created that registry key, but... it didn't seem to do anything. However, I did search my uninstall logs for the word "Disallow", and I found this phrase 9 times:
Disallowing uninstallation of component: {GUID-HERE} since another client exists.
Also, this phrase appears before each grouping of the "Disallow" phrase:
PROPERTY CHANGE: Adding INSTALLLEVEL property. It's value is '1'.
This gives me something to go on. However, I can't seem to find the GUIDs that are mentioned! They're not in my solution nor are they searchable in the registry. Besides searching the registry, is there a way (Windows 7 32 bit) to find out what component a specific GUID corresponds to?
I've been told that there's a one-to-one relationship between components in a major upgrade. That is, for every component that is removed, another component has to be added. When it's NOT a one-to-one relationship is when the old version doesn't get removed -- because there are still old components hanging.
This is not strictly true. It's quite true of minor upgrades, and in certain configurations (those involving a late RemoveExistingProducts) major upgrades are just as picky. But your typical major upgrade functions more like the user had chosen to uninstall the old version, then to install the new version. Start by verifying your assumptions: make sure you have a proper major upgrade (you changed your ProductVersion and Product Code, and have the right entries in your Upgrade table, right?). Then diagnose.
How best to identify what's going on? In my experience, log files are your best bet. Since the older version is being uninstalled indirectly, you cannot use command lines to log it. So instead set the Logging policy by creating or setting the following registry value. (Remove it later when you want to revert the setting.)
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer
Value (Reg_SZ): Logging
Data: voicewarmup
Then run your major upgrade, find the appropriate log file that was generated in %temp%. (Consider cleaning out %temp% ahead of time to make finding it easier. Or sort by date.) Look especially at the uninstallation (which you can identify by ProductVersion, or the presence of UPGRADINGPRODUCTCODE). I'd look especially for lines like Disallowing uninstallation of component ... that contain a component GUID.
Once you have that GUID, you have to figure out what component it is, and how it got into its current state. You can manually examine your built .msi files (with a tool like Orca) to find the component, but few tools will tell you all the clients. My employer's product comes with a helper tool called InstallShield Msi Sleuth that can list all the installed products referencing a component code, or you can build your own from MsiEnumProducts or Installer.ComponentClients. You cannot just search the registry directly, because Windows Installer stores GUIDs in a compressed or packed form.
Then identifying the "why" could be the hard part. Or it could be as simple as an incorrect Shared DLL reference count, especially if you've only encountered this on a test machine that has seen non-released versions of your product.
As a related alternative, but only relevant to a minor upgrade or small update, you could set the EnforceUpgradeComponentRules Policy. This helps reveal problems as you hit them, rather than allowing Windows Installer to do its best to continue anyway.
I'm currently trying to understand the relationship between Windows Installer ProductCode and the Version attribute.
As far as I understand the examples I've seen so far, the ProductCode denotes a specific version, so increasing the version also should change the product code. (Indeed the example above uses Product Id='*').
To understand this better, I am asking myself whether there is any scenario that would keep the ProductCode the same but increase the Version? What would Windows Installer do with such an MSI, given a previous one with a different ProductCode (but same UpgradeCode) were installed?
I guess another variation on my confusing would be: If I onnly want to do "major upgrades" does Id='*' make sense or will I have to control the ProductCode somehow?
IMO:
1) The MSI SDK doco is poorly written. It discusses the topic in a roundabout way without actually explaining your options.
2) The vast majority of MSI developers should use Major Upgrades which in WiX means Id="*", bump one of the first 3 fields in ProductVersion and author a MajorUpgrade element.
3) Minor upgrades are much stringent and error prone. You should be an expert in MSI and understand it and the component rules very well before deciding it's time for a Minor Upgrade. In other words you'll know when it's time.
FWIW when doing Major Upgrades "UpgradeCode" acts more like a ProductCode in that it's static. Think of UpgradeCode as a series of products and your ProductCode is always changing not because it's a new product per say but because MSI says you must change it to do a major upgrade.
Software gets refactored so much from build to build these days with so little functionality change that the whole description of major, minor and "small" (always disliked that one... who releases a product without changing the version number???) is pointless.
If you were to rebuild your MSI file with updated files and increment the ProductVersion, then you have a minor update that you could install with a command line of REINSTALL=ALL REINSTALLMODE=vomus (typically) that would update the existing instaled product. This is rare, IMO.
If you didn't use that command line you'd get that "another version of this product is already installed" message (if the package code was new for the new MSI, as it should be).
If you only do major upgrades then yes you need a new ProductCode every time, and increment the ProductVersion somewhere in the first 3 fields.
I'd like to make an install package in WIX, which will upgrade previous version of my product. I use MajorUpgrade for this purpose.
The problem is - I'd like to keep ProductId for the whole life time of my application without any changes. But MajorUpgrade requires different ProductId's for each version. Otherwise it shows an error message "Another version is already installed".
How can I perform an upgrade, keeping my ProductId?
Thanks ahead of time!
For major upgrades you must change ProductId. Actually I recommend to auto-generate ProductId each time installer is built by having "*" as its value. This way you will have always different value in each installer version and you will be allowed to do major upgrade. The actual value of ProductId is easy to obtain from build result.
But what you really need to keep for product lifecycle is UpgradeCode. This value you should choose once for your application and keep it.
I'm using AjaxControlToolkit and they decided to change their version numbering scheme. The change is documented here : http://stephenwalther.com/archive/2013/01/24/new-january-2013-release-of-the-ajax-control-toolkit.aspx
Basicaly, the newer versions have a lower file version (4.1.7.123 is newer than 4.1.60501.0, but 7 is smaller than 60501.)
Obviously, this causes issues in my MSI as it is now seeing a component with an higher version number already on the machine and thus ouputs this:
MSI (s) (7C:10) [10:04:14:996]: Disallowing installation of component: {22C7D2FC-179E-515D-B650-CE20A7B3F9E0} since the same component with higher versioned keyfile exists
How would i go and force the installation of this newer but lower-version-number component ?
P.S. Personal rant: AjaxControlToolkit guys for justifying this number by saying "And yes, I realize that 7.0123 is less than 60,919, but we ran out of numbers.". 4.2.7.123 would have worked, guys. You ran out of 3rd numbers, fine, you need to increment the 2nd.
Easiest thing to do is to install to a new location. That will avoid the checks completely. A hacked thing to do is to fake the File.Version column in the MSI but that will only get you through this once, eventually you'll need to get to a new location to address the problem.
You could also set the REINSTALLMODE to include "a" but that will just create all sorts of grief for you lately, so I can't really recommend that as an option.
Note: The AjaxControlToolkit guys did give you a huge headache. If they renamed their .dll, that would be the most helpful. Seems like the least they could do since they just broke their world so badly.