When I'm building my MSI file, and I use a basic condition, the expected happens. For example, let's say that I have this in Setup File:
<Property Id="myProperty" Value="0"/>
<Condition Message="Value of myProperty is [myProperty], and it should be 1.">
<![CDATA[Installed OR myProperty = "1"]]>
</Condition>
If I build this and run the MSI file, it works -- that is, it displays the error message and quits.
Working condition when running MSI
However, if I put the MSI into a Bundle, it doesn't work. That is, when I put just this into my Bootstrapper ("Properties" below is the name of my Setup project -- bad name, I realize):
<Chain>
<MsiPackage SourceFile="$(var.Properties.TargetPath)"/>
</Chain>
And then I run the setup file, I get an error. When the installation starts, it checks the condition, gives me the expected message box (same as above), and then I get this error message:
Setup Failed
Looking at the Log, I get three error messages:
Error 0x80070643: Failed to install MSI package.
Error 0x80070643: Failed to execute MSI package.
Error 0x80070643: Failed to configure per-machine MSI package.
With the exit code:
Exit code: 0x643, restarting: No
I'm such a noob at WiX that I'm not even sure how to go about researching what the problem is -- I can't even ask an intelligent question. Hence, I'm reaching out to you kind folks!
(I'm using WiX 3.10 and Visual Studio 2015)
EDIT:
Thanks for getting back to me! I tried your suggestions:
In the installer file, I made the property public and I made it secure. I left the condition the same, and, since I don't think that I should get the value here as opposed to in the bootstrapper, I left the value of the property out. Here is the code that I made for the property/condition:
<Property Id="MY_PROPERTY" Secure="yes"/>
<Condition Message="MY_PROPERTY is [MY_PROPERTY]. Should be 1">
<![CDATA[Installed OR MY_PROPERTY = "1"]]>
</Condition>
Then, in the boostrapper file, I added a child element of and gave it a value:
<MsiPackage SourceFile="$(var.LCondErrorInstaller.TargetPath)">
<MsiProperty Name="MY_PROPERTY" Value="0"/>
</MsiPackage>
When I ran it, I got almost the same behaviour as I did before, except for one difference -- when I get the error message. This time, I get the pop-up screen with the Message condition and the same error message as I did before (see "Setup Failed" above), except this time I get it happens little later in the installation, making me think that the condition is, in fact, getting triggered in the bootstrapper.
As far as the log files, they look the same (I'm not sure how to get log files of the MSI when running the Burn file, what I do now is just run the Burn file with the flag "/l", like so: > file.exe /l logFile.log).
For clarity, here are the parts of the log file that appear to be important:
Error 0x80070643: Failed to install MSI package.
Error 0x80070643: Failed to execute MSI package.
Error 0x80070643: Failed to configure per-machine MSI package.
...
Exit code: 0x643, restarting: No
I should have been more specific when I initially asked the question about what kind of behaviour I'm looking for...
I will have more than just that one MSI file in the Burn file. What I want to do is this: when the Burn file installs, if there is a condition in one of the MSI files that is not met, I want that MSI file to simply not be installed, and the rest of the MSIs to be installed. I don't care about the UI.
If there's another way to do this, I'm all ears.
If you have launch conditions in the MSI you can replicate or move those launch conditions into the bootstrapper bundle itself to stop this type of behaviour.
Launch condition failure returns Fatal Error 1603 (0x643 in hex) which is what I would expect to see when the MSI launched by the bootstrapper fails due to launch condition not met.
You should see something like this in the msi's logs
Action ended 17:33:38: LaunchConditions. Return value 3.
MSI (c) (08:4C) [17:33:38:610]: Doing action: FatalError
Action 17:33:38: FatalError.
Action start 17:33:38: FatalError.
...
MSI (c) (08:4C) [17:33:41:188]: MainEngineThread is returning 1603
To elaborate, you would have to change your msi package definition to the following to get it to run properly through the bootstrapper
<Chain>
<MsiPackage SourceFile="$(var.Properties.TargetPath)">
<MsiProperty Name="MYPROPERTY" Value="1"/>
</MsiPackage>
</Chain>
Additionally if you want to pass in a property from your bootstrapper to your MSI the property must be a public property which is a property whose name is ALL CAPS.
If you want to use this property somewhere in the Install phase of your msi you must also mark this property as secure.
Related
We are using wix 3.9.1208.0 to generate MSI. Below code prepend the value to Upperfilters registry key.
<RegistryKey Id="UpperFilters" Root="HKLM" Key="xxxxxxxxx" Action="create">
<RegistryValue Name="UpperFilters" Type="multiString" Action="prepend" Value="xxxxx"/>
</RegistryKey>
After install observed, value not prepend to 'UpperFilters' registry key and not found any errors in MSI log. This issue happened only once.
MSI Log:
MSI (s) (0C:28) [10:38:08:835]: Executing op: ComponentRegister(ComponentId=xxxx,KeyPath=02:xxxxx,State=3,,Disk=1,SharedDllRefCount=0,BinaryType=0)
MSI (s) (0C:28) [10:38:24:455]: Executing op: RegOpenKey(Root=-2147483646,Key=xxxxx,,BinaryType=0,,)
MSI (s) (0C:28) [10:38:24:456]: Executing op: RegAddValue(Name=UpperFilters,Value=xxxxx[~],)
Is MSI returns any failures when unable to update registry?
Will all registry failures are recorded in MSI log?
What's the issue in my scenario?
Thanks in Advance.
It might help to show more from the log. It's hard to tell what's going on from those log fragments. ComponentRegister isn't typically next to RegOpenKey - it's just a register of the keypath in the registry and not related to the actual issue.
There are few things that could be wrong:
Why is the Component id xxxx? Have you hidden the actual guid when you posted the log information or is that what you actually used? It's not a legal id.
It's a 64-bit system and you tried to update the 32-bit registry. Without knowing the system bitness and your MSI's architecture we can't tell if you updated the required key.
Prepending doesn't really do anything if there is nothing in the existing data, so without seeing the data before and the data afterwards it's not clear if it worked correctly (because there was nothing to prepend to) or failed (because it did not actually prepend your data to the existing data).
Using WiX 3.6 I'm trying to create an MSI for silent installation of an in-house product.
One some machines, my installer works fine, but on others the installer fails with an error message indicating the property value hasn't been passed through from the UI phase to the Install phase of the process:
This error comes from a guard clause in my WiX source:
<Condition Message="The property SERVER must be defined on the commandline. Installation will abort.">
<![CDATA[Installed or SERVER]]>
</Condition>
Why is my Guard clause triggering even though I provide the property SERVER on the command line?
The installation commandline:
msiexec /i 'C:\work\Excel.2010(x86).msi' SERVER=fsis-app-server ENVIRONMENT=Production SKIN=Black
According to everything I can find by consultation with Professor Google, all I should need is to make my property public (by using all capitals for the name) and to mark it Secure="yes":
<Property Id="SERVER"
Secure="yes"/>
I've done this, but it's still not working - any ideas what I've missed?
Other details ...
... my installer is configured to run as a MajorUpgrade every time.
... I'm deploying exclusively to Windows 7. On my machine (which does have this problem), I have Windows Installer. V 5.0.7601.17514
... Most machines upgrade fine, but a handful (<10 out of 200) fail with this error. My machine is one (helpful for troubleshooting). The previous version is NOT listed under Programs and Features on this machine.
Update #1
Very interesting, reading the logs. My properties (e.g. SERVER) are not losing their values as the install progresses.
If I'm reading the log right, it seems my error in being shown by the previous MSI, not the one I'm currently running:
MSI (s) (D8:D0) [13:20:19:213]: Product: FSIS Plugin for Excel 2010 (32 bit) v4.7.1047.0 -- The property SERVER must be defined on the commandline. Installation will abort.
The installer I'm using is v4.8.9999.0, so the old version number is my clue as to what's happening ... though this doesn't match the v4.5.0.0 in my original screenshot.
Looks like I have two jobs ahead of me ...
... napalm the old installer to clean up this machine
... alter the installer to prevent recurrence.
Update #2
I've verified that my failure happens on UNinstallation.
<Condition Message="The property SERVER must be defined on the commandline. Installation will abort.">
<![CDATA[Installed or SERVER]]>
</Condition>
Why does this guard clause trigger and abort uninstallation?
I thought the point of having "Installed or" was to allow it to work properly when removing the product.
I have a bootloader that I created with WiX 3.6/Burn and was wondering if there was a command similar to <ExitCode Behavior="forceReboot"/> that would execute only on uninstall after everything was executed in the <chain> tag.
You can put the ScheduleReboot action in one of your MSIs and condition the action to run on unistall. Burn will respect the restart request and inform the user a restart is required at the end.
I already have the following line in my WiX setup to check if the current version is already installed:
<UpgradeVersion OnlyDetect='yes' Property='NEWPRODUCTFOUND' Minimum='$(var.ProductVersion)' IncludeMinimum='no' />
The MSI exits with a message and exit code "1638".
However, this MSI is part of a bootstrapper that chains multiple MSIs together - and I want the bootstrapper to continue and install the following MSIs.
How do I tell WiX/MSI to exit with exit code 0 and no message dialog?
I could modify the bootstrapper but would rather prefer to set the exit code to 0.
(The exact exit code is: ERROR_PRODUCT_VERSION - "Another version of this product is already installed. Installation of this version cannot continue. To configure or remove the existing version of this product, use Add/Remove Programs on the Control Panel.")
It seems WixExitEarlyWithSuccess Custom Action is what you need.
I'm installing a large app, and part of it is a custom written tool called "DbUpdateManager" to mass execute SQL scripts against our target database.
Right now, the WiX 2.x install works - but it has one flaw: during install, I also install a couple of Windows services, which can be optionally started right away. Those however will fail, if the DbUpdateManager hasn't been run yet.
So what I'm trying to accomplish is this:
Install DbUpdateManager and my services from my MSI
Run DbUpdateManager BEFORE any of the services start up
My current WiX source looks something like this:
<Directory Id='INSTALLDIR' Name='DbUpdMgr' LongName='DbUpdateManager' >
<!-- DbUpdateManager component with the necessary files -->
<Component Id='DbUpdateManagerComponent' Guid='...' DiskId='1'>
<File Id='DbUpdateManagerFile' LongName='DbUpdateManager.Wizard.exe'
Name='DbUmWz.exe' src='DbUpdateManager.Wizard.exe' KeyPath='no' />
</Component>
<!-- Component to install one of my Windows services -->
<Component Id='InstallServiceComponent' Guid='...' DiskId='1'>
<File Id='InstallServiceFile' LongName='MyService.exe'
Name='MyServic.exe' src='MyService.exe' KeyPath='yes'/>
<ServiceInstall Id='InstallMyService' Name='MyService'
Description='My Service' ErrorControl='normal'
Start='auto' Type='ownProcess' Vital='yes' />
<ServiceControl Id='UninstallMyService' Name='MyService'
Remove='uninstall' Wait='yes' />
</Component>
<!-- Feature for the DbUpdateManager referencing the above component -->
<Feature Id='DbUpdateManager' ConfigurableDirectory='INSTALLDIR'
AllowAdvertise='no' Description='DbUpdateManager' Level='1'
Title='Database Update Manager'>
<ComponentRef Id='DbUpdateManagerComponent'/>
</Feature>
<!-- Custom action for running DbUpdateManager -->
<CustomAction Id='RunDbUpdateManagerAction' FileKey='DbUpdateManagerFile'
ExeCommand='' Return='asyncWait' />
<!-- Calling the custom action in the install sequence -->
<InstallExecuteSequence>
<RemoveExistingProducts After='InstallInitialize' />
<Custom Action='RunDbUpdateManagerAction'
After='InstallFinalize'>&DbUpdateManager=3</Custom>
I inherited this WIX, and it works - but as I said - the DbUpdateManager gets called too late in the process (only "After=InstallFinalize") and thus the services will fail to start up properly at first (the run fine the second time around when you restart them manually after DbUpdateManager has run).
I poked around the MSI documentation a bit and found a nice step called "StartServices", so my hunch was to just change my calling the custom action to this:
<InstallExecuteSequence>
<Custom Action='RunDbUpdateManagerAction'
Before='StartServices'>&DbUpdateManager=3</Custom>
Unfortunately, in this case, nothing at all happens - DbUpdateManager NEVER gets called....
Any ideas why? Debugging the MSI/WiX stuff is really really tricky, and I can't seem to see the forest for the trees anymore....
Thanks!
Marc
EDIT: The "RunDbUpdateManagerAction" is placed in the right position in the InstallExecuteSequence table in my MSI - right AFTER InstallServices and just BEFORE StartServices - and yet it doesn't work.... DbUpdateManager (a Winforms utility) does not show up during installation :-(
EDIT 2: now my action appears to be executed and at the right time - unfortunately, I'm just not seeing my wizard :-( What I'm seeing is an error code "return value 1631" which means something like "MSI Service could not be started" - wtf ???
MSI (s) (2C:D8) [20:53:36:383]: Doing action: RunDbUpdateManagerAction
Action 20:53:36: RunDbUpdateManagerAction.
Action started at 20:53:36: RunDbUpdateManagerAction.
MSI (s) (2C:D8) [20:53:36:383]: Doing action: StartServices
Action 20:53:36: StartServices. Services are being started
Action started at 20:53:36: StartServices.
Action finished at 20:53:36: RunDbUpdateManagerAction. Return value 1631.
Well, I finally got it working - with a bit of help from everyone who responded, and by consulting some of the WiX tutorials and help pages out there on the web. MSI installer stuff isn't easy to figure out and learn......
Basically, I changed execution of my custom action to "deferred" (as suggested by Rob) and I moved the point in the sequence where it gets executed to "After=InstallFiles". I also changed the condition in the <Custom> tag to "NOT Installed" which seems to work just fine in my scenario.
Contrary to Rob's fear, the Db Update Manager and its UI come up quite nicely this way, and the process of updating our database is now completed before any of our services (that depend on the database) get started.
Looking forward to a full RTM release of WiX 3.0 (and its future) !
Thanks to everyone - unfortunately, I could only accept one answer - all would have deserved it.
Marc
It appears that your CustomAction depends on the 'DbUpdateManagerFile' being installed. That means that your CustomAction needs to be scheduled after InstallFiles executes. Remember there are two passes to the InstallExecuteSequence. First, the "immediate" (or "scheduled" or "script generation") actions are executed to build the transaction log (aka: "install script"). Second, the "deferred" actions in the transaction log are executed.
Right now your CustomAction is "immediate" (the default) so it is trying to run before the files are actually copied to the machine. The InstallFiles action is in the script before your CustomAction but it hasn't been executed yet.
So, you need to mark your CustomAction "deferred" to get it to run after your files are installed.
Note: you are not probably not able to show UI from a deferred CA. I wasn't sure if this tool of yours was expected to show UI.
PS: sorry if I didn't explain that well, it's been a long day.
Try getting a log file of the Installation, and look for the sequence order in there and the value of the condition to perform the Custom Action
Use this in the command line:
msiexec /i [msiname] /l*v [filename]
EDIT: After reading your comment have a look at this page here you could try to add NOT INSTALLED in the condition
EDIT2: I found this page Search for your error Number 1631
You can open the .msi in Orca and look at the InstallExecuteSequence table to see what order things are actually happening in. This may give you a good idea of what's actually happening when.