Top 10 Issues in InstallShield that will bite you!
- Never use Dynamic File linking. Never, NEVER! Causes severe problems when attempting Upgrades/Patches. More posts have been written on how to work around issues caused by this.
- When creating Custom Actions, always name it unique (i.e, ISI_StopServices, ISI_ModifyRegistry) – this will assist you in quickly determining if the C.A. was successful within the MSI logging.
- When referring to the same file numerous times (for example a specific version of a Release Notes) try to make a string value and reference the string value (@Release_Notes). This will prevent having to locate each and every occurrence when the name changes.
- Caution when using SQL within project – default will attempt to uninstall scripts at application removal, which will destroy customer data. Always leave database data populated – let the DBA handle deletion.
- Issues with XML within project working – most Developers cannot get it working correctly – check the message boards. If you use XML query to grab values during a AppSearch, expect excessive time delay.
- Have staging for binaries separate from the compile output directories to ensure only specific items are handled within project. This will ensure that when a build process fails, the last good compile is not incorrectly incorporated into the InstallShield CAB files.
- COM Extraction
- Concept works most of the time – but must guard against developer hard include of ATL code, and situations which end up having the developer workstation machineIDs incorporated into web server configs.
- Never run COM Extract at build time – extract and verify and freeze. Granted, this runs the risk of developers adding functionality without notifying IS Developer who will need to extract COM again. But when they do this, you may encounter possibly new Microsoft Redistributables need to be included as well.
- Personnally I recommend never do COM extraction. Use scripting instead to register/unregister all files for ease in specifying sequence. Yes, you could use properties to select registration – but then need to use DirectEdit on the ISSelfReg table to specify sequence – which applies to both install and uninstall. Think of long term maintenance aspects – Keep It Simple, Simpleton! NT Services
- Again the issues with COM Extract has caused me serious problems with hard includes of ATL code
- I cannot easily specify which other Services to stop/start in specific order when I have more than one service – consequently I use scripting to Stop/Start the services when required
- I use scripting to create the services and then unregister the service on uninstall.
- Windows Installer “Repair” capability has issues. Although typically the restoration of a DLL/Executable has been flawless (when used with Static File Linking), the Repair process also will drive in the InstallShield project registry. In my situation, the registry template carried in the IS Project will have properties (Version, INSTALLDIR, [PropertyValue]) that are reflected within the project registry – I also take customer input from the dialogs and translate that into fields to update the registry after it has been applied to the workstation. Since the “Repair” process does not present dialogs – so it doesn’t resolve the property values – the resulting registry is essentially corrupt because of missing values. To resolve, I have created Custom Actions that run before a “Repair” to archive the registry to a file, and another Custom Action that runs after the “Repair” to delete the registry and restore from the archived file.
- InstallShield version 12 has been radically restructured and you may encounter serious issues within your project’s scripts when you upgrade. For example there are the issues that I have encountered:
- Global variables will no longer pass information to scripts – but no message is given, either during compile or execution – just blank values received.
- Within the “Execution Sequence”, the ability to extract values from predefined directories (INSTALLDIR, SETUPEXEDIR, PROGRAMFILES) will no longer work. Again, no message is given, either during compile or execution – just blank values received.
- Within the “Execution Sequence”, the ability to extract values from MSI Properties that were defined during the “UI Sequence” will no longer work. Again, no message is given, either during compile or execution – just blank values received.
- Conceptually, the use of the MSI Property “CustomActionData” is allowed – but severe gyrations required to pass multi-value string into the MSI Property during the “UI Sequence” for retrieval during the “Execution Sequence”. I ended up writing all of the values needed in the “Execution Sequence” to a registry while they are accessible during the “UI Sequence”. Then during the “Execution Sequence” when I need a value (i.e,., INSTALLDIR), I extract the values from the registry.
InstallShield Tips and Techniques
InstallShield Tips and Techniques