INSTALLDIR/TARGETDIR blank after upgrading to IS Pro 2008

[DACarr]

Hi all,

I have a 'Basic MSI Project' that builds and runs perfectly fine in IS Pro V11 on my Windows XP machine.

I also have IS Pro 2008 on my development machine, and have opened this 'Basic MSI Project' in IS Pro 2008, which converted it to the latest format. No other changes were made to the ISM.

Now, it seems that the TARGETDIR property I was using in my InstallScript is no longer set - installing on the same XP machine. Note that the InstallScript is being invoked through a custom action near the end of the MSI sequence, right after ScheduleReboot.

Adding in a MessageBox to try to display the TARGETDIR, I also see that INSTALLDIR is empty, as well as calling MsiGetProperty(hMSI, "MSI_TARGETDIR", sValue, nCount).

So the path isn't set anywhere, despite INSTALLDIR being set in Installation Information | General Information | Product Properties. If case it matters, the value is set to:
[WindowsVolume]MyDestination

Clearly there is a problem moving from IS Pro V11 to IS Pro 2008. Any ideas how to solve this?

Thanks in advance,
David

[DebbieL]

Some major architecture changes were introduced in InstallShield 12, as described in the following help topic:
Upgrading Projects from InstallShield 11.5 or Earlier

For details about changes affect InstallScript custom actions in Basic MSI projects, please see the following help topic:
Upgrading InstallShield 11.5 or Earlier Basic MSI Projects that Have InstallScript Custom Actions

I hope that helps.

Debbie Landers
Acresso Software

[DACarr]

Hi Debbie,

Thx for the speedy reply and the links to the architectural changes. I have read through these documents and I can't find any reference to actual issue at hand: INSTALLDIR and TARGETDIR, IS-defined variables, are not set.

Thx,
David

PS: Note that my custom actions work fine; they are properly invoked in IS Pro 2008, and I am not using any global variables. So I don't think the cautionary notes in the links apply to this problem.

[DebbieL]

About the custom action scheduled after the ScheduleReboot action: What is this custom action's in-script execution set to?

[DACarr]

The 'In-Script Execution' for this custom action is 'Deferred Execution'. This is the same as when it works in IS V11.

PS: Some other info if relevant...
I have opened the projects in both IS V11 and IS V2008, making a screen capture in both. In terms of the custom action (which IS correctly called in both...only that INSTALLDIR/TARGETDIR are not set in IS V2008), the only difference I can see is that the 'Install Exec Sequence' in IS V11 is 'After OnMoved', whereas in IS V2008 it is 'After ScheduleReboot'. Given that 'OnMoved doesn't seem to exist in V2008, but that 'OnMoved' in V11 occurs right after 'ScheduleReboot', this would seem fine to me.

[DebbieL]

Ah, that explains it.

