PDA

View Full Version : InstallScript CA - SUPPORTDIR Path Changes Between Custom Actions



EricJK
06-13-2006, 03:41 PM
I have many InstallScript CA's. I have 2 text files also placed in the Support Files - Language Independent.

I call the first InstallScript CA and refer to one of my text files using the SUPPORTDIR path and this is resolved to a different location than where my text files are.

In the next InstallScript CA, the SUPPORTDIR path has changed again. The GUID changes each time.

This all worked fine in version 11 but when I updated to 12 the SUPPORTDIR no longer works the same.

Any suggestions?

Thanks for any help,
Eric

EricJK
06-13-2006, 04:32 PM
I see that this was brought up in the IS12 BETA thread.
http://community.installshield.com/showthread.php?t=158559

I was able to fix my custom actions by using MsiGetProperty to get the value of SUPPORTDIR.

Christopher Painter
06-13-2006, 05:15 PM
FYI there is a sticky in this thread that will help you fix any other issues arrising from the ISScript refactoring that occurred with IS12.

( For example if your CA was defferred, rollback or commit then you would have had to do another CA to set the CustomActionData property then within your main CA use MsiGetProperty to get the value of CustomActionData and decode the SUPPORTDIR property )

EricJK
06-14-2006, 11:03 AM
Thanks for the info about other CA types. All my immediate execution CA's work again. I am stumped because now my deferred Execution CA is not even being called (it worked in IS11). It's an InstallScript CA that is ran 'After InstallFiles' with a condition of 'Not Installed'. I ran it with the debugger and this CA is never called.

It's strange that my only CA that doesn't work is the deferred one. I have quite a few imediate and DoAction CA's. I expected the CA to run but fail to get the SUPPORTDIR property. Any ideas? Am I missing something obvious?

Christopher Painter
06-14-2006, 03:04 PM
I'd have to know what the deferred CA is doing.

EricJK
06-15-2006, 02:41 PM
This particular deferred CA retrieved some property values and then updated some registry settings using InstallScript.

I commented out my code and just made it a simple Installscript CA that updated a registry entry with a MessageBox. That does work! This must have to do with using MsiGetProperty. I would expect that it should give some error message when ran with my other script but it didn't. I also thought it should have stepped through that function when in debug mode.

I'll try using CustomActionData and see if it fixes it. I may have questions on implementing it as it's new to me.

Christopher Painter
06-15-2006, 02:50 PM
Check out my blog and follow the link to InstallSite. I have an example of how to use it there.

Christopher Painter
06-19-2006, 03:03 PM
As for debugging deferred CA's, read this KB article:

http://support.installshield.com/kb/view.asp?articleid=Q112187

EricJK
06-19-2006, 04:03 PM
Thanks for all the help! I used your CustomActionData function you posted at InstallSite and was able to use your example. I'll definitely use this function in my deferred CA's.

I also downloaded the reg file from the knowlegebase article you posted and now am able to debug my deferred CA.

I really appreciate the help!

Christopher Painter
06-19-2006, 04:19 PM
Glad to have helped!

MartinMarkevics
06-19-2006, 04:32 PM
Admittedly, it would be ideal if this functionality was built into the product itself. To that end, we are looking at adding similar functionality, but it's impossible right now to say when it will make it into the product (12 SP, the next version, or something else...). However, this is definitely on our radar.

In the meantime, thanks Christopher for making this example available to users.

MarinaK
08-08-2006, 05:01 AM
I down load Evaluation version of InstallShield 12.
I began to test it and see a big problem.
Setup creates 2 support directories:
C:\Documents and Settings\username\Local Settings\Temp\{GUID1} with
_isres.dll
IsConfig.ini
ISRT.dll
setup.inx
String1033.txt

C:\Documents and Settings\username\Local Settings\Temp\{GUID2} with
my files from "Support files"

(Every start it creates them with defferent GUID)

Function in InstallScript receives SUPPORTDIR = C:\Documents and Settings\username\Local Settings\Temp\{GUID1}
So I cannot use my support files from the script.

Sorry about my English :rolleyes: I hope you understand me.

Christopher Painter
08-08-2006, 08:12 AM
Try the MSI Property SUPPORTDIR instead of the InstallScript SUPPORTDIR keyword.

MarinaK
08-09-2006, 01:46 AM
Try the MSI Property SUPPORTDIR instead of the InstallScript SUPPORTDIR keyword

Thank you. It resolved my problem.
But I think it is not OK if SUPPORTDIR as variable is not equal to value from MsiGetProperty

Tim Magee
09-05-2006, 01:25 PM
I see that this was brought up in the IS12 BETA thread.
http://community.installshield.com/showthread.php?t=158559

I was able to fix my custom actions by using MsiGetProperty to get the value of SUPPORTDIR.

Sorry to be a day late and a dollar short in this thread, but it was very useful after I'd spent half a day wondering why half my setup files were missing.

After reading this thread I wrote myself a GetSupportDir() function and the script compiler complained that the function is already defined. Can't see it in any of the script include files. Doesn't pop up any intellisense when you start coding a call.

So it's as though GetSupportDir is partly defined in InstallScript in v12.

RobertDickau
09-05-2006, 01:41 PM
There seems to be a reference to an external version of GetSupportDir in SysVars.h. Of course, one can always define MyVersionOfGetSupportDir or GetSUPPORTDIR or something else...

Tim Magee
09-06-2006, 04:45 AM
There seems to be a reference to an external version of GetSupportDir in SysVars.h. Of course, one can always define MyVersionOfGetSupportDir or GetSUPPORTDIR or something else...

Thanks Robert, that's the approach that I took.

The thing that still puzzles me is, on Q112115 (http://support.installshield.com/kb/view.asp?articleid=Q112115) where it says "another implication of this change is that each CA initializes and uses its own SUPPORTDIR". I don't see why that's a necessary result of running each script CA in its own process.

Looking at the MSI log, there's a property called SUPPORTDIR which throughout the client and server sessions points to %TEMP%\[ProductCode], which is where my support file has been downloaded. It would make my installer so much more elegant if there were a one-step way to retrieve that directory.

Alternatively, if my support file had actually been written into my CA's individual SUPPORTDIR - that would have worked for me too.

Cheers,
Tim