Invalid MSI handle passed to deferred InstallScript custom actions?
I recently converted a BasicMSI project from IShield 11 to IShield 2009, i.e. across the border of major IScript engine architecture changes introduced by IShield ... 12 it was I think. In there I have an IScript CA of execution type "deferred in system context", scheduled after DuplicateFiles action in the Exec sequence, which makes use of the passed MSI handle calling MsiGetFeatureState(hMSI,...) for instance. While this worked perfectly with IShield 11 I'm now facing the challenge that the MSI handle passed by IShield 2009 appears to be invalid, i.e. MsiGetFeatureState() returns ERROR_INVALID_HANDLE (6). This is not the case for other CA's which are of Immediate execution type. This ugly behaviour matches somehow my understanding of the architecture changes which took place, but ... what now, how to deal with it? :confused: I didn't find any hint in the documentation or here so far. This handle is no MSI property so all the conversion hints about their new special treatment for deferred CAs don't apply. By the way, as expected ISMSI_HANDLE gives the same result.
I tried various things, and now comes another surprise: After switching this CA to Immediate In-Script execution it suddenly worked again (well half-way, due to the loss of the system context) though the action works on files being installed to the target system! :eek: From my understanding, this contradicts to every piece of MSI or IShield documentation about the Immediate vs. Deferred In-Script execution, and I know that the "Immediate" setting didn't work at all before (IShield11) for this action because the files were not yet installed, now they are. Does someone has an explanation for this behaviour? And hopefully a work-around for me? 😉
Generally you want two custom actions. One to run immeadiate to make your API calls, access properties, process business rules and another to make the actualy system configuration changes. The former communicates to the later via the CustomActionData property.
Google "InstallScript CustomActionData" and the first few hits are some discussions/examples that I've published.
Thanks a lot, Christopher, for pointing me to these topics, with the help provided by you mastering the challenge was no big deal anymore. 🙂 Well, primarily one doesn't want 2 CAs, eventually many extra properties and dealing with this CustomActionData stuff I think, just to obtain a little piece of MSI information ... but okay, unfortunately it seems to be necessary. I just can subscribe to all the posted wishes that InstallShield would finally provide more attempts to ease the pain of this issue which obviously are claimed but not addressed since so many versions. 😞
Windows Installer requires this. IS 12 and newer actually respects Windows Installer design practices. The previous versions did very wonky things that got around all of this.
For sure I copy to this point, being no friend of global variables either. But I mean helpers like your CAD parser function (btw, I modified there the nstart check to be if( nStart >= nLengthAttributePrefix ) for the case where the first StrFindEx() returns -1, isn't this else a bug?), couldn't there be one in InstallScript? Or somebody else suggested some special CA(-wizard) preset in order to automize a bit the required naming connection between the immediate/deferred pair...all this is pretty error-prone.
I haven't looked at that code in a long time ( I don't do much InstallScript these days ) but I do recall someone mentioning there was a parsing bug and they fixed it. I don't think that fix ever got posted back to InstallSite.
These days I use WiX's C#/DTF custom actions. The interop has a CustomActionData class that acts as a key/value dictionary with built serialization and deserialization methods. Way easier...
