12 replies to this topic

[Scott Mayham]

If one of my setup's two features is selected by a user, either by choosing a "complete" setup, or by selecting the feature in the Custom Setup dialog, I have the UI sequenced to flow to a dialog box to solicit some additional configuration data.  This data is set as "public" properties, by virtue of having been set in the edit field's "property" property IN ALL CAPS.   However, when I go to use this data during a CA which runs later, in the EX sequence, these properties are not visible to my InstallScript (i.e., they are "undefined").

So, I set them in the Property Table as well, but my IS still doesn't "see" them.  What am I doing wrong?

(ISWI 2.03  /   W2K + spk 1)

[Leigh Ravenhall]

Is your custom action deferred or immediate.  There are limitations on the properties available to a deferred custom action.

[Scott Mayham]

Leigh,

My CA is deferred.  And yes, I'm aware that MSI properties like INSTALLDIR are not exposed during the EX phase, which is why my setup uses a Type 51 CA to overcome this.  But, what about other properties, such as those which represent data gatered from the user during the UI phase.  It would seem that the purpose of a Dialog box would be to get data (true in my case), and the purpose of a deferred CA is to do something with this data (again true in my case).  But, in the general case, how does one get that data from UI do EX?  Type 51, and the whole "Custom Action Data" scenario seem pretty onerous for what must be a routine kind of requirement.

