2 Answers
2

This gets remoted over to the unmanaged C++ side where they invoke MsiGetProperty and MsiSetProperty. It's kind of like VBScript Session.Property("SUPPORTDIR") only simpler.

InstallShield should have scheduled a custom action called ISSetupFilesExtract. Log your install and see if it's executing and assigning the path to the property.

The only other gotcha I can think of is if you are doing a proper UAC story of non-elevating your UI but then elevating your Execute sequence, make sure that SUPPORTDIR is listed in the SecureCustomProperties property. Only "Secure" properties that get a value in the UI sequence are carried over to the execute sequence. "PUBLIC" properties will default back to whatever then were when the installer started executing.

I can tell you that I use SUPPORTDIR ( sometimes directly and sometimes via CustomActionData serialization) in my DTF custom actions and I have no problems with it.

There is no ISSetupFilesExtract. I've read on Flexera's board that I just need to add/re-add the support files to fix this. I did that but still no ISSetupFilesExtract.
–
IanJan 14 '11 at 10:06

This is stupid. I got it now. I was adding files under "Advanced Files" (Disk 1). I am not putting it on the "Language Independent" node. Question: What's the difference between the two?
–
IanJan 14 '11 at 10:33

1

Disk1 just teaches the build engine to stage those files at the root of the media. Useful for dropping readme.txt or packages you want to make available to the user but you don't want to automate as a prereq ( Think a game that puts DirectX on the CD ).
–
Christopher PainterJan 14 '11 at 11:54

An object of Session class is passed to the custom action in DTF. Use session["SUPPORTDIR"] to access the property value (for immediate action). For deferred action, you'll have to pass it via CustomActionData. Also, for immediate CA, make sure you scheduled the action which reads SUPPORTDIR after CostFinalize - the point when all entries in Directory table become accessible as properties.