Scripting

Stephane,

You should create your property (Department) first in the Property table and give it a default value. Then use your CA to set it to a certain value in the InstallExecuteSequence (make sure this happens immediately before InstallInitialize).

Your condition should be:
Department = "ABC"
and will probably go on a Component....

A couple things to consider:

1) In order to use the Session.Property("Department") statement in your CA's, the Department property needs to be defined in your MSI. Ofcourse once you define it, you can use it in your MSI, in conditions and what not, provided your CA is sequenced early enough so the value is filled in before the conditions are evaluated.

2) Session properties, by default, are only available during the immediate execution sequences. Once your MSI passes into deferred execution, it loses access to its session objects. If you want access to your properties for whatever reason in Deferred execution, you'll need to populate the "CustomActionData" property with the values you require, using a CA in immediate exeution context. (look for it on the internet, plenty of information on it out there)

Hope this helps

PJ

Yeah, one more thing that may or may not help is that you could use a 'Set Property' (Type 51) custom action to get the domain name, and condition your components based on that?

(UserDomainName will be your custom property, and you could use this to condition your components)

(CustomAction table)
SetUserDomain 51 UserDomainName [%USERDOMAIN]

Oh really?

Ok that makes sense. Before reading your message I tried what Captain_Planet mentionned. I can now indeed create my condition, it seems all i was missing was the Property in the table. And now I guess it's working since my file isn't installed, which is normal since it's probably never changed from the default value because of what you said in your second note.

I'll google that right away, but thanks in advance, I think we're headed in the right direction!

I'll let you know what I find!

Thanks,

Stephane

ORIGINAL: pjgeutjens

A couple things to consider:

1) In order to use the Session.Property("Department") statement in your CA's, the Department property needs to be defined in your MSI. Ofcourse once you define it, you can use it in your MSI, in conditions and what not, provided your CA is sequenced early enough so the value is filled in before the conditions are evaluated.

2) Session properties, by default, are only available during the immediate execution sequences. Once your MSI passes into deferred execution, it loses access to its session objects. If you want access to your properties for whatever reason in Deferred execution, you'll need to populate the "CustomActionData" property with the values you require, using a CA in immediate exeution context. (look for it on the internet, plenty of information on it out there)

Hope this helps

PJ

Ummm...why not simply use AppSearch? Environment junk is in the registry (User level stuff in 'HKEY_CURRENT_USER\Environment', machine level stuff in 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment') so a simple registry read in AppSearch can populate the property which can then be used in your conditioning.

Ok, I'm starting to wonder if too much reading on the subject is getting me more confused. I think I get a better picture of how CustomActionData works, but I'm still having problems implementing it in my scenario.

If you guys want to bear with me, I will recap my situation.

1) I have a VB Script which needs to run BEFORE installing the files. This script scans the computer (sadly not available thru environment variables as proposed by VBScab) and finds the department of the user.
2) I need to set a condition for configuration files to be installed only if the department is equal to a given department.
3) I understand that I will need to Embed my VBScript in a CustomAction.

Where it gets foggy is
- Does my VBScript need to run in Immediate or Deferred?
- Naming convention when using this method seems to be very precise also.
- Trying to find more examples of implementing CustomActionData and how it relates to my case.

Anyway, I'll go back to my reading in the meantime.

Thanks for your patience all,

Stephane

I might have sent you in the wrong direction. Actually, if your Department can be found ANYWHERE in the registry, VBScab's suggestion is by far the simplest one. Just have a look at the SystemSearch functionality, see if you can use it to populate a property.

don't go too crazy on the whole CustomActionData thing. It was just a heads up. If I'm not mistaken, in setting properties to use as component conditions you'll be sticking to immediate execute sequence anyway.

So to recap:

First look at SystemSearch
If that REALLY doesn't work create your property and your CA, execute it in immediate, somewhere right after InstallValidate for example. I don't think you'll run into naming constraints here.

Good luck

PJ

When I use Wise Package Studio's Condition Builder, under the property section, my custom made Property from my Embedded VBScript isn't there.Stephane, just to advance your understanding, the property isn't there because it doesn't exist until the embedded script runs. If you want to see a property, add it to the 'Property' table and assign it a value: I normally use zero. When a property-setting CA runs, its value will change accordingly. You can see this in action if you run the MSI through your authoring tool's debugger.

As for the script-versus-AppSearch, where is the Department information held? Is it in the registry? My point about the environment, BTW, was that there's no magic to the environment - its content is stored in the registry locations I indicated. So, registry or environment amount to the same thing - it's just a question of where in the registry the data is. :)

Hello again!

We are making progress! My DEPARTMENT property is set to 0 in the properties tables. I also have my CA running in Immediate. Since the question was asked, let me answer: in this case, our departments are deducted using the IP Adress of the workstation.

So a Subnet A will get a configuration of Firefox A, B will get configuration B and so on and so forth.

In my MSI, I then go in the component view, right click it, details, and on the Condition Field, I supply the following:

DEPARTMENT = "ABC" because I want this component only installed if my Property is ABC right?

Compile, install. The files are NOT present on the machine.

Upon closer examination of the Log File here are a few infos I get that confuse me:


MSI (s) (A0:BC) [13:14:45:411]: Doing action: SetDept
Action ended 13:14:45: InstallValidate. Return value 1.
MSI (s) (A0:BC) [13:14:45:411]: Transforming table CustomAction.
MSI (s) (A0!BC) [13:14:46:514]: PROPERTY CHANGE: Modifying DEPARTMENT property. Its current value is '0'. Its new value: 'ABC'.
Action start 13:14:45: SetDept.


