/build/static/layout/Breadcrumb_cap_w.png

need to persist the properties to be used in deferred execution context

Hi All,

Thanks for your support so far given.

MSI deferred custom actions can only access a few predefined properties unless secondary actions are defined to save a property list for each custom action.
eg: Set Property apdir to [APPDIR] (setapdirprop)
CallVBScript From EmbeddedCode (CALLVBS)

CALLVBS has some code like
.
.
.
.

sApdir=Session.Property([apdir])
.
.
.


Currently when a new deferred custom action is defined or when an existing one requires access to a new property, the property list for the custom action must be defined/updated as a Set Property action in the sxxx.wsi. This is cumbersome and complicated and would be better implemented by persisting all of the properties to temporary storage at the beginning of the deferred actions and then just accessing them from temporary storage.

Note: The WiseAltStartup custom action creates a WiseData.ini file in [WindowsFolder]\[ProductCode].TMP however this format is undocumented and could possibly change.
My need is to persist MSI properties after InstallValidate action for use by deferred actions.


Kindly help me in this.

0 Comments   [ + ] Show comments

Answers (3)

Posted by: spartacus 16 years ago
Black Belt
0
Reading between the lines in your post, it sounds like you are already aware of the use of CustomActionData as a mechanism to feed property data to a deferred custom action. Where the value of more than one property is required to be passed, common practice is to set a single property to the concatenated value of the several properties but each separated by a delimeter of your own choosing. The deferred action can then parse the CustomActionData as needed. All fairly standard stuff so far, it's not elegant I'll admit.

What troubles me a little is why your deferred action is (seemingly) subject to frequent change necessitating updating the property that holds the CustomActionData ? Correct me if I am wrong but the example posted suggests your Custom Action is peforming some file/folder related activity (?) Are you certain this could not be achieved in Immediate execution ? Perhaps if you replied with a little more detail as to :

(i) why your CA is subject to ongoing change such that altering the property list has become burdensome ?

(ii) what activities your CA is performing in deferred mode ?

then the community here might be able to offer an alternative approach

Regards,

Spartacus
Posted by: bhuvan 16 years ago
Senior Yellow Belt
0
Thanks for your reply.Actually I need to set permissions for the msi files and the path is stored in SourceDir property.I need to retrive the property value and use it in a batch file and this should be done in deferred execution mode only.
Posted by: anonymous_9363 16 years ago
Red Belt
0
ORIGINAL: bhuvan
Actually I need to set permissions for the msi files
Why?!? Trying to assign permissions to an MSI from within that MSI sounds like madness to me. If you deny users all access, for example, how will the app self-heal?

Presumably you have a deployment mechanism? And your MSIs are on a network share somewhere? THAT is where your permissioning belongs.
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