/build/static/layout/Breadcrumb_cap_w.png

Launch Conditions based on registry key or file

I am using Installshield 10.5 to modify a transform. I was using System Search to create a launch condition based on a (first) registry key then the existence of a file. The launch condition based upon the registry key or file existence just prevents the msi from running, rather than evaluating whether or not the file/registry key exists. I've verified that it does this by adding/removing the file/registy key then trying to run it. I've also made sure that the AppSearh step in the Execute and UI sequences are occuring b/f LaunchConditions. I've also tried manually doing this using Orca to no avail. What the hell am I doing wrong here? I know I've done this before this is driving me insane. If someone can just explain this in detal maybe I can figure out where I'm getting this wrong. [:@]

0 Comments   [ + ] Show comments

Answers (8)

Posted by: nheim 17 years ago
10th Degree Black Belt
0
Hi Dan,
you do the following, right?
In AppSearch:
YOURPROP Signature1

In RegLocator:
Signature1 2 Software\Microsoft\Windows\Whateverkey Whateverval 0

With this you get back the value of 'Whateverval' in 'YOURPROP'.
But you can also check simply for the existence of 'YOURPROP'.

Hope this helps a bit.

Regards, Nick
Posted by: danr29 17 years ago
Purple Belt
0
Nick;

So to find the existence of YOUPROP (and allow the msi to install if this property exists), you would use a LaunchCondition that would look like the following right?

table: LaunchCondition
Condition: YOUPROP
Description: (whatever dialog)

You don't have to specify what the property will equal in the condition column, because it already has a value (that of Signature1). Am I correct?
Posted by: nheim 17 years ago
10th Degree Black Belt
0
Dan,
yes, that should work, IMHO.
Do you have by any chance, more than one condition in there?
If, yes, be aware that there is no order guarantee here.
See: http://msdn2.microsoft.com/en-us/library/aa369752.aspx
Regards, Nick
Posted by: danr29 17 years ago
Purple Belt
0
No there's definitely only one condition here. AppSearch needs to be b/f Launch Conditions right? I've moved AppSearch b/f Launch Conditions and now it's telling me it's looking for an entry in the Signature table. I thought if RegLocator was used the Signature table didn't need to be used? This is insanely frustrating.
Posted by: nheim 17 years ago
10th Degree Black Belt
0
Hi Dan,
i'm not 100% convinced, what you are searching for in the registry.
But this is the important thing here. Please read this:
http://msdn2.microsoft.com/en-us/library/aa371171.aspx
Especially the signature and type stuff.
Regards, Nick
Posted by: danr29 17 years ago
Purple Belt
0
Ok I can explain a little more in-depth. I want my application to install only if the presence of the following registry key is detected: HKLM\Software\CaseSoft\CaseMap\6.0. If it's not there I want the LaunchCondition dialog to pop up telling me I need another application installed before this (one that creates the previously mentioned registry key) and the application quits. If it's there I want the installation to run.
Posted by: danr29 17 years ago
Purple Belt
0
I was finally able to do this by using the Custom Software Condition wizard which allowed me to determine what happens when it finds the file (install if found, not install if not found). My issue was having it determine what to do when it was found.
Posted by: anonymous_9363 17 years ago
Red Belt
0
One thing that catches folk out is to ensure that the AppSearch action is sequenced before the LauchConditions action. Wise Package Studio, for example, defaults to having LaunchConditions as the first CA, followed by FindRelatedProducts, then AppSearch. Bizarre. It's one of the first things I change in my template when setting up WPS.
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