And near the end I also have:


Property(S): DEPARTMENT = ABC


Which is what I was expecting! But if this is the case, my component SHOULD be installed. Going forward in the logfile, I searched for the component in question, and here's what I get:


MSI (s) (A0:BC) [13:14:45:131]: Component: firefox.exe; Installed: Absent; Request: Local; Action: Null


Why? To be sure I hadn't messed up anything, I removed the condition, and all files are present, which is normal since I didn't have conditions.

Final test I did was the following. Instead of having my DEPARTMENT = 0 in the properties table, I hardcoded it to ABC. Commented out my CA, compiled and installed. And wham, the Component is there. So my condition seems to work fine when Hardcoded.

Does this seem normal to you guys? What am I missing out?

Thanks!

Stephane

My guess would be that your CA is sequenced AFTER the ProcessComponents action. Most property-setting is best done right at the beginning of the sequence.

Not even :(

I'll keep looking!

Stephane

ORIGINAL: VBScab

My guess would be that your CA is sequenced AFTER the ProcessComponents action. Most property-setting is best done right at the beginning of the sequence.

And the plot thickens!

While looking around my package, I was in my Component Table. Now, as expected, I looked under my component line, and at the Condition column, my condition was set as we spoke of yesterday: DEPARTMENT = "ABC".

Now, while scrolling over my condition, a charming yellow box popped up at my mouse cursor saying the following:

A conditional statement that will disable this component if the specified condition evaluates to the 'True' state. If a component is disabled, it will not be installed regardless of the 'Action' state associated with the component.

Now, I may be nuts here, but isn't this exactly the contrary from what I was expecting? Isn't my component installed only if my condition is TRUE? And not the other way around?

Thanks!

Stephane

I'm not entirely sure, but I think your CA might need to execute before CostFinalize, try it that way.

Now, while scrolling over my condition, a charming yellow box popped up at my mouse cursor saying the following:

A conditional statement that will disable this component if the specified condition evaluates to the 'True' state. If a component is disabled, it will not be installed regardless of the 'Action' state associated with the component.


This is from the InstallShield help:

Condition
This column contains a conditional statement that can control whether a component is installed. If the condition is null or evaluates to true, then the component is enabled. If the condition evaluates to False, then the component is disabled and is not installed.

So one of them is right, logic would dictate that TRUE means install....

PJ

What tool is that you're using? MSI.CHM says:
This column contains a conditional statement that can control whether a component is installed. If the condition is null or evaluates to true, then the component is enabled. If the condition evaluates to False, then the component is disabled and is not installed.
The Condition field enables or disables a component only during the CostFinalize action. Oops! My mistake: your CA evidently needs to be before CostFinalize.

Ding ding ding ding!
We have a winner! hahaha!!!!

Ok, so to answer VBScab, I'm using Wise Package Studio 7.0.

And as suggested by VBScab and PJ, I moved up my CA a few spaces, setting it right before CostFinalize and bingo, it's working.

Now for my own personal knowledge and experience. Why is it that in this case the CA has to be before CostFinalize and not right before/after InstallInitialize? What's the difference?

Thank you by the way for all your help in resolving this problem!

Stephane

null ORIGINAL: VBScab

What tool is that you're using? MSI.CHM says:
This column contains a conditional statement that can control whether a component is installed. If the condition is null or evaluates to true, then the component is enabled. If the condition evaluates to False, then the component is disabled and is not installed.
The Condition field enables or disables a component only during the CostFinalize action. Oops! My mistake: your CA evidently needs to be before CostFinalize.

Costing is the process that the engine goes through to work out stuff like how much disk space the install will consume. That will be affected by whether or not components are to be installed or not so the engine parses the components table and selects those which will be installed. Those which are conditioned-out won't be installed and thus don't count towards the final "cost". As ever, MSDN will have a ton of stuff about costing.

BTW, I asked about which tool you use (I should have remembered it was WPS) to try and determine where that help text came from. I still can't find it! What view are you in when the tooltip containing the text appears? I'm intrigued... :)

Sure thing,

I go in Wise, and at the bottom where you click on either Installation Expert | MSI Script | Setup Editor, click on Setup Editor.

Then, you should be able to choose one of 5 tabs: Features | Components | Product | Tables | Dialogs.

I went in Tables, chose subtable "Components", scrolled down to my component, and left my mouse cursor hover over the condition that was set in my component.

That's where the little confusing yellow help window appeared.

Tell me if you find it!

Thanks,

Stephane

LOL...you're right!

Report it as a bug. You'll be a Grandad before it even hits the 'Looking at' pile. You might even be lucky enough to receive an acknowledgement of its existence. Don't hold your breath waiting for that, either.

On a related note, you have to wonder about the intelligence of a development team that imagines that the default tooltip time is sufficient to enable anyone to actually *read* that tip. Clearly, using a message bar is too "bleeding" edge at Altiris...

LOL!!!!
Ok, well, as we say: better late than never :)

I'm happy to know that I wasn't nuts :)

Thanks again guys,

Steph

be lucky enough to receive an acknowledgement of i ORIGINAL: VBScab

LOL...you're right!

Report it as a bug. You'll be a Grandad before it even hits the 'Looking at' pile. You might even be lucky enough to receive an acknowledgement of its existence. Don't hold your breath waiting for that, either.