Hi all,
I have the following problem: I need to read properties from the MSI and do stuff with them in Execute Deferred (so as to get elevated priviledges).
I've followed the following procedure:
and it works fine, for the property used in the document, however I can't seem to get it to read / set any other properties.
Specifically, I'm trying to store the SourceDir Property, as need to use this in a vbs in execute deferred.

I am able to use session.property("SourceDir") in Execute Immediate, and return that property in an embedded vbs, but can't seem to use SourceDir in a set property custom action (as per document above.)

any help much appreciated
0 Comments   [ + ] Show Comments


Please log in to comment

Community Chosen Answer

Remember that the "ResolveSource" action should be run before the "SourceDir" property will be available. If you are successfully reading this within the "immediate" sequence, then that should not be your issue.

Try this "set property" action as your "Immediate" action:

Action: Test Action
Type: 51
Source: Testing123
Target: [SourceDir]

This action must be after "CostInitialize" and "ResolveSource", but before "InstallFinalize".

Try this "embedded VBScript" action as your "Deferred" Action:

Action: Testing123
Type: 1062
Target: Msgbox Property("CustomActionData")

Remember that property names are case-sensitive.
Answered 09/08/2005 by: WiseUser
Fourth Degree Brown Belt

Please log in to comment
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.


brilliant, that'll be it, I hadn't clicked that it relied on resolvesource. have deleted it out of frustration, but I'm sure you'd hit the nail with the package there. thanks
Answered 09/08/2005 by: DuncanPaul
Orange Belt

Please log in to comment
Well done WiseUser.....rated for 2 points with that one.
Answered 09/09/2005 by: MSIMaker
Second Degree Black Belt

Please log in to comment
yeah that was a nice catch,.. so while the fatbrains are on a roll..

the actual reason I need to do this, is so can include in a merge module to allow us to add it to any msi, and have it do these actions. Problem I now have is that I can't seem to name the property correctly:

In my MSM I give the VBScipt CA a name, but when include module to an msi it appends the package code guid of the merge module to the CA name (in the msi). I imagine this is so you can identify where properties come from, but the issue is that I then have to, in the merge module, in the set property CA in execute immediate, set the correct property name, ie Testing123.{packageguid}.
Problem is this is too long for the field.

any suggestions much appreciated.

-- update, this turned out to be an issue with the field formatting in wise, so couldn't fit the propertyname.guid in the field, I edited it in Orca and was no problem. only issue is that if you then edit the wsm in wise again, and recompile, it truncates it. ugly.
Answered 09/11/2005 by: DuncanPaul
Orange Belt

Please log in to comment

Well done WiseUser.....rated for 2 points with that one.

Thanks Jim!
Answered 09/28/2005 by: WiseUser
Fourth Degree Brown Belt

Please log in to comment
OK, so, sorry to revive an old post, but has come back in a new way...

Does anyone know how vbscript Custom actions resolve paths? I have an issue with a vbs ca that works outside the msi, works inside the msi against a local path, but doesn't work if the path is non local. It seems to behave the same whether is UNC or a mapped drive, or even subst'd. I've also checked that long paths locally, with spaces etc in them still work.

I've debugged the script and it appears to encapsulate the path in 3 sets of quotes when it stores it, but if you message box the variable out it strips these quotes. I think this is what is messing it up in the embedded custom action, as I use the path to do a FolderExists(path) and its acutally doing FolderExists("""path""")

any thoughts much appreciated..

.. update, I know have you all on edge of seats... UNC path will work to local drive, but not to remote drive. weird. have seen this issue before, but can't find the post.
Answered 10/25/2005 by: DuncanPaul
Orange Belt

Please log in to comment
OK, the only thing I can think of is instead of encapsulating the long path (with spaces) in quotes, try using CHR(34), which is a quote.


CHR(34) & "C:\Program Files\Application Name\Version Number" & CHR(34)
Answered 10/26/2005 by: brenthunter2005
Fifth Degree Brown Belt

Please log in to comment
Answer this question or Comment on this question for clarity