Showing results for 
Show  only  | Search instead for 
Did you mean: 
Level 7

CustomActionData (in basic MSI) broken in IS 2012?

I have a basic MSI project where I implemented the technique recommended by Christopher Painter (see thread:

This worked perfectly fine in IS 2011. I'm on 2012 now and have added some things to the project, but have not really touched the script code and custom actions in place for using CustomActionData. However, now it seems to be broken (I added Messageboxes in both the immediate and commit CA's to check... strings are fine when setup for the CustomActionData, but then are empty when retrieved in the commit CA's.

I did add some conditional Set Directory CAs for a new product config, but I checked both in the new PC and the original (where the Set Directory actions are skipped), and still no CustomActionData is being retrieved.

Does anyone have ideas about what may be going on? Has anyone else seen this in moving from IS 2011 to IS 2012?

Thank you.
Labels (1)
0 Kudos
(9) Replies
Level 17

Have you tried creating a Windows Installer verbose log for your installation and checking if the value of the property having the same name as your deferred execution custom action is set as expected? Your verbose log should have an entry like this:

Property(S): DeferredActionName = xxxxxxxxxx
0 Kudos
Level 7


Everything looks fine in the verbose logs. For instance, I have these lines:

MSI (s) (F8!84) [15:07:22:902]: PROPERTY CHANGE: Adding InvokeRegistration property. Its value is '{all the data I expect to see}'.

then much later in the log:

MSI (s) (F8:FC) [15:07:51:479]: Executing op: ActionStart(Name=InvokeRegistration,,)
MSI (s) (F8:FC) [15:07:51:479]: Executing op: CustomActionSchedule(Action=InvokeRegistration,ActionType=1601,Source=BinaryData,Target=f4,CustomActionData= {all the data I expect to see})

I double-checked that my custom action (and Installscript function) was named correctly, "InvokeRegistration"

Trying to narrow this down further, the ISScript function calls a helper function which is supposed to parse the Data to return a single parameter among the packed data. Early in the function the data is supposed to be retrieved with this call:

nResult = MsiGetProperty( hMSI, "CustomActionData", sBuffer, nSize );

I put a message box right after that and found that sBuffer is empty.

I tried the same experiment in the original script function called directly by the CA, and same result, empty string returned.

Again, this worked fine in IS 2011.

Note that the later CA's use CommitExecution, while many of the posts mention DeferredExecution. When I first worked on this last year, I remember having a reason to switch to Commit from Deferred, but I don't recall now what that reason was. Is it possible this is only broken in 2012 for CommitExecution? Is this an unrecommended practice? Thanks.
0 Kudos
Not applicable

Hi BrHartmann

Please see InstallShield 2012 release notes:

"IOA-000060069 (Basic MSI, InstallScript MSI, Merge Module)
If you use an InstallScript custom action that calls a Windows Installer API such as MSIGetProperty, the function can now return a property value that contains the same number of characters that the Windows Installer API supports, rather than a limit of 2,047 characters."

Hope that helps.

0 Kudos
Level 7

Kevin, thanks for the tip. However, it sounds like the functionality of MSIGetProperty should be enhanced then, not broken. I was nowhere near 2047 characters regardless. The IS help does not seem to indicate that MSIGetProperty should have different arguments in 2012 vs. earlier, so I'm not sure what I should be changing. Further advice on solving this problem would be appreciated.
0 Kudos
Level 12

What's the value of nSize at the time of function call? Empty sBuffer string right after MsiGetProperty sugggests nSize might be 0.
BrHartmann wrote:
nResult = MsiGetProperty( hMSI, "CustomActionData", sBuffer, nSize );

I put a message box right after that and found that sBuffer is empty.
0 Kudos
Level 8

I read a post, that in IS-2012 you have to specify the buffersize for MsiGetProperty before each call to MsiGetProperty. In the past this was not necessary. So may be that's the reason why your code works in IS-2011


0 Kudos
Level 7

Thank you both, nSize was the culprit, so my code is working now 🙂

In case anyone is curious about the post (or one at least) which discusses this change in more detail (and provides a sample function to wrap MsiGetProperty):
0 Kudos
Level 2

Thanks for this post as it resolved my problem as well!
0 Kudos
Level 16

I just discovered this today myself as I haven't been using IS2012 and/or InstallScript custom actions these days. ( Pretty much all C# DTF now. )

This seems pretty craptastic to me that InstallShield changes the behavior of their wrapper of MsiGetProperty that's been the same for a good 10+ years.

What's next? Malloc()? InstallScript is supposed to be a higher level langauge then C/C++.
0 Kudos