Automatic account creation is now enabled. Captcha authentication required for account creation and editing unless you are trusted here.

Messy Custom Actions

From WiX Wiki at MindCapers

Jump to: navigation, search

Contents

Intro

All about Custom Actions ...

http://www.codeproject.com/tips/msicustomaction.asp http://msdn2.microsoft.com/en-us/library/aa370134.aspx



Undo Custom Action

I have to write my own 'undo' Custom Action, that only runs during uninstall. The reason why these actions are safe, is because the command prompt will execute the command, and report an error (which the user is unable to see) - so there are essentially 2 cases: a) the ExeCommand in the CA succeeds, or b) the CA in the ExeCommand fails. In my case, it doesn't matter in either case, because if the COM .dll is registered, it'll be unregistered, and if the COM .dll is not registered (this must also mean that someone did something bad), the ExeCommand will still allow WIX to finish its uninstallation procedure. Here is my solution: 

 
    <CustomAction Id='Uninstallation' Directory='INSTALLDIR' Win64='no'
           ExeCommand='"[WindowsFolder]Microsoft.NET\Framework\v2.0.50727\regasm.exe" /unregister "[ProgramFilesFolder]MyCompany\MyProduct\MyLibrary.dll"'
           Return='check' />
 
    <InstallExecuteSequence>
        <!-- Only run before uninstallation -->
        <Custom Action='Uninstallation' Before='RemoveFiles'>Installed AND NOT REINSTALL</Custom>
    </InstallExecuteSequence>
 

Notice that I run the 'uninstallation' CA only during uninstall, and not reinstall - you can change this behavior to your needs.




Machine State

Writing CustomActions that modify machine state is rarely an easy task. Transactions (even compensating transactions) are hard things to get right. Reference counting is similarly difficult. Trivializing the effort to get a CustomAction correct reduces that chances that we keep end users machines stable when they install our software.

Debugging Custom Actions

Was the error in the custom action itself? If so, then you can always try to debug the custom action in Visual Studio. I was able to do this by adding a MessageBox to the beginning of the custom action and then attaching to the MessageBox when the custom action was run. If the error was when launching the custom action, there may be a missing dependency.


Browser Control

> I want to show a link on an installer dialog so that when a user > clicks on that link, the browser should open with the URL. How can I > achieve this functionality? >

MSI doesn't support hyperlink controls. You can approach it using a PushButton control and the WiX v3 ShellExec CA.

Setting TARGETDIR to a root directory 

 
 <CustomAction Id="AssignTargetDir" Property="TARGETDIR" Value="C:\" Execute="firstSequence" />
 <InstallUISequence>
   <Custom Action="AssignTargetDir" Before="CostInitialize">TARGETDIR=""</Custom>
 </InstallUISequence>
 <InstallExecuteSequence>
   <Custom Action="AssignTargetDir" Before="CostInitialize">TARGETDIR=""</Custom>
 </InstallExecuteSequence>
 

Starting Application after installation

I am looking for a way to kick start the application after it has been installed. The application start consists of running an executable.

> 2. Immediate. Trying to invoke the app via QtExecCmdLine. However, the application does not start if I use this method.

Immediate custom actions don't have access to installed files, unless they're after InstallFinalize, and with that deferred one you just need to set the Wix magic that says "don't wait" - that's why the MSI is waiting for it to complete.

MSIHandle

Ok, my custom action function gets a parameter called MSIHandle. What should or could I do with this?

MsiCreateRecord

MsiGetProperty

UINT uiStat = MsiGetProperty(hInstall, strName, szValueBuf, &cchValueBuf);

MsiProcessMessage

MsiRecordSetString


Custom Actions and Execution Sequences

InstallUISequence typically runs in its entirety before InstallExecuteSequence is processed (the execute sequence is processed by the ExecuteAction action). You can't set a property in the execute sequence and expect its value to appear in the UI sequence. You should schedule your custom action in the UI sequence before your Show action.

Public properties are copied from the client process to the server process, but not in the other direction, which is I think what you're trying to do here.

If you need the property in the execute sequence as well, it needs to be a public property (ALLCAPS, as this one is), and you should schedule the custom action in the execute sequence as well so that your install still works in no-UI mode (msiexec /qn). If you want it only to run once, set CustomAction/@Execute to "firstSequence".

License scrolling sample

checks if the user has scrolled the Licence window to its end

More Help

1) If you've got an existing MSI you're converting to Wix, use the Wix tools (Dark) to decompile it into Wix markup.

2) Very handy Custom Action Type Calculator on the InstallShield web site makes the guess and test go much quicker. (Needs IE, doesn't work in Firefox for me.) http://helpnet.installshield.com/robo/projects/helplibdevstudio9/IHelpDLLFunctionCalcType.htm

3) The Custom Action Reference on MSDN provides the real info on the flag values. (http://msdn2.microsoft.com/en-us/library/aa368070.aspx) You break your known type into its component pieces. Note that you seem to have to step through a bunch pages to find everything you're looking for (types, scheduling options, etc.) - maybe there's a page somewhere that has them all on one page?

Retrieved from "http://wix.mindcapers.com/wiki/Messy_Custom_Actions"
Personal tools