Elsewhere in Installsite, in one of the other Forums/Topics (I can't recall which one), someone mentioned that making properties public, by capitalizing them, made them visable across the great chasm which separates UI from EX.  No replies were made by anyone to challenge that notion, so I took it to be true.  If it is not, what does capitalizing them do?

You recently posted some inquiries which indicated that you are working on a setup similar to the one I am creating.  One of my two features must communicate with a SQL Server 2000 database using either a SS2K client or MSDE; so in those cases in which that feature is selected, I bring up a dialog box which gets from the user such things as the server name, and the username and password by which to access the database on its server over the network.  Of course, this occurs in UI, after the SetupType and CustomInstallation dialogs, and before ReadyToInstall.  In EX, I have a CA which activates a series of configuration utilities (via LaunchAppAndWait), and it is those utilities which need the server information gathered earlier.  So, all I am looking for is a straightforward way to get the data gathered in my dialog box to my configuration utilities.

At any rate, that's my problem, and I am open to all suggestions.  Sorry about the detailed description, but I want to convey the situation accurately.

Regards,

[Leigh Ravenhall]

From what I understand, a deferred execution Custom Action can only retrieve the CustomActionData property and ProductCode properties.  I agree with you, this is seriously annoying.

Capitalisation of properties makes a property public, but only in the sense that it is available in the UI and to immediate execution custom actions in the execute sequence.  Public properties can also be used as part of conditional statements in the execute sequence, whereas private ones cannot.

I can only think of two solutions.  First, pack all of your properties into the CustomActionData property, using a unique character to seperate the properties, then unpack them as part of the custom action.  I agree that this is a large amount of work for something quite trivial.

The other option is to set your custom action to immediate execution.  To run your custom action after the files are installed, place it in the execute sequence after InstallFinalize.  This method still has limitations.  You can access your public properties that were set as part of the UI sequence, but I haven't yet been able to get the status bar working correctly.  The best I have done so far is to change the line above the status bar to "Modifying databases, this may take a while....."

It may not look good, and I may be violating a huge number of best practices, but it allows me to create databases, configure WMI, modify COM+, setup IIS, etc.

Please note, I'm still new to this, so if I've made any mistakes and someone would like to correct me, feel free.

[Scott Mayham]

Leigh,

Thanks for your detailed reply.  However, I was afraid you were going to say what you did.  There appears to be nothing "easy" or straightforward about ISWI, although I suspect the real guilt lies with our friends in Redmond (Microsoft Installer).

I'm going to try something, and I'll let you know how it works.  The fact that there is but one CustomActionData property would indeed seem to imply that there is but one place to stash the stuff we collected during UI, for the purpose of passing it to CAs located in EX.  But when I was building my one such use of that mechanism, I noticed something which might be useful, if my inference is correct.  That is, when setting up a Type 51 CA, you specify the name of the CA which is to be the recipient of the data, as the "source" of the CA.  In other words, there seems to be a relationship established between the name of the recipient CA and the occurence of CustomActionDate.  

What I will do is to create a Type 51 for each data element which I would have passed via the Global Property mechanism, had I been able to do so.  I will declare a different recipient ("source") CA on the EX side for each of them, each with a unique name.  If my guess is correct, then there will be multiple occurences of CustomActionData, one for each of the recipients.  I'll know by later today (Eastern US time).  I always do my best to avoid obscure mechanisms wherever possible, and bundling all this stuff in one occurence of CustomActionData, and having to parse it out later strikes me as obscure.  I'll do it if I have to, but I hope to find I don't have to.

Finally, there is no need to apologize for being "new" at this - since we all are.  Our best hope is for all of  us to continue to help each other out, and to be willing to try new things, and to share our results with each other.

Regards,

[Scott Mayham]

Progress Report -

I created a second Type 51 CA, with a different "recipient" than my first one.  The recipients (in the EX sequence) reported what they got when they did a GetMSIProperty.  All built and ran without any reported errors.

The first one (the original) properly received and displayed the CustomActionData property (INSTALLDIR) which it's Type 51 CA stashed for it.  

The second (new) one did it's GetMSIProperty without an error, but the CustomActionData property it went after came back blank (?!!?).  

Inconclusive.  I'm reversing the order in which the Type 51s execute, to see if this reverses which gets blanked.  Perhaps then I'll be able to draw some conclusions about my theory that you can have as many CustomActionData occurrences as you have unique "recipients" for them.

Watch this space.

Scott Mayham

[MetinSenkal]

Hi guys,

I have to create similar installer package, which will create databases on a sql server that Servername, LoginID and Passwd will be taken from UI and osql.exe will be launched after sql scripts are installed to target machine if a feature is chosen. I have succesfully manage to do all this as follow,

By using &FeatureState control mechanisms, i have run first script which seraches target machine for osql.exe (I don't use AppSearch, since it looks for file at first, but i do not want to search if user doesn't choose that specific feature.)

Then i called and immediate execution scripts that uses MsiGetProperty and gets INSTALLDIR and above three parameters and assign them to global script variables. So I can reach them in deferred execution step by getting these globals. (In fact, i am not quite sure about these step, i put this CA in the execution sequence after InstallInitialize, and i have few questions in my mind whether i will properly get INSTALLDIR in all cases)

Then in deferred execution, by using above global parameters i launched osql.exe from search path with UI taken parameters and INSTALLDIR script files.

I have installed a few number of times and it seems, its working properly.

By the way, i am also new in this subject, and in your notes please at least once refer the custom action numbers with their explanations, i mean type 51 custom action(i guess from your notes it's set a property) you may refer once it and then uses as you wish, it will be easier for novices to understand.

Thanks,
Metin SENKAL

[Ian Blake]

Scott, You are on the right track.  I suspect you have made a small easily made error such as a typo or perhaps mixing Target and Source in a 51 CA.  

I find it very helpful in these situations to generate a log file.  You get a list of properties at the end of the log so you can verify what you got is what you wanted.  I have found it invaluable when debugging msi problems.  You also learn a lot how msi works by reading them.  Win9X, WinNT and Win2000 logs are slightly different.  I found a log in a 9X install highlighted a problem that was not clear from the Win2000 log.

Provided the required property is defined before the CA is added to the script the appropriate "CustomActionData" will be set.  The order of your type 51s should not matter.

(I believe the property must be set before the deferred CA is added to the script, I do not believe changes made between script generation and execution will have any affect. I might be wrong.)

[Scott Mayham]

Final Results:

I'm still inclined to believe that there is (or should be!) a way to pass multiple instances of CustomActionData from UI to EX via a combination of Type 51 CAs and Deferred CAs in EX.  However, time constraints have forced me to abandon that subject for now.  

However, in a reply earlier in this topic thread, Leigh Ravenhall suggested using an Immediate CA rather than Deferred, and so I turned to investigating that possibility more carefully.  And, there is where I found my solution (Thanks Leigh!!!!).

What I do is this:  I collect three user-supplied data elements from the user via a dialog box in the UI phase: the name of a SQL Server box, and the Username and Password to use when accessing that box.  Via the "Property" attribute in the Dialog box's behavior settings, these items are deposited in the Public Properties I created for them in the Property Manager: SQLSERVER, SQLUSER, SQLPASSWORD.  (I'm uncomfortable with the security implications of making a password a public property, but I'll have to deal with that later).  

I then wrote a very short Immediate CA in InstallScript, which is sequenced to run early in the EX phase, before InstallInitialize.  At this point, these properties are still exposed to my CA, and it gets them via calls to MsiGetProperty, loading them into InstallScript Global variables (sSQLServer, sSQLUser, and sSQLPassword, respectively).  This is where they reside, until the CAs which really need them are executed, just before InstallFinalize.  

And, ("Ta-da!") it all works beautifully.

Not that I'm done with this installation.  I've got to solve the security hack I mentioned; I'm not sure that my properties must of necessity be public - I'm going to try redefining them in mixed case (thus making them private).  The other upgrade will involve an attempt to verify the user-entered SQL configuration data while still in the UI phase, by means of an immediate CA which will call a method in a DLL (streamed in the binary table?) which will attempt a "ping" type handshake with server, and drop back to the dialog box if the connection fails.

Again, thanks for all of the suggestions and encouragement.

Regards,
Scott Mayham

[Leigh Ravenhall]

A quick method to verify the SQL information is to use the SQLDMO SQLServer object in VBScript.  A short 5 line script can be used to connect to the server, expand it if required for more detailled error checking.

[Ian Blake]

I'm still inclined to believe that there is (or should be!) a way to pass multiple instances of CustomActionData from UI to EX via a combination of Type 51 CAs and Deferred CAs in EX. However, time constraints have forced me to abandon that subject for now.  

As I said previously you are there is no restrictions here I do it all the time.  One of my installations has more than ten 51s setting the custom action data.

However, in a reply earlier in this topic thread, Leigh Ravenhall suggested using an Immediate CA rather than Deferred, and so I turned to investigating that possibility more carefully.  And, there is where I found my solution (Thanks Leigh!!!!).

In general I am not fond of the immediate CA solutions.   It is not possible to place the the CA in the correct position, not possible to adjust the progress bar for the action, very difficult to do rollbackj etc.  This is not at all a criticism of Leigh who I have noticed to be one of the most helpful members of this discussion group.

(I'm uncomfortable with the security implications of making a password a public property, but I'll have to deal with that later).  

It does not make much difference if a property is public or not.  Make sure you have a CA to turn logging off.

And, ("Ta-da!") it all works beautifully.

Well Done.

[IgorS]

I had the same problems with transfer InstallShield properties to deffered CA.
I solve it this way. I writed my COM object, which has methods SaveTempProperty(PropertyName, PropertyValue),  ReadTempProperty(PropertyName), DeleteTempProperty(PropertyName).
There was more methods in this COM object for my installation purpeses. But this is not important now.
Method SaveTempProperty save property value in the temp folder in the file with the same name.
I registered the COM in the start of installation. In the UI I created CA with SaveTempProperty, and in the deffered CA I called ReadTempProperty.
May be it is too complex, but it works.