Basically, InstallScript variables are tied to the corresponding Windows Installer properties. Thus, the INSTALLDIR InstallScript variable (and the TARGETDIR InstallScript variable, which takes INSTALLDIR's value) is tied to the Windows Installer property INSTALLDIR in your InstallScript custom action. Deferred actions cannot access the Windows Installer property INSTALLDIR, so this property will be blank, and its corresponding INSTALLDIR InstallScript variable will be blank. Only immediate-mode custom actions can obtain the value of Windows Installer properties such as INSTALLDIR.

To resolve this, you'd need to use the CustomActionData Windows Installer property. The second hyperlink in my earlier post has some details.

[DACarr]

Ah...ok, now I can see the relevance of those links. Thx.
http://helpnet.acresso.com/robo/projects/installshield14helplib/AccessingProps-DeferredCAs.htm

Based upon your help and the link above, I have now set up a custom action to try to achieve my goal, where I created a 'New Set Property' called setMyProperties, where its 'Property Name' is MyProperties and its 'Property Value' is [INSTALLDIR]. Its 'Install Exec Sequence' is 'After InstallInitialize'.

Lastly, I created a ISScript function to retrieve those values called MyFunc, along with a custom action MyProperties which uses this 'Function Name'. And it works! MyFunc is able to access the value using MsiGetProperty(), using hard-coded string "CustomActionData" as the second argument. The key part of the puzzle is that the 'Property Name' and the custom action to retrieve the values must be spelt identically.

So Debbie...here is my question. If I have more than one deferred action where they both need access to the 'Property Values' data, how can I do this? Is there a way to invoke a custom action from within IS Scripting code?

Any other thoughts?

Thanks again...you have been a great help!
David

PS: I dropped the InstallShieldScriptingEngine.msm from my project as per the upgrade docs.

[DebbieL]

I'm glad you're making progress.

Unfortunately, I don't know of a way to use the value set by one immediate set-a-property custom action with more than one deferred custom action. As you pointed out, the property name must match the deferred action name. I think that the easiest thing to do would be to create the custom action pair (one immediate set-a-property custom action plus one corresponding deferred custom action) for every time that you need to refer to INSTALLDIR.

[DACarr]

Morning Debbie - Thx again for your responses.

So we are definitely on the same wavelength...as late last night I realized that the approach you describe would be the way to solve it. Taking it further...for each deferred custom action requiring 'state', I would set up an immediate set-a-property custom action that contains all the state variables (separated by ';' as described in the link you gave) required within that deferred custom action (and all of the functions it calls...passing the state variables as function arguments).

I'd like to ask you one last thing before wrapping this. I also tried setting up an immediate custom action IS Script function call which calls MsiSetProperty(). Then in a deferred custom action IS Script function, I call MsiGetProperty() using the same property name. Unfortunately this doesn't work - it returns an empty string.

Is there any way the MsiSetProperty/MsiGetProperty can be used? I also read about the Session object's Property method. Can this be used?

Anyhow, thx again for all your speedy and informative responses.

[DebbieL]

No problem.

The MsiSetProperty and MsiGetProperty behavior that you describe is along the same lines as the issue that you originally reported: You're using MsiGetProperty in a deferred custom action, but deferred custom actions can't get property values. So, you get the empty string again.

The Session object is only available for custom action types such as VBScript. Trying to use it in InstallScript would probably result in a few compiler errors.

[DACarr]

MsiSet/GetProperty - Ok, makes sense.

Session - Is this a compelling reason to use VBScript over ISScript? I am language-agnostic and have used ISScript just because that is what I have done before. Is there a link to the merits of one over the other? Having easy access to this Session object might make it worthwhile.

Sorry...learning one thing leads to another question...

[DebbieL]

Ya know, I think I need to step back a second. What is your deferred custom action doing? Based on your screen shots, it looks like the name of it has the word "Installer" in it, so I'm wondering if it will install something. If it does install something or make any changes to the target system, you'll probably want to change the in-script execution to Deferred in System Context. Otherwise, end users may have trouble on Windows Vista systems. This is described a bit in #2 in the following newsletter tip:
7 Reasons Why your Installations May Fail on Windows Vista (And How You Can Fix Them) [PDF]

Back to your latest post: I'm not aware of any documentation that points out the advantages/disadvantages of one language over another for custom actions. Session.Property("INSTALLDIR") is just the VBScript way of writing MsiGetProperty(hMSI, "INSTALLDIR", ...) or MsiSetProperty(hMSI, "INSTALLDIR", ...). A deferred/deferred in system context custom action has the same limitation (can't access the Windows Installer properties), regardless of whether the action code is written in VBScript or InstallScript. So, in that respect, neither language has an advantage over the other. Note that VBScript custom actions can be blocked by some anti-virus software on some machines, so that may weigh in your decision on what language you use to write custom actions.

I hope that helps.

[DACarr]

Ahhh...you are observant! Yes, one of the reasons to use custom actions is to invoke a 3rd party legacy InstallShield install pack EXE, and based upon where it gets installed, then install a file to that location. So your tip is helpful.

Ok, great...so thx for clarifying that I would have the same obstacle using the Session.Property() in VBScript in a deferred custom action - the string returned would be empty.

So that settles it, and in the interest of not hogging any more of your time (ok...I have actually seeded some new threads!), this issue is closed. The solution being: write a custom action pair as we discussed in posts #8 and #9.
http://community.acresso.com/showpost.php?p=421841&postcount=9

Thx for all your advice on the original topic and the sidebars - it has all been very useful for this project and all the others I manage here.