5 replies to this topic

[AndrewWalker]

I am creating an install whose purpose is to read a flat file that contains information on some features.  It then adds that information to an MSI database file (not the one that's currently running).
Mostly, what I have works:  The flat file gets read, all of my MSI function calls work, and when, just before closing the database handle, I export the Feature table to a text file, the text file contains all of the stuff I just added.  But when I close the database handle, all of my changes go away.  I am doing an MSIDatabaseCommit after each addition and just before closing the handle, but the changes don't seem to be taking.  Any ideas?

[AndrewWalker]

Managed to solve this one myself and found a new problem:
The solution is that a running MSI package doesn't seem to want to directly update another MSI package, at least not through InstallScript commands.  So I created a batch file in the script with the necessary Cscript WiRunSQL.vbs MSIFile "SQL Statement" calls, then launched the batch file.  This updated the MSI database as I wanted done.
However, I have now discovered that something strange is going on with the dialogs:    When I try to run the changed MSI file all by itself, I get no dialogs.  As part of trying to figure this out, I created an MSI package from ISWI, then opened the resulting MSI file in ISWI.  All the dialogs were now gone, even though I had done nothing to the MSI file.  Any ideas why this might happen?

[SteveP]

Andy,

Do you have ORCA (part of the Windows Installer SDK)?  If so, take a look at the Dialog Table and Control Table to see if the dialogs are really missing or perhaps not called.

When you are generating a 'blank' MSI database, you can easily end up with something that functions as a database but has none of the standard tables.  I have designed a custom packager, and in order to ensure that I have all the elements I want in the deployable database, I use a copy of the full schema (also available in the WI SDK) and populate the tables I need to use.  I also import the full standard UI, so I don't have to worry about dialogs, except for customizing, as needed.

What you may want to do is to generate a series of 'templates' that contain your basic structure and dialogs ... then populate only those tables that have to be changed for each of your installs (i.e., File Table, Feature Table, Component Table, Class Table, etc.) from your update routine.

Most of the files can be built in the IDT 'flat file' format and then directly imported into the database using the automation interface or by using the MsiDB.exe tool included in the SDK.

Please send me an email if you would like to discuss these issues in further detail.

[AndrewWalker]

Steve--

I think I have discovered what has become of the dialogs.  I am designing around the possibility of internationalization.  As such, ISWI creates transform (.mst) files, one for each language.  I believe the Setup.exe it creates determines the language, then performs a transform on the MSI file with the appropriate language's .mst file; the .mst file contains the localized dialogs.

This means that I can't just double click on MyProject.msi; I need to either run the Setup.exe or perform the same transform that it does.

The problem with running the Setup.exe is that when it launches the .msi file it closes, returning control to my launching setup before the launched setup has even really gotten started, much less finished.  I don't want to rely on the launched installer to somehow notify the launcher that it's done.  Having the launcher keep track of the launched setup sounds terribly tricky, given the way MSI works.

So, do you have any clues on what the Setup.exe does behind the scenes before it launches the MSI file?

[AndrewWalker]

I answered my own question again.  Actually, I went into the book (The Official InstallShield for Windows Installer Developer's Guide by Bob Baker) and found the answer, and applied it.

Simply put, I convert the system variable SELECTED_LANGUAGE into a string, and make that part of a parameter passed to the MSIExec command that I launch:

MSIExec /i MSIFile TRANSFORMS="LanguageNumber.mst"

Anyway, thanks for your help!  :)