Without ranting too much, there are some amazingly useful things that you probably didn’t realize you could do with InstallShield. Either because the capability is not well documented, or because the feature just lies in an area of InstallShield where it’s likely to be overlooked in day-to-day usage.
Convert an Existing MSI package into a Project File.
File -> Open is known to you if you’ve tried to reverse engineer a vendor MSI Package. But did you know that by changing the Drop-Down list for “Open As” from “Auto” to “Wizard” that instead of opening the project, it will let you create a new project file?
I’ve used this a few ways in the past.
- Regaining Project sources, if the original project file was lost.
- Changing an Uncompressed package into a Compressed package by creating a new release configuration in the new Project file.
- Converting an MSI built with a different tool to an InstallShield project (i.e. Wise, Wix, Orca, InstallAware, etc.)
Obviously, there are other possibilities as well. Generally, this works because most records in the project file have a 1:1 mapping with the MSI database, making backwards conversion possible.
Opening and Editing Setup.exe Files
Not a documented feature, InstallShield will know how to open many older setups built with an equivalent or previous version of InstallShield. In more recently built projects, it even has the capability of saving the updated *.msi file back into setup.exe!
To accomplish this, you have to trick the File -> Open Dialog to display all files. Since it’s a standard windows dialog, you just have to type ‘*’ into the FileName field and hit enter. This then lets you select an *.exe file.
Note: This will generally only work with a setup that contains an *.msi file, and not InstallScript projects. As well, if the package was built with a version of InstallShield newer than what you’re using, this will probably fail and may possibly Crash InstallShield.
Creating a Merge Module out of an MSI Package
Building off of the entry on ‘Wizard’ Mode, once you’ve gotten a setup into an InstallShield *.ism format, the ‘Export Components Wizard’ is available under the ‘Project’ menu. You can export to an existing project file, or export as a new Merge Module Project.
XML System Searches
Need a value from an XML File? Put down that Script! While not natively supported by Windows Installer, InstallShield has quietly supported this functionality for years via a C++ *.dll custom action. Simply view the Help to find more details.
Use Property References All Over the Place
If you find yourself saying, “Boy, I wish X feature could use a Property reference”, there’s a sort of process you can go through to figure out if this is a possibility:
1. Check to see where the Table data is stored. Basically, type a descriptive string into the UI you are using to configure whatever data, and search for it in InstallShield’s Direct Editor.
2. Once you’ve found the table record that holds your data entered in step 1, press ‘F1’ to bring up the Table Reference.
3. If the field has a data type of ‘Formatted’, then it can use a Property Reference. There are some other field types that also support this formatting:
InstallShield-Specific tables (Generally named like ISxxx…) is a separate topic, however. Since these tables are used internally are not intended to be manipulated directly, there’s no table reference for them.
However, while not advertised in all parts of the Product, generally the InstallShield Developers will use the Windows Installer API “MsiFormatRecord” when processing a data table in an *.msi package:
If a data table contains a string value of some sort that’s not obviously used as a Primary key, there’s a decent chance it will be formatted by the associated InstallShield Custom Action at runtime before the data is used. My recommendation is to try a property reference if you’re not certain, and see if this works for you.
InstallShield MSI Tools
When you’ve got an MSI that doesn’t work quite right, what do you do? That’s what these were designed for. The InstallShield Help contains information on these, but I’ll list what I find to be most useful:
MSIDiff.exe – Allows a Visual Diff of two MSI databases. Incredibly useful when some new revision breaks, and you are not certain why. Or in the case you are trying to diagnose a tough Patching issue where the state of the database tables becomes very relevant.
MsiSleuth.exe – Allows you to see the various Product, Feature and Component states for MSI packages. This I found to be useful when Virtualizing MS Office, since Microsoft Office uses Windows Installer API’s to determine whether it should manually trigger a repair or not. In this case, I added this tool to the sequenced App-V package.
RegSpyUI.exe – Not officially an “InstallShield MSI Tool”, this tool is a standard part of InstallShield, and gets placed here:
This little tool lets you take control of extracting COM Information from a particular file. In the case of *.exe files, it simply runs the *.exe file with the /RegServer parameter. If your application doesn’t specifically handle this parameter, this will also capture other registry configuration that occurs before the application exits.
Making Order from Chaos
Sometimes it becomes necessary for records to be processed in a particular order. However, Windows Installer is not designed with this in mind, since like-operations are done at once instead of installing discrete units of files and registry data piece by piece.
One common scenario is the need to register *.dll files in a particular order, due to dependencies between the modules. Which, as we can see, the SelfReg table contains no ‘Order’ column with which to accomplish this:
Luckily in this case, the InstallShield style of self-registration (a setting under Tools -> Options -> Preferences) uses the ISSelfReg table which contains an Order column:
But what if the table didn’t have an ‘Order’ column? In the absence of a field that specifies the order in which records are to be processed, there are a couple of things that can be done to mitigate the issue of ordering.
Windows Installer, being just a database that gets processed by a Windows service (msiexec.exe), typically processes records in the order in which they are returned from the database. The order it uses for this is based on the order in which the records were entered into the database, so there is 2 methods of implementing the order here:
- Changing the Project File format from Binary to XML. This stores records in a human-readable format that you can specify a particular order, which determines how InstallShield ends up inserting the records into the table while building the project.
- Cutting and pasting the records in question until they end up in the correct order. In some views of InstallShield, such as the XML File Changes view, records are displayed in the same order that they will be processed later, so if you’ve implemented it correct, it will be visible here.