Hello,
I have been tasked with migrating our installation system from InstallShield 3.0 (yes, 3.0) to something a bit more modern. The main reason we are still employing IS3 is because of the custom nature of our install. Please allow me to explain...
We have a main application that displays map data. The map data resides on multiple CDs, and are sold in sets by the state. Ex.: 14 CDs for California, 3 for West Virgina, and some sets - 10 CDs for New England's 6 states.
We also include (one for each state) an "Extra Data" CD, which basically consists of non-map databases to be used in conjunction with the Map CDs. These databases must be installed on the user's hard disk at install time.
Because the Application is updated 2-3 a year, it is necessary to keep it separated (via an "Installer CD") from the Map Data CDs and the Extra Data CDs. Moreover, the Map Data CDs and the Extra Data CDs are updated occasionally without necessarily updating the Installer CD. Oh, and we need a system where new states can be added to existing installations, and we need to be able to migrate older directory structures and data files into the new system.
As you can imagine, its quite complex. The existing system (in IS3) works, but has been hacked so much (like to remove the 16-bit wrapper for Windows 3.1 compatibility) that it really needs to be rewritten.
I was thinking about using an MSI-based installer. We have InstallAware 7. However, it seems to me that if the data on the "Extra Data CD" changes, the database in the main setup application (on the separate Installer CD) also needs to be changed. (I have implemented this via Web Media Blocks in IA.) This is not a good solution for us.
I also would like the data on the "Extra Data CD" to be compressed. Ideally, these compressed files could be combined onto regional DVDs which would help our warehouse and reduce duplicating costs.
Meanwhile, I don't want to create 50 or so different sub installers that effectively all do the same thing, but just with different data files.
Oh, and some states don't have all data types available, so the installer has to be able to handle that. (For example, we don't offer photos of Alaska, but we do have them for the lower 48.)
At any rate, I've been looking at trying to accomplish all of this with MSI, and I am starting to think that it will not be possible. Besides InstallAware 7, I also have InstallShield 12 (sorry.) This might be the tool to use, but I am not sure if it can elegantly deal with different combinations of Installer and Extra Data CDs, either. At first, I was considering making Merge Modules for each state's "Extra Data" - but those would have to be on the Installer CD and that won't work due to space requirements.
The other option is to abandon MSI altogether and write my own install platform in a windows scripting language like VB or WinBatch. While it would be lots of work, I would have complete control and ultimate flexibility. However, I fear that MSI based installers are going to be the norm as Windows continues to evolve - especially in Windows Vista, etc.
So, anyone have any good ideas or advice?
Thanks,
-Ed Lecuyer
Build and Release Engineer
Maptech, inc.
Seeking Advice on Limitations of MSI/InstallAware
-
Mark Fulford
- Posts: 25
- Joined: Tue May 23, 2006 2:22 pm
I’m also seriously considering writing our own installation platform. From what you've said, there are similarities in our installations.
Most of our installations are for add-ons to a core product. During installation the add-ons overwrite files which were originally installed by the core product. For example, the core product comes with basic symbol sets. Our customer buys an add-on which replaces the basic symbol sets with better ones.
The problem we (and others) found is that, for no obvious reason, some files from the add-on would not overwrite the previous version, but others would. We'd get a 99% successful installation - so a ton of tech support. We spent ages on this problem and could find no obvious explanation or pattern to which files weren't overwriting. Specifically it was nothing to do with file dates, versions or locking. We concluded that it was an MSI bug.
The first solution we used to force an overwrite was to delete the older file first. In the context of 1,000s of files being replaced (but not by a wildcard), this had to be done file-by-file (line-by-line in code) – which was totally impractical.
The workable solution we're now living with is a hack and cobble. We use password protected self-extracting zips to silently unzip the new files over the old ones, totally removing MSI from that part of the operation. InstallAware’s job has been reduced to creating registry entries and calling appropriate zip files to unpack. For that reason, it's a small step to completely ditching MSI.
Most of our installations are for add-ons to a core product. During installation the add-ons overwrite files which were originally installed by the core product. For example, the core product comes with basic symbol sets. Our customer buys an add-on which replaces the basic symbol sets with better ones.
The problem we (and others) found is that, for no obvious reason, some files from the add-on would not overwrite the previous version, but others would. We'd get a 99% successful installation - so a ton of tech support. We spent ages on this problem and could find no obvious explanation or pattern to which files weren't overwriting. Specifically it was nothing to do with file dates, versions or locking. We concluded that it was an MSI bug.
The first solution we used to force an overwrite was to delete the older file first. In the context of 1,000s of files being replaced (but not by a wildcard), this had to be done file-by-file (line-by-line in code) – which was totally impractical.
The workable solution we're now living with is a hack and cobble. We use password protected self-extracting zips to silently unzip the new files over the old ones, totally removing MSI from that part of the operation. InstallAware’s job has been reduced to creating registry entries and calling appropriate zip files to unpack. For that reason, it's a small step to completely ditching MSI.
IMHO, you should consult an InstallAware consultant on very complex installer. Generally speaking a normal user of IA like me never create so complicate systems.
CodeGear uses IA to deliver Delphi with help of IA consultants, so you may have a try.
In fact, I never meet bugs in IA. Most of the times, I just write some code wrongly.
CodeGear uses IA to deliver Delphi with help of IA consultants, so you may have a try.
In fact, I never meet bugs in IA. Most of the times, I just write some code wrongly.
MSI
MSI seems real picky about file dates and versions. It looks like some files although the revisions may be different do not get overwritten and when recursice delete fails, I have resorted to using an old wise script program in the Pre-req to delete the files first, retreiving a return code if a reboot is needed.
Never have any problems if the user has already installed using MSI Installer and you are replacing the same files, as the Uninstall Previous Version Pre-req seems to handle it fine.
You should also make sure you app is terminated before you try and update any files.
Never have any problems if the user has already installed using MSI Installer and you are replacing the same files, as the Uninstall Previous Version Pre-req seems to handle it fine.
You should also make sure you app is terminated before you try and update any files.