InstallShield Media Table Gotcha (BugBug)

It should stand without saying that you should always test your installer using the various ways your customer will install it.   For example, if you are building a CDROM / DVD release don't just mount the network share and navigate to DISK1,  actually burn the folder to media ( or ISO's and mount them ) and use this to test your install.   Doing so would expose the following InstallShield bug that I found using InstallShield 2010.  Perhaps this is fixed in 2011 but I wouldn't know since I don't have it available to me at the moment.

1. Create a feature called A1.1 and give it some components / files.
2. Create a Product Configuration / Release of type CDROM, Compressed and tell it to create 1 CAB per feature.
3. Build and examine the Disk1 folder with windows explorer and ORCA.

What you'll find is a Media table with a DiskId 1 row that has a Cabinet name of A11~1.cab.  That is correct as the Media table only understands short names. ( Yes, I know... this is 2010 AD right? )

Take a look at the Disk1 folder and you'll see a CAB named A1.1.cab.  This is incorrect.

If you drop to a DOS prompt and CD to the Disk1 folder you can do a DIR /X (display short names ) and you'll see   A11~1.CAB for short and A1.1.cab for Long.    However if you burn DISK1 to a CDROM you'll see something different for a short name.  What you see will depend on what type of file system you use but generally it won't be what you expect.  A detailed explanation of all this would take a long time and frankly it doesn't matter to me.    The point is if the media table only understands short names then the cabinet files should match it as short names so you don't have to worry about all of this.

As an aside, another gotcha to watch out for is when you burn a release that has more then 1 disk.  Windows Installer cares about the VolumeLabel in the Media table matching the VolumeLabel on the media.  It doesn't matter that your disk has the right cabinet file name with the right hash,  MSI will keep prompting for the next disk unless this VolumeLabel matches up.   This probably goes back to the 1990's when a 'high speed' CD-ROM was capable of only 300KB/sec.  The problem of course is that in many organizations the group responsible for building installers isn't always the group responsible for media control.   So again, make sure you get a copy of what's actually going to go to the customer and test it before signing off on a release.