Missing MSI Tables?

[gripper4hire]

Looks like I found an interesting issue in Installshield 2009. I have a DLL custom action which dynamically adds new entries to the MoveFile / RemoveFile tables at runtime.

However, when I build an MSI Basic install project which contains my custom action using Installshield 2009, the MoveFile and RemoveFile tables are missing from the built MSI. It appears that Installshield 2009 is not including these tables if the project doesn't explicitly have any entries added to these tables.

Is there a way to turn this behavior off, similar to the ability to turn off "Keep Unused Directories" from the build setting? Perhaps an extended entry in one of the IS* tables?

[Christopher_Pai]

You are correct, there is a list of tables that InstallShield started purging in I believe IS12. Of the top of my head, I'm not sure if/where the override settings are.

As a hack, since you said you are using dynamic tables, you could author the MSI with fake records and then in your custom action delete those records in your temporary tables before you populate your dynamic records.

[RobertDickau]

Right, I think you can edit settings.xml to control tables getting deleted; please see [post=361243]this post[/post], for example.

[gripper4hire]

Thanks Chris and Robert.

Editing settings.xml works, but it looks like I'll have to roll these xml updates across several standalone builders.

On this topic, would it make sense for this behavior be switchable in the project ism? Settings.xml is a global setting, and whether to drop tables or not seems like it'd make more sense on a per-project basis. Devs could want to do different things for different projects.

It also doesn't make sense why the build would drop these (and other tables) when the standard actions which use these tables (MoveFiles, RemoveFiles, etc) are still included in the Sequence tables.

I'd imagine that a better way of doing this would be to have the build identify if the corresponding standard action is included in the Sequence tables, and if so, include the corresponding table in the output. If a developer doesn't want the table, they can simply remove the standard action from their sequence -- nothing would use the table anyway, unless the dev was trying to replace the standard action with a custom action that reads these same tables as their standard action counterpart (which sounds like a really bad idea!)

[Christopher_Pai]

I think the goal of purging unneeded tables is good. Any questions of how to implement would be for a future release of InstallShield.

For now, I agree that you now have an unwanted build box configuration dependency. To achieve per project ( per build really ) variation, I'd put a step into your build automation plumbing that brings different xml configurations into scope prior to calling standalong build or msbuild targets.

[gripper4hire]

Christopher Painter wrote:
I think the goal of purging unneeded tables is good. Any questions of how to implement would be for a future release of InstallShield.

For now, I agree that you now have an unwanted build box configuration dependency. To achieve per project ( per build really ) variation, I'd put a step into your build automation plumbing that brings different xml configurations into scope prior to calling standalong build or msbuild targets.

Hi Chris,

Thanks for the suggestion. I think I'll combine the suggestion in your first post (make an entry with the filekey "Bogus" to insure table is build), and they add a post-build step to remove any row with the "Bogus" name using MSI automation. Something like:

Const OUTPUTMSIPACKAGEPATH = "path to output Installshield msi file, use your own variable or command line option"

Dim installer: Set installer = CreateObject("WindowsInstaller.Installer")
Dim database: Set database = installer.OpenDatabase(OUTPUTMSIPACKAGEPATH,1) '1 = msiOpenDatabaseModeTransact
Dim oView

'SQL Command to Delete 'Bogus' entry from MoveFile Table...
Set oView = database.OpenView("DELETE FROM `MoveFile` WHERE `MoveFile`.`FileKey`='Bogus'")
oView.Execute

'SQL Command to Delete 'Bogus' entry from RemoveFile Table...
Set oView = database.OpenView("DELETE FROM `RemoveFile` WHERE `RemoveFile`.`FileKey`='Bogus'")
oView.Execute

database.Commit

Set oView = Nothing
Set database= Nothing

This seem simpler then swapping XML's at build time, or rolling out custom Settings.xml files for our standalone builders which can be replaced by a reinstall or upgrade of that product. Luckily, we sign our MSI packages from a secure signing server after the installer build, so there should be no digital signature problems with post build mods before signing. Anyone using this solution should keep this in mind!

I am hopeful that Installshield would be able to improve this behavior in future versions. The product should get better and better with time... 🙂

Thanks again!

[Christopher_Pai]

I did mean that as a hack. Copying the xml would seem simpler to me. Eitherway, I'd reccomend you look into C# and DTF for build automation tasks requiring interacting with the MSI API and/or ISAuto automation layer. Particularly implementing them as custom NAnt or MSBuild tasks. Script CA's get ugly to maintain after a short while.

[gripper4hire]

Christopher Painter wrote:
I did mean that as a hack. Copying the xml would seem simpler to me. Eitherway, I'd reccomend you look into C# and DTF for build automation tasks requiring interacting with the MSI API and/or ISAuto automation layer. Particularly implementing them as custom NAnt or MSBuild tasks. Script CA's get ugly to maintain after a short while.

Hi Chris,

Thanks for the suggestion! I thought I'd put the VBScript snippet up to help someone who may have a similar problem in the future. Same APIs (and SQL syntax), just a different way of calling them. 🙂

[MichaelU]

Brainstorming here, so pardon any fatal flaws in the idea. Looking from a robustness perspective, instead of making the environment perfect ahead of time, can you instead make your custom action fix up the environment? So when it goes to insert records into the MoveFile / RemoveFile tables, check and add the (temporary) table if it's not already present?

[Christopher_Pai]

That should work also. But I still prefer build complexity over installer complexity. It's alot easier to debug and fix when the problem is in my build environment rather then the end user's machine.

[gripper4hire]

I agree with Chris. It's much easier to control/debug the build environment then it is to rely on (now) several custom actions to fix something the build environment should do, especially when the item in question is something as trivial as including a "standard" MSI table if the standard action is sequenced.

Then again, I tend to be a little jaded as I deal with tens of millions of retail end-users, and a sizable amount of them have "tweaked" (a/k/a weird) Windows configurations. :rolleyes:

The less things a custom action does, the better. Its bad enough the MoveFiles table can't handle something as simple as recursively including sub-directories, hence the whole point of my exercise. :mad:

[Christopher_Pai]

BTW for anyone who cares, the TEMP table records way of getting around problems like mentioned above ( my favorite is that shortcuts aren't formattable.... that sucks for trying to do multiple instance installs with a shortcut on the desktop ) is to have custom actions that emit data into the standard tables and then let the standard actions do what they were designed to do. This is far better then say an InstallScript CA to call CreateFolderIcons() or similar.