I have an application that needs to upgrade itself, so it runs an MSI that installs the application while the application is still running. For years that has worked successfully, despite the .exe's, .dll's and other things being in use the installer works without a problem. However I am now installing the CEF browser component and this is causing me trouble.
This is an example from the installer log:
*** the file is scheduled for removal
MSI (s) (9C:7C) [11:44:06:372]: Executing op: FileRemove(,FileName=cef.pak,,ComponentId={AEDD9CDD-C5CB-4260-A5D5-A7C13011CC97})
MSI (s) (9C:7C) [11:44:06:374]: Verifying accessibility of file: cef.pak
MSI (s) (9C:7C) [11:44:06:374]: Verifying accessibility of file: cef.pak
MSI (s) (9C:7C) [11:44:06:374]: Using source file security for destination.
MSI (s) (9C:7C) [11:44:06:375]: Note: 1: 2318 2: C:\Config.Msi\144c57.rbf
MSI (s) (9C:7C) [11:44:06:390]: Note: 1: 2329 2: 32 3: C:\xxxx\cef.pak
MSI (s) (9C:7C) [11:44:06:390]: Verifying accessibility of file: cef.pak
MSI (s) (9C:7C) [11:44:06:393]: Executing op: FileRemove(,FileName=cef_100_percent.pak,,ComponentId={AEDD9CDD-C5CB-4260-A5D5-A7C13011CC97})
Info 1903. Scheduling reboot operation: Deleting file C:\xxxx\cef.pak. Must reboot to complete operation.
*** The file is not overwritten and it sees the files as the same
MSI (s) (9C:30) [11:44:09:050]: Executing op: FileCopy(SourceName=cef.pak,SourceCabKey=cef.pak,DestName=cef.pak,Attributes=512,FileSize=1961473,PerTick=65536,,VerifyMedia=1,,,,,CheckCRC=0,,,InstallMode=58982400,HashOptions=0,HashPart1=885556701,HashPart2=2067920947,HashPart3=-336625845,HashPart4=-1380829775,,)
MSI (s) (9C:30) [11:44:09:056]: File: C:\xxxxcef.pak; Won't Overwrite; Won't patch; Existing file is unversioned and unmodified - hash matches source file
So the installer tries to remove the file, knows it is in use and schedules a remove after the reboot. But then it sees if it should install the file, sees it is already there (it hasn't been removed yet) and decides to not do anything. So after the reboot the file is gone and the application fails.
I tried setting the installer to always replace the file with:
<Property Id='REINSTALLMODE' Value='amus'/>
On Windows 7 this produces the desired behaviour, the file is seen as being in use, the new one is copied to a temporary location and a rename scheduled for after a reboot and delete.
Line 1525: MSI (s) (CC:64) [12:19:41:201]: The file represented by File table key 'cef.pak' has no eligible binary patches
Line 2618: MSI (s) (CC:64) [12:19:41:775]: Executing op: FileRemove(,FileName=cef.pak,,ComponentId={AEDD9CDD-C5CB-4260-A5D5-A7C13011CC97})
Line 2619: MSI (s) (CC:64) [12:19:41:776]: Verifying accessibility of file: cef.pak
Line 2620: MSI (s) (CC:64) [12:19:41:776]: Verifying accessibility of file: cef.pak
Line 2622: MSI (s) (CC:64) [12:19:41:779]: Note: 1: 2329 2: 32 3: C:\xxx\cef.pak
Line 2623: MSI (s) (CC:64) [12:19:41:779]: Verifying accessibility of file: cef.pak
Line 2625: Info 1903. Scheduling reboot operation: Deleting file C:\xxx\cef.pak. Must reboot to complete operation.
Line 3382: MSI (s) (CC:68) [12:19:42:632]: The file represented by File table key 'cef.pak' has no eligible binary patches
Line 3801: MSI (s) (CC:68) [12:19:42:933]: Executing op: FileCopy(SourceName=cef.pak,SourceCabKey=cef.pak,DestName=cef.pak,Attributes=512,FileSize=1961473,PerTick=65536,,VerifyMedia=1,,,,,CheckCRC=0,,,InstallMode=62914560,HashOptions=0,HashPart1=885556701,HashPart2=2067920947,HashPart3=-336625845,HashPart4=-1380829775,,)
Line 3801: MSI (s) (CC:68) [12:19:42:933]: Executing op: FileCopy(SourceName=cef.pak,SourceCabKey=cef.pak,DestName=cef.pak,Attributes=512,FileSize=1961473,PerTick=65536,,VerifyMedia=1,,,,,CheckCRC=0,,,InstallMode=62914560,HashOptions=0,HashPart1=885556701,HashPart2=2067920947,HashPart3=-336625845,HashPart4=-1380829775,,)
Line 3801: MSI (s) (CC:68) [12:19:42:933]: Executing op: FileCopy(SourceName=cef.pak,SourceCabKey=cef.pak,DestName=cef.pak,Attributes=512,FileSize=1961473,PerTick=65536,,VerifyMedia=1,,,,,CheckCRC=0,,,InstallMode=62914560,HashOptions=0,HashPart1=885556701,HashPart2=2067920947,HashPart3=-336625845,HashPart4=-1380829775,,)
Line 3802: MSI (s) (CC:68) [12:19:42:939]: File: C:\xxx\cef.pak; Overwrite; Won't patch; REINSTALLMODE specifies all files to be overwritten
Line 3803: MSI (s) (CC:68) [12:19:42:939]: Source for file 'cef.pak' is compressed
Line 3805: MSI (s) (CC:68) [12:19:43:713]: Verifying accessibility of file: cef.pak
Line 3806: MSI (s) (CC:68) [12:19:43:713]: Verifying accessibility of file: cef.pak
Line 3808: MSI (s) (CC:68) [12:19:43:717]: Note: 1: 2329 2: 32 3: C:\xxx\cef.pak
Line 3809: MSI (s) (CC:68) [12:19:43:717]: Verifying accessibility of file: cef.pak
Line 3810: Info 1603. The file C:\xxx\cef.pak is being held in use. Close that application and retry.
Line 3811: Info 1903. Scheduling reboot operation: Deleting file C:\xxx\cef.pak. Must reboot to complete operation.
Line 3812: Info 1902. Scheduling reboot operation: Renaming file C:\xxx\TBMBFB2.tmp to C:\xxx\cef.pak. Must reboot to complete operation.
In Windows 10 however this does not occur, it tries to immediately replace the file without using the temporary file and it therefore fails.
cef.pak
Line 1895: MSI (s) (88:8C) [12:07:12:133]: The file represented by File table key 'cef.pak' has no eligible binary patches
Line 3011: MSI (s) (88:8C) [12:07:13:761]: Executing op: FileRemove(,FileName=cef.pak,,ComponentId={AEDD9CDD-C5CB-4260-A5D5-A7C13011CC97})
Line 3012: MSI (s) (88:8C) [12:07:13:763]: Verifying accessibility of file: cef.pak
Line 3013: MSI (s) (88:8C) [12:07:13:764]: Verifying accessibility of file: cef.pak
Line 3016: MSI (s) (88:8C) [12:07:13:782]: Note: 1: 2329 2: 32 3: c:\xxx\cef.pak
Line 3017: MSI (s) (88:8C) [12:07:13:782]: Verifying accessibility of file: cef.pak
Line 3019: Info 1903. Scheduling reboot operation: Deleting file c:\xxx\cef.pak. Must reboot to complete operation.
Line 3747: MSI (s) (88:8C) [12:07:16:042]: The file represented by File table key 'cef.pak' has no eligible binary patches
Line 4322: MSI (s) (88:8C) [12:07:16:577]: Executing op: FileCopy(SourceName=cef.pak,SourceCabKey=cef.pak,DestName=cef.pak,Attributes=512,FileSize=1961473,PerTick=65536,,VerifyMedia=1,,,,,CheckCRC=0,,,InstallMode=62914560,HashOptions=0,HashPart1=885556701,HashPart2=2067920947,HashPart3=-336625845,HashPart4=-1380829775,,)
Line 4322: MSI (s) (88:8C) [12:07:16:577]: Executing op: FileCopy(SourceName=cef.pak,SourceCabKey=cef.pak,DestName=cef.pak,Attributes=512,FileSize=1961473,PerTick=65536,,VerifyMedia=1,,,,,CheckCRC=0,,,InstallMode=62914560,HashOptions=0,HashPart1=885556701,HashPart2=2067920947,HashPart3=-336625845,HashPart4=-1380829775,,)
Line 4322: MSI (s) (88:8C) [12:07:16:577]: Executing op: FileCopy(SourceName=cef.pak,SourceCabKey=cef.pak,DestName=cef.pak,Attributes=512,FileSize=1961473,PerTick=65536,,VerifyMedia=1,,,,,CheckCRC=0,,,InstallMode=62914560,HashOptions=0,HashPart1=885556701,HashPart2=2067920947,HashPart3=-336625845,HashPart4=-1380829775,,)
Line 4323: MSI (s) (88:8C) [12:07:16:584]: File: c:\xxx\cef.pak; Overwrite; Won't patch; REINSTALLMODE specifies all files to be overwritten
Line 4324: MSI (s) (88:8C) [12:07:16:584]: Source for file 'cef.pak' is compressed
Line 4325: MSI (s) (88:8C) [12:07:16:585]: Re-applying security from existing file.
Line 4326: MSI (s) (88:8C) [12:07:21:645]: Verifying accessibility of file: cef.pak
Line 4327: MSI (s) (88:8C) [12:07:21:647]: Using source file security for destination.
Line 4328: MSI (s) (88:8C) [12:07:21:647]: Note: 1: 2318 2: C:\Config.Msi\a5880.rbf
Line 4329: MSI (s) (88:8C) [12:07:21:651]: Note: 1: 1310 2: 0 3: c:\xxx\cef.pak
Line 4330: Info 1603. The file c:\xxx\cef.pak is being held in use. Close that application and retry.
Line 4331: MSI (s) (88:8C) [12:07:21:652]: Product: XXX-- Error 1310. Error writing to file: c:\xxx\cef.pak. System error 0. Verify that you have access to that directory.
Line 4332:
Line 4333: Error 1310. Error writing to file: c:\xxx\cef.pak. System error 0. Verify that you have access to that directory.
Line 4334: MSI (s) (88:8C) [12:07:21:683]: Note: 1: 2265 2: 3: -2147287035
Line 4335: MSI (s) (88:8C) [12:07:21:684]: User policy value 'DisableRollback' is 0
Line 4336: MSI (s) (88:8C) [12:07:21:684]: Machine policy value 'DisableRollback' is 0
Line 4337: Action ended 12:07:21: InstallFinalize. Return value 3.
Line 4347: MSI (s) (88:8C) [12:07:21:713]: Executing op: FileCopy(SourceName=C:\Config.Msi\a5880.rbf,,DestName=c:\xxx\cef.pak,Attributes=32,FileSize=0,PerTick=0,,VerifyMedia=0,ElevateFlags=3,,,,,,,InstallMode=4194304,,,,,,,)
Line 4348: MSI (s) (88:8C) [12:07:21:713]: File: c:\xxx\cef.pak; Overwrite; Won't patch; REINSTALLMODE specifies all files to be overwritten
Line 4349: MSI (s) (88:8C) [12:07:21:715]: Re-applying security from existing file.
Line 4350: MSI (s) (88:8C) [12:07:21:718]: Note: 1: 2318 2:
Line 4351: MSI (s) (88:8C) [12:07:21:720]: Verifying accessibility of file: cef.pak
Line 4352: MSI (s) (88:8C) [12:07:21:722]: Using source file security for destination.
Line 4353: MSI (s) (88:8C) [12:07:21:722]: Note: 1: 2318 2: C:\Config.Msi\a5881.rbf
Line 4354: MSI (s) (88:8C) [12:07:21:735]: File will have security applied from OpCode.
Line 4355: MSI (s) (88:8C) [12:07:21:737]: Note: 1: 1310 2: 32 3: c:\xxx\cef.pak
Line 4356: Info 1603. The file c:\xxx\cef.pak is being held in use. Close that application and retry.
Line 4357: MSI (s) (88:8C) [12:07:21:737]: Error in rollback skipped. Return: 3
Line 4358: Info 1310. Error writing to file: c:\xxx\cef.pak. System error 32. Verify that you have access to that directory.
Is there a way to get that behaviour for other types of files (e.g .pak files)?
CEF Browser: I am not familiar with this component. Does it run in-process? (as a dll) - or does it have an API-call to shut itself down? Could you try to implement the Windows Restart Manager "RegisterApplicationRestart" feature described below for your main executable? Or you can call shutdown in a custom action for the component if there is an API?
Data File: Also, is this a data file that you should not install at all, but rather let the component itself create on launch? If this is the case you can remove the file from the installer and avoid it being entangled with your installer at all? This is particularly preferable for unversioned files - which can be hard to update beacuse of the MSI file overwrite rules / file versioning rules.
Restart Manager: Windows Installer supports what is referred to as a Restart Manager feature. The idea is to have the application shut itself down gracefully during installation - releasing all file and resource locks - and then to have Windows Installer restart it again after all files have been updated. This means that the application itself will take care of its own shutdown and restart when told to do so: "shut yourself down and restart when told" (saving all data and ideally the exact state). Only the application itself can know how to do this properly?
Technical Support: This is a technical article on how to implement support for the Restart Manager feature in your application - from Advanced Installer, makers of leading deployment tools. It is a nice article: https://www.advancedinstaller.com/user-guide/qa-vista-restart-manager.html
HRESULT WINAPI RegisterApplicationRestart(PCWSTR pwzCommandline, DWORD dwFlags);
The whole idea is basically to prefer restarting applications rather than restarting the OS - and also to avoid reboots in general. To that end: 1) Your application calls RegisterApplicationRestart() with a command line specified for its eventual restart - it "signs up" for restart management. 2) Your application watches for WM_QUERYENDSESSION messages and shuts down gracefully saving data in an appropriate way when told to do so. 3) Then Restart Manager can restart the application when finished installing (restart can be disabled).
Links:
Restart Manager and rebooting
Restart Manager guidelines for applications
I have a problem getting a wix installer to do a major upgrade when the previous versions installer was made by a different toolkit. I have my product defined like this:
<Product Version="!(bind.FileVersion.baustatik.exe)" Id="*"
Name="DIE Anwendungen"
Language="0"
Codepage="1252"
Manufacturer="D.I.E. Software GmbH"
UpgradeCode="6DCA3BAD-77E9-41AE-8F72-B92DE136C499">
<Package InstallerVersion="400"
Compressed="yes"
InstallScope="perMachine"
InstallPrivileges="elevated" />
<MajorUpgrade
AllowDowngrades="no"
AllowSameVersionUpgrades="no"
DowngradeErrorMessage="Es ist bereits eine neuere Version von [ProductName] installiert." />
..... other stuff
The above produces an msi. That msi is chained inside a bundle. The bundle is defined like this:
<Bundle Name="DIE Anwendungen"
Version="!(bind.packageVersion.The32bitMsi)"
Manufacturer="D.I.E. Software GmbH"
UpgradeCode="6DCA3BAD-77E9-41AE-8F72-B92DE136C499"
HelpUrl="https://www.die.de/impressum"
Copyright="Copyright D.I.E. Software GmbH"
HelpTelephone="0800 343 2255"
UpdateUrl="https://www.die.de/downloads.aspx"
IconSourceFile="$(var.SolutionDir)applications\xfalt\xfalt.loader\baustatik.ico"
AboutUrl="https://www.die.de">
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.HyperlinkLicense">
<bal:WixStandardBootstrapperApplication
LogoFile="res/banner.png"
ThemeFile ="res/ClassicTheme.xml"
LocalizationFile="res/ClassicTheme.wxl"
SuppressOptionsUI="yes"
LicenseUrl=""/>
</BootstrapperApplicationRef>
I have verified that
- i'm using the same upgrade code
- i'm building a new product code (*) for every update
- I'm using the same language-id (language_neutral: 0)
- !(bind.FileVersion.baustatik.exe) produces the version info that i expect
When i build the setup like this, install, increase the version number, build and install (all using wix), the major upgrade takes place.
When i install the setup for a previous version (one that was build using 'advanced installer') - where the upgrade code was the same - and next install a newer version where the setup was build using wix, the major upgrade does not work. i.e.: No files or startmenu entries from the previous version are beeing removed and i end up with 2 entries in control panel.
Any suggestions what might be causing this ?
(Edit)
I did what Bogdan suggested. The full log, however, did not have any helpful information.
FindRelatenProducts:
MSI (c) (8C:88) [17:34:20:741]: Doing action: FindRelatedProducts
MSI (c) (8C:88) [17:34:20:741]: Note: 1: 2205 2: 3: ActionText
Aktion 17:34:20: FindRelatedProducts. Nach verwandten Anwendungen wird gesucht
Aktion gestartet um 17:34:20: FindRelatedProducts.
Aktion beendet um 17:34:20: FindRelatedProducts. Rückgabewert 1.
... and later:
MSI (s) (2C:04) [17:34:24:762]: Doing action: FindRelatedProducts
MSI (s) (2C:04) [17:34:24:762]: Note: 1: 2205 2: 3: ActionText
Aktion gestartet um 17:34:24: FindRelatedProducts.
MSI (s) (2C:04) [17:34:24:762]: Skipping FindRelatedProducts action: already done on client side
RemoveExistringProducts gives:
Aktion gestartet um 17:34:24: RemoveExistingProducts.
MSI (s) (2C:04) [17:34:24:841]: Note: 1: 2205 2: 3: Error
MSI (s) (2C:04) [17:34:24:841]: Note: 1: 2228 2: 3: Error 4: SELECT Message FROM Error WHERE Error = 22
MSI (s) (2C:04) [17:34:24:841]: Note: 1: 2205 2: 3: Error
MSI (s) (2C:04) [17:34:24:841]: Note: 1: 2228 2: 3: Error 4: SELECT Message FROM Error WHERE Error = 23
MSI (s) (2C:04) [17:34:24:841]: Note: 1: 2205 2: 3: Error
MSI (s) (2C:04) [17:34:24:841]: Note: 1: 2228 2: 3: Error 4: SELECT Message FROM Error WHERE Error = 16
MSI (s) (2C:04) [17:34:24:841]: Note: 1: 2205 2: 3: Error
MSI (s) (2C:04) [17:34:24:841]: Note: 1: 2228 2: 3: Error 4: SELECT Message FROM Error WHERE Error = 21
Aktion beendet um 17:34:24: RemoveExistingProducts. Rückgabewert 1.
Concerning perUser/perMachine:
In my (wix)package (see code) i have "InstallScope='perMachine'" and in the "AdvancedInstaller" i have "Installation Type: per machine only" - i assume this is the same thing.
Any other ideas?
(EDIT 2)
I have done as PhilDW suggested and opened the upgrade tables for the old and the new msi using orca. I did find the following.
Old msi:
New msi:
However, i do not know what to make of that. Given that information, does anybody know what i have to put in my wix code in order to upgrade the old msi ?
The major upgrade could fail even if the upgradecode is the same, if the install type of the package is different (per user or per machine - this happens a lot) or if the install language is different (which you already checked).
You can install the new MSI and create a verbose log while you do this, then search the log for RemoveExistingProducts and FindRelatedProducts. Next to one of these standard actions you will find an explicit message about why the upgrade is skipped.
Bogdan is on the right track. However the log would indicate if there was a related product installed, and it would show its ProductCode and say something about the other context, and those things are not in the log. That means you'll need to look directly at the Upgrade table in the MSI file to make sure that the version checking is correct in the minimum/maximum fields. There's nothing in the posted data I can see verifying the actual version of the older product and the versions that the Upgrade will search for. It also wouldn't hurt as a sanity check to see that you actually have an Upgrade table in your MSI. Docs here:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa372379(v=vs.85).aspx
You may as well check that the languages match with the older product, and that the Attributes don't have OnlyDetect set (unlikely, but being thorough).
It's also not clear to me that you have incremented ProductVersion in the first three fields, another requirement for a major upgrade.
There are some odd things that can cause issues. WiX forces uppercase Guids at build time, as required for ProductCode. I have come across issues when the original product was installed with lowercase ProductCode or UpgradeCode, and that was because it seems that some of the searches related to these are case-sensitive. Unlikely, however.
The way I have solved it was setting the predefined REINSTALL and REINSTALLMODE properties manually like this...
<Product>
<!-- ... your code ... -->
<SetProperty Id="REINSTALL" Value="ALL" After="FindRelatedProducts">Installed AND REMOVE<>"ALL"</SetProperty>
<SetProperty Id="REINSTALLMODE" Value="omus" After="FindRelatedProducts">Installed AND REMOVE<>"ALL"</SetProperty>
<!-- ... your code ... -->
</Product>
... where omus refers to these codes:
o : Reinstall if the file is missing or is an older version.
m : Rewrite all required registry entries from the Registry Table that go to the
HKEY_LOCAL_MACHINE
or
HKEY_CLASSES_ROOT
registry hive.
u : Rewrite all required registry entries from the Registry Table that go to the
HKEY_CURRENT_USER
or
HKEY_USERS
registry hive.
s : Reinstall all shortcuts and re-cache all icons overwriting any existing shortcuts and icons.
You can also use e or a instead of o:
e : Reinstall if the file is missing, or is an equal or older version.
a : Force all files to be reinstalled, regardless of checksum or version.
(Taken from Microsofts development center here)
The answer is: For some strange reasons, the Upgrade-Code that is listed in my version of the 'Advanced Installers' UI, is NOT the actual upgrade-code. Using orca revealed the one from the UI (which I was using) as well as a different one (which was not shown in the UI).
Changing the upgrade code in the wix source so it uses the "other" Upgrade-Code worked.
Note: I could not find Orca on microsoft.com. MSDN has several references to it, and it's supposed to be part of the Windows SDK, but it's not. I used an alternative download site which still had a copy.
We have created a WIX installation MSI that installs certificates to machine store. It installs a root certificate (GoDaddy Class 2 Certification Authority) to the Trusted Root Certification Authorities. It works for most of machines, but it fails some machines. We suspected the group policy restrictions(
http://technet.microsoft.com/en-us/library/cc754841.aspx), but the change did not resolve the problem. Below is a WIX definition and a portion of the log file that shows where the error occurs.
<DirectoryRef Id="ApplicationDirectory">
<Component Id="G.Root.Cert" Guid="{C6672075-1BFB-4158-86B4-8DD6D26BBC12}">
<CreateFolder />
<iis:Certificate Id="GoDaddy.Class2.Certificate"
Name="GoDaddy Class 2 Certificate"
Request="no"
StoreLocation="localMachine"
StoreName="root"
Overwrite="no"
BinaryKey="GoDaddy.Class2.Binary"
/>
</Component>
MSI (s) (B4:08) [11:58:21:952]: Executing op: CustomActionSchedule(Action=RollbackAddMachineCertificate,ActionType=11521,Source=BinaryData,Target=**********,CustomActionData=**********)
MSI (s) (B4:08) [11:58:21:953]: Executing op: ActionStart(Name=AddMachineCertificate,,)
Action 11:58:21: AddMachineCertificate.
MSI (s) (B4:08) [11:58:21:953]: Executing op: CustomActionSchedule(Action=AddMachineCertificate,ActionType=11265,Source=BinaryData,Target=**********,CustomActionData=**********)
MSI (s) (B4:40) [11:58:21:980]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI3EE3.tmp, Entrypoint: AddMachineCertificate
MSI (s) (B4:D0) [11:58:21:981]: Generating random cookie.
MSI (s) (B4:D0) [11:58:21:982]: Created Custom Action Server with PID 9920 (0x26C0).
MSI (s) (B4:90) [11:58:22:042]: Running as a service.
MSI (s) (B4:90) [11:58:22:043]: Hello, I'm your 32bit Elevated custom action server.
AddMachineCertificate: Deleting certificate that begin with friendly name: GoDaddy Class 2 Certificate_wixCert_
AddMachineCertificate: Adding certificate: GoDaddy Class 2 Certificate_wixCert_1
AddMachineCertificate: Error 0x80070005: Failed to add certificate to the store.
MSI (s) (B4!0C) [11:58:22:173]: Note: 1: 2205 2: 3: Error
MSI (s) (B4!0C) [11:58:22:173]: Note: 1: 2228 2: 3: Error 4: SELECT Message FROM Error WHERE Error = 26352
The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 26352. The arguments are: -2147024891, ,
MSI (s) (B4!0C) [11:58:27:816]: Note: 1: 2205 2: 3: Error
MSI (s) (B4!0C) [11:58:27:816]: Note: 1: 2228 2: 3: Error 4: SELECT Message FROM Error WHERE Error = 1709
MSI (s) (B4!0C) [11:58:27:816]: Product: Netsmart VR BA Prerequisites -- The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 26352. The arguments are: -2147024891, ,
AddMachineCertificate: Error 0x80070005: Failed to install certificate.
AddMachineCertificate: Error 0x80070005: Failed to install per-machine certificate.
CustomAction AddMachineCertificate returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 11:58:27: InstallFinalize. Return value 3.
MSI (s) (B4:08) [11:58:27:961]: User policy value 'DisableRollback' is 0
MSI (s) (B4:08) [11:58:27:962]: Machine policy value 'DisableRollback' is 0
MSI (s) (B4:08) [11:58:27:972]: Executing op: Header(Signature=1397708873,Version=500,Timestamp=1163681610,LangId=1033,Platform=0,ScriptType=2,ScriptMajorVersion=21,ScriptMinorVersion=4,ScriptAttributes=1)
We are puzzled as to what causes this problem. If you have any idea as to what causes this problem, it would be greatly appreciated.
Thanks.
We ran into the same problem, and sometimes it was because the user had the key already in the personal store. WiX doesn't seem to be smart enough to overwrite the key from other stores of a "higher" level (or overwrite at all -- not sure if it is a bug or not).
I would check to see if that certificate was already installed at the user level.
I had a similar problem with installing Basler Pylon 5.x software which uses WiX installer. With some help of Joe's answer I confirmed the failing machine had the certificate Microsoft Root Certificate Authority 2011 installed without a friendly name.
So I set the correct friendly name (MicrosoftRootCertificateAuthority2011.crt_wixCert_1) with this powershell command and the install succeeds:
(Get-ChildItem -Path Cert:\LocalMachine\Root\8f43288ad272f3103b6fb1428485ea3014c0bcfe).FriendlyName = 'MicrosoftRootCertificateAuthority2011.crt_wixCert_1'
So, I have a product installer authored using WiX which is failing to upgrade correctly once the 'Microsoft_VC100_CRT_x86.msm' merge module is incorporated. The old product is not removed during the installation. If the merge modules are removed from the project the removal of the old version takes place as it should.
The merge module is included quite simply under a Directory node:
<Directory Id="ProgramFilesFolder">
<Merge Id="VC10_CRT_MergeId1" Language="0" SourceFile="c:\\Program Files (x86)\\Common Files\\Merge Modules\\Microsoft_VC100_CRT_x86.msm" DiskId="1" />
... other stuff
</Directory>
and then referenced in the features:
<Feature Id="MainFeature" Title="Core Files" Level="1">
<MergeRef Id="VC10_CRT_MergeId1" />
... other stuff
</Feature>
I am incrementing the version number of the product but the upgrade fails to happen and the new version is installed over the old version but without performing a correct upgrade - both versions are listed in 'Add or Remove Programs'.
The old product should be removed as follows:
<InstallExecuteSequence>
<RemoveExistingProducts After='InstallValidate'/>
</InstallExecuteSequence>
I have also tried various other positions for RemoveExistingProducts as per http://jpassing.com/2007/06/16/where-to-place-removeexistingproducts-in-a-major-msi-upgrade/, with the same results.
In the verbose log for the installer the following is seen:
MSI (s) (AC:44) [19:48:22:300]: Doing action: RemoveExistingProducts
MSI (s) (AC:44) [19:48:22:300]: Note: 1: 2205 2: 3: ActionText
Action start 19:48:22: RemoveExistingProducts.
MSI (s) (AC:44) [19:48:22:300]: Note: 1: 2205 2: 3: Error
MSI (s) (AC:44) [19:48:22:300]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 22
MSI (s) (AC:44) [19:48:22:301]: Note: 1: 2205 2: 3: Error
MSI (s) (AC:44) [19:48:22:301]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 23
MSI (s) (AC:44) [19:48:22:301]: Note: 1: 2205 2: 3: Error
MSI (s) (AC:44) [19:48:22:301]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 16
MSI (s) (AC:44) [19:48:22:301]: Note: 1: 2205 2: 3: Error
MSI (s) (AC:44) [19:48:22:301]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 21
Action ended 19:48:22: RemoveExistingProducts. Return value 1.
In the WiX build log I get the following (but from memory this is normal with the VC runtime msms?):
1>light.exe(0,0): warning LGHT1076: ICE82: This action SystemFolder_x86_VC.F1DD796A_B984_3DCA_A68D_6B352BDC86F3 has duplicate sequence number 1 in the table InstallExecuteSequence
1>light.exe(0,0): warning LGHT1076: ICE82: This action SystemFolder_x86_VC.F1DD796A_B984_3DCA_A68D_6B352BDC86F3 has duplicate sequence number 1 in the table InstallUISequence
1>light.exe(0,0): warning LGHT1076: ICE82: This action SystemFolder_x86_VC.F1DD796A_B984_3DCA_A68D_6B352BDC86F3 has duplicate sequence number 3 in the table AdminExecuteSequence
1>light.exe(0,0): warning LGHT1076: ICE82: This action SystemFolder_x86_VC.F1DD796A_B984_3DCA_A68D_6B352BDC86F3 has duplicate sequence number 3 in the table AdminUISequence
1>light.exe(0,0): warning LGHT1076: ICE82: This action SystemFolder_x86_VC.F1DD796A_B984_3DCA_A68D_6B352BDC86F3 has duplicate sequence number 3 in the table AdvtExecuteSequence
The InstallExecuteSequence in the msi looks like the following:
If the merge module is removed (it needs to be included due to updated files in the installer) then the upgrade works as expected. Is this a bug in the merge module stuff/WiX/Windows Installer, or am I doing something wrong?
You're not getting any error messages on the upgrade? It goes through but you're left with two Add/Remove entries and a messed up file system? It sounds like your two versions don't share the same upgrade code.
If you're trying to do a minor upgrade, RemoveExistingProducts won't be triggered. Files should be updated but you'll keep one Add/Remove entry.
If you're trying to do a major upgrade that will trigger RemoveExistingProducts, but you need to set up the Upgrade element correctly.
Also, as a tip, don't use the merge modules. Due to how Windows Installer component rules work, on a minor upgrade you cannot remove the components the merge module adds. You would need to introduce a major upgrade. (Or add all the component codes from the old merge module to your project by hand. Not fun.) Depending on how all your stuff is set up, forcing a major upgrade could be a big hassle.
You'll run into this if you add the merge module and later need to remove it. Or if you want to replace say the VS 2010 module with the VS 2012 one. MS even broke component rules between service packs once. It's much easier to install them by running the vcredist*.exes during or before your product's install.
Have you found the problem yet? Check if the version of merge modules you are adding is older than that already existing on the system you are installing. In that case, the MSI would remove the VC++ files but not put the new ones down because they were older.
Edit: I found the solution to your problem!!
you should be using:
RemoveExistingProducts After="InstallFinalize
Refer: http://blogs.msdn.com/b/astebner/archive/2007/02/08/assemblies-may-be-missing-from-the-gac-or-winsxs-cache-after-an-msi-major-upgrade.aspx
I had the same issue and changing this fixed it.