Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

InstallShield automation chained msi.


4 replies to this topic

scrilla103

scrilla103
  • Full Members
  • 3 posts

Posted 01 August 2014 - 17:49

I'm working on trying to automate with InstallShield. Currently, I'm using the provided automation objects (ISWiProject, ISWiFeature, etc) to dynamically build a project with certain features and components, and then build it with ISCmdBld.exe.

 

However, I can't seem to figure how to link chained msi's through the given objects. Anyone know if this is even supported?

 

Thanks in advance.



deramor

deramor
  • Full Members
  • 187 posts

Posted 03 September 2014 - 23:47

I actually started to look into chained MSI packages a while back and found this to be a critical limitation of the feature.  I find forcing updates to a project file with every release is a bad thing.  I would love to be able to update a chained package properties through the automation api but have found no such function or property.  Have you had any luck?



scrilla103

scrilla103
  • Full Members
  • 3 posts

Posted 05 September 2014 - 18:38

I have actually had some luck with this. Though the InstallShield automation does not provide any method for creating or modifying a Chained MSI setup, there is another option.

 

As long as the project file is saved in binary format (instead of xml), it can be accessed as if it were an MSI by using Windows Installer Automation to edit the database tables. In order to discover what changes needed to be made to which tables, you can save two identical projects in XML format, diff them with a tool and see which tables get modified.

 

My current method of automation for creating a Chained MSI is as follows:

  1. Save a project 'template', containing non-dynamic options and elements.
  2. In that template, add a single, empty, placeholder Chained MSI package (needed so that the other tables have the necessary Chained MSI tools, so we don't have to add them dynamically).
  3. Open that project with Windows Installer Automation in a script.
  4. Edit the ISChainPackage and ISChainPackageData tables to add an entry (in each) for each Chained MSI package desired. You'll find that if you analyze what these tables look like if you were to add packages from the GUI, you'll find that everything is straightforward except for a string preceded by an underscore in ISChainPackageData. This string, as it turns out, is a simple MD5 hash of the file name of the msi.
  5. Remove the placeholder entry from both ISChainPackage and ISChainPackageData.

It's definitely not the most straightforward technique, nor anywhere near easy to implement, as Windows Installer Automation usually lacks good examples, but with a good amount of trial and error and time, it's doable.

 

Cheers.


Edited by scrilla103, 05 September 2014 - 18:40.


deramor

deramor
  • Full Members
  • 187 posts

Posted 15 September 2014 - 15:50

Thanks for the update.  In parallel, I also mentioned to support that Installshield's automation APi is lacking in this area.  Perhaps they will improve upon this functionality and include some functions to automate this operation for you.  I'm sure that whatever function they add, it will do just about the same as your method.  Does the project really need to be saved as binary?  This makes it really hard to diff them to see what has changed.  Is Installshield XML not compatible with Windows installer Automation?



scrilla103

scrilla103
  • Full Members
  • 3 posts

Posted 15 September 2014 - 18:36

Unfortunately, it does have to be saved in binary. The reason for this I believe is because the binary format used is the same format as an MSI, so it isn't that Windows Installer Automation supports InstallShield project files, but that InstallShield project files (when saved in binary format) have an identical format as MSI database files, thus allowing Windows Installer Automation to access them.

 

I too need to have the files stored as XML files for diffing purposes. To get around this, I do two conversions, wrapping my Windows Installer Automation changes. As an example, say I have a function that uses Windows Installer Automation to chain some MSI's in a project. Also assume that the project file that I'm chaining into is stored as XML before the function is called. The function would call InstallShield automation, convert the project to Binary format and save, then do the Windows Installer Automation part (chaining), and then once again use InstallShield automation to re-save the project in XML. In this way, from an external point of view, the function appears to use Windows Installer Automation to chain some MSI's on a project in XML format.

 

Hope this helps clear up the method a bit.

 

Cheers.