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.

Seeking Advice on Limitations/Restrictions of MSI

3 replies to this topic


  • Full Members
  • 1 posts

Posted 22 August 2007 - 15:31


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. 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. 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. 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?


-Ed Lecuyer
Build and Release Engineer
Maptech, inc.


  • Full Members
  • 8 posts

Posted 12 June 2008 - 21:28

Hi, take a look at Wise Installation Studio by Symantec. I have used it in our new installation project and it works. It has a few problems but it works anyway and it's a bit tricky to start out with it but you will get the grip after a couple of months.


  • Full Members
  • 436 posts

Posted 13 June 2008 - 08:44

QUOTE (masterjonte @ 2008-06-12 20:28)
Hi, take a look at Wise Installation Studio by Symantec.

The OP's issue isn't about which tool to use but how to structure the product's installation.

Actually, your scenario isn't really that complex. There was a similar post a while ago and I believe we settled on having the main application as one "product" and the data part as another, where each "product" has its own ProductCode (and therefore its own upgrade/patch path).

As for catering for different map types (the Alaska data having no map, for example) this can be handled easily by feature/component conditioning.

All in all, MSI is perfectly suited to your requirements.
- Don't know why 'x' happened? Want to know why 'y' happened? ProcMon will tell you.
- Try using http://www.google.com before posting.
- I answer questions only via forums. Please appreciate the time I give here and don't send me personal emails.


  • Full Members
  • 1 posts

Posted 13 June 2008 - 14:30

Thanks for the replies.

We ended up deciding to use InstallAware/MSI for the installation of the main application files. There were a number of custom actions that I had to write outside of their scripting language to perform the needed upgrade tasks.

The data portion of the install was written in WinBatch, but I can see now how creating a unique ProductCode for each state might have worked as well. However, I still would have had to make some custom actions.