A type 2 Custom Action is failing to execute on InstallUISequence while it is executed if put on InstallExecuteSequence - wix

I have a Type 2 Custom Action which is executing an executable file with parameters.
I need to execute this CA before InstallWelcome dialog because it is used to collect some information to pre populate a dialog later.
So I sequenced this CA after CostFinalize action in the InstallUISequence but the installer fails to execute it with an error like below.
If I move the CA in the InstallExecuteSequence sequence it is executed as expected. (As explained in a later comment this is not true, it fails also in this sequence).
Does anyone have any idea what might happened?
Maybe useful information: If same executable is used in a Type 18 Custom Action (the executable is installed with the application's binaries) it is executed without problem.
<CustomAction Id='RunEXE' BinaryKey='EditCfg.exe.CA.ID' ExeCommand='[INSTALLFOLDER][SEPARATOR][CONFIG_FILE_NETWORK_LOCATION][SEPARATOR][USER_NAME][SEPARATOR][PASSWORD][SEPARATOR][WIX_UPGRADE_DETECTED][SEPARATOR][CHECKED_RULE][SEPARATOR][CERTIFICATE_LOCATION]' Execute='immediate' Impersonate='no' Return='check' />
<Binary Id='EditCfg.exe.CA.ID' SourceFile='path_to_the_exe_file'/>
MSI (c) (14:04) [15:18:36:452]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1722
Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor. Action RunEXE, location: C:\Users\yyyyy\AppData\Local\Temp\MSIC8A9.tmp, command: param1§param2§param3§§param5§§param7

The 1722 error indicates that the exe returned a non-zero exit code. If this is expected, you can alter the Return attribute to use ignore instead of check. But if it's not expected, you probably need to figure out what that return code indicates, as odds are high that it's some sort of failure.
Here are a couple things that might cause failures:
The exe file may have some dependencies. Putting just the exe in the binary table doesn't carry its dependencies with it, so attempts to load and run the exe may fail, even before it gets to the exe's main code, depending on the kind of dependency.
When executed as a file installed with the product, the file may not exist in the specified location as of the time the custom action executes. During installation, new files do not show up until a deferred/in-script action after InstallFiles (or regular scheduling after InstallExecute); during uninstallation they often disappear by RemoveFiles. Maintenance can be a combination of those. However, a missing exe would likely result in a 1721 error instead of a 1722 error.
Regardless, note that exe custom actions cannot communicate useful data back to the Windows Installer session, so it will be difficult to leverage any data it finds (or creates) in the UI without the help of additional DLL-based actions or system searches. If you also add a DLL-based action, you may find it more friendly to launch the exe from that action (or even fully incorporate what it does into the dll), as you can log better diagnostics than the generic ones you've seen here.

Related

Launch condition in WIX to check advertise mode

I am running my MSI from command prompt with /jm option. I want to add a LaunchCondition in my WIX file to check whether the MSI is triggered with /jm option.
Thanks in advance.
https://wixtoolset.org/documentation/manual/v3/xsd/wix/advertiseexecutesequence.html
Try using the AdvertiseExecuteSequence tag. You can create an error action to prevent any advertised installations from taking place. Just place the error at the beginning of the sequence.
Initialize the error action:
<CustomAction Id="ErrorMessageId" Error="Insert error message here"/>`
Run the error action:
<AdvertiseExecuteSequence>
<Custom Action="ErrorMessageId" Before="CostInitialize"/>
</AdvertiseExecuteSequence>
Every feature can go into advertised state. One easy way would be to edit the .msi, if possible and add the "msidbFeatureAttributesDisallowAdvertise" (8) and maybe the "msidbFeatureAttributesUIDisallowAbsent" (16) attribute to the MSI feature table. (I don't work with WiX so you will find out yourself).
Another way would be to add a custom action who controls if the ADVERTISE property is nonempty and just abort the installation.
Changing the feature action from advertise to install local would be quite tricky but maybe possible.
If you have a path (.msp) there are other ways to protect it from being installed with features in advertised mode.

Error repairing setup created in WiX 3.8

I have created a Web Server setup in WiX (3.8), It gets installed correctly, but when i Repair it, I get an error 'Fatal error during Installation' and the process is rolled back. below is what i see in logs
MSI (s) (F8:C4) [12:39:26:183]: Executing op: CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,Source=BinaryData,Target=**********,CustomActionData=**********)
MSI (s) (F8:F8) [12:39:26:188]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI7B14.tmp, Entrypoint: WriteIIS7ConfigChanges
WriteIIS7ConfigChanges: Error 0x80070002: Site not found for create application
WriteIIS7ConfigChanges: Error 0x80070002: Failed to configure IIS application.
WriteIIS7ConfigChanges: Error 0x80070002: WriteIIS7ConfigChanges Failed.
CustomAction WriteIIS7ConfigChanges returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 12:39:26: InstallFinalize. Return value 3.
Am i missing out something. Any help is appreciated, Thanks in Advance :)
If it's a repair and the site name is missing, chances are that it was entered in a UI dialog in the original install. In a repair there is no UI to re-enter the site name and properties aren't automatically saved. It may be trying to configure a site with no name. The best way to deal with this type of thing in general is to use the WiX remember property pattern on the site name so that it is preserved and is available for a repair. I can't tell if that would be a good thing in this particular case because I don't know if writing the config changes again on top of the existing config changes will work or be handled correctly by the code. A verbose log of the original install should tell you what property names are being used for site names etc.
If you think it's unlikely that the IIS config changes will break and that they won't need repair, you could consider adding "Not Installed" to the condition on the CA so that a repair won't call it.

Re-cached msi still running old custom action

I have made a change to a custom action in my msi file to not attempt to stop a windows service if the service is stopped or stop pending. However, after re-caching the msi using msiexec /fv mymsi.msi, when running the major upgrade to the next version (which also has the corrected service stopping custom action) the verbose logging is showing that the old custom action code is still being run even though the cached msi was updated. I even ran a binary comparison of the cached msi against the one that was used in the re-caching.
What am I doing wrong here.
If the old custom action is still running it means one of two things:
The new MSI logic is not correct and is still running the custom action.
The recache/reinstall did not work.
To re-cache/reinstall make sure your MSI is basically identical (same ProductCode/Upgradecode etc) to the old MSI except with the updated custom action. Then do:
msiexec /fv new.msi /l*v log.txt
That will overwrite the old MSI and do a repair using the new MSI (and give you a log file in case anything goes wrong).
In my case it was a cached copy of my MSI in %windir%\Installer and corresponding keys in the system registry (found them by GUID in HKLM and HKCR).

Wix custom-action dll relies on files installed at execution

I'm using a dll to install a driver that's packaged inside the msi. When I schedule the custom-action for after InstallFinalize it succeeds, but if I schedule it either 1) after InstallFiles 2) after InstallFiles, execute=deferred, 3) after InstallFiles, execute=deferred, impersonate=no, or 4) before InstallFinalize it fails with "file not found" for the .inf file.
I've read This SO post and this page, but still don't understand how I get my driver to be installed.
If I use after InstallFinalize then if for some other reason an error is returned it's too late to abort the installation and it's botched.
According to this answer to the question you linked, you should schedule it after InstallFiles and make it deferred.
Enable verbose logging during your installation, and you'll be able to see when files are copied to the hard drive and when your custom action is called.
After InstallFinalized, your installation is already complete.

WIX CustomAction - how to get more info in install/log

Someone told me there was a way for the CustomAction in WIX to display the output in the console log. I'm including an .exe called XmlPreprocess.exe to manipulate my web.config, based on parms in a file called SettingsFileGenerator.xml,
I'm running like this:
msiexec /i bin\Debug\TFBIC.RCT.WCFWebServicesWIXSetup.msi /L*V "C:\logs\WixInstall01.log"
This is my WIX build file:
<CustomAction Id="**SAMPLE_CONFIG**" BinaryKey="XMLPREPROCESS" ExeCommand="/i:"[INSTALLLOCATION]web.config" /x:"[INSTALLLOCATION]SettingsFileGenerator.xml" /e:QA /d:ServiceLocation=[SERVICELOCATION]" Execute="deferred" />
<Binary Id="XMLPREPROCESS" SourceFile="../TFBIC.RCT.WCFWebServices/RequiredBins/XMLPreprocess.exe" />
<InstallExecuteSequence>
<Custom Action="SAMPLE_CONFIG" After="StartServices"><![CDATA[NOT Installed]]></Custom>
</InstallExecuteSequence>
Install log shows this:
Action 15:22:27: StartServices. Starting services
Action start 15:22:27: StartServices.
MSI (s) (58:CC) [15:22:27:898]: Note: 1: 2205 2: 3: ServiceControl
MSI (s) (58:CC) [15:22:27:898]: Note: 1: 2228 2: 3: ServiceControl 4: SELECT `Name`,`Wait`,`Arguments`,`Event`, `Action` FROM `ServiceControl`, `Component` WHERE `Component_` = `Component` AND (`Action` = 0 OR `Action` = 1 OR `Action` = 2)
Action ended 15:22:27: StartServices. Return value 1.
MSI (s) (58:CC) [15:22:27:899]: Doing action: SAMPLE_CONFIG
Action 15:22:27: SAMPLE_CONFIG.
Action start 15:22:27: **SAMPLE_CONFIG**.
SAMPLE_CONFIG:
Action ended 15:22:27: **SAMPLE_CONFIG**. Return value 1.
This is my very first attempt to do WIX, so please bear with my ignorance.
Thanks
UPDATE:
This is a quote from another forum - but he doesn't specify how it works and he doesn't seem to check back often.
WiX has a custom action that captures
the console output and sticks it
directly into the verbose MSI log, so
that's what I use.
reference: http://xmlpreprocess.codeplex.com/Thread/View.aspx?ThreadId=79454
Would this be the tool he is talking about?
http://wix.sourceforge.net/manual-wix2/qtexec.htm
I get this error when trying it:
error LGHT0103: The system cannot find the file 'wixca.dll'.
I have searched entire disk for this .dll and could not find it.
To enable all possible logging while installing an msi, use the /lvx* logfile.txt option. However, even this will not log the STDOUT and STDERR output of command line applications invoked as a custom action.
If you have written the custom action yourself, you can add such logging to it. For example, the DTF libraries that come with wix have a handy Session.Log method that you can call. See c:\program files\windows installer xml v3\doc\dtf.chm, topic "Writing Managed Custom Actions" for more information.
If you have not written the application, you could write a custom action to wrap it. Such a wrapper could use the .NET Process class to invoke an executable, read the StandardError and StandardOutput streams, and log everything with the Session.Log method mentioned above.
edit: I don't know of any standard custom action in wix that sends console output to the log. Try the wix-users mailing list.
In Wix 3.10 you can use the Quiet Execution custom action to run an executable (silently, e.g. without a command window popup), and the console output will end up in the msi log.
As mentioned, you need the WixUtilExtension reference to get access to this feature.