In my post here, I discussed a problem I’d run up against having to do with performing an ADMIN installation to a specific drive letter or network path, then unmapping that drive letter and remapping it to some other letter.
If you then attempt a client install, you’ll get either at 1327 error (for mapped drives) or a 1606 error (if you used network UNC paths).
After further testing, it appears that the problem comes from assigning the TARGETDIR property to the AdminProperties property.
Some background:
The AdminProperties property is a “;” delimited list of property names that should be preserved when performing an admin install. The MSI engine stores those property values as they are at the time of the administrative install into the created Client Installation MSI (the MSI file that ends up in the admin install folder). Here’s an example:
and a little closer in…
(Interesting bit of trivia: I have no idea how the MSI engine actually stores these properties in the MSI file, because opening the MSI file with ORCA, I couldn’t find them anywhere. I’m guessing they’re not stored as a normal table entry).
Normally, any properties you’d like to pass on to the client install (ie those collected via the User Interface during the Admin install), you would list as AdminProperties so the MSI engine will pass them on.
I had set the TARGETDIR property as an AdminProperty, because at one point, I believed it was necessary to preserve the path to the Admin installation, so the client installation could make use of it.
This turned out to be ill advised, however, because often, admin installations will be moved (for disk space reasons, reshuffling servers, etc), and preserving the TARGETDIR this way locked the Client install to always point back to the original administrative install. Instead, during a client install, I simply obtain the value of the current location of the MSI file (which, by necessity is the current location of the administrative install) and use it where needed.
At any rate, none of this should have mattered, because the documentation clearly states that the COSTFINALIZE MSI event checks the directory table for valid drive letters, not the Properties table.
However, directories stored in properties listed in the AdminProperties list are appearently special cases, and their validity is checked.
Moral of the story? Use InnoSetup<g>
But, if ya gotta use InstallShield, make sure you do not:
- Store the Admin Installation folder or any folder that might end up getting remapped or disconnected, into a property during the Admin install.
- List that property in the AdminProperties property.
This goes for the TARGETDIR property (a common one), but also any other properties you might create.
2 Comments
This is only somewhat related, but since I just finished fighting an MSI-based install and this thread is a cautionary tale about MSI related weirdness, I figure what the heck.
I just spent six hours wrestling one of my projects which mysteriously stopped working. It compiled fine, but when the user tried to view any reports, the invoked Access.Application object instantly GPF’d the machine. GPF OMG WTF sez me, and long story short it turned out to be Office 2007. Yep, Office 2007 had helpfully replaced all my references to the MSACC9.OLB I use for backwards compatibility with nice new references to its own MSACC.OLB file.
As polite and well-mannered as Office 2007 usually is regarding retrocompatibility, in this one area it fails mightily: if the user does not have Office 2007, then referencing the 2007 .OLB file causes a crash. Can’t really fault it for THAT, but I thought I had things under control. By keeping a separate install of Access 2000, I assumed it would leave my explicit references to the old version intact. Nope.
You’d think it’d be easy to fix this: I reset the VB6 project references back to point to the correct .OLB, not the one in Common Files. Upon recompiling and checking the reference it had reverted back. I hacked the registry, and changed the internal pointers to veer into the Access 2000 folder for the right .OLB… which worked great, until I fired up any Office 2007 app and the hacked references were "fixed" for me. I tried pointing it to another copy of MSACC9.OLB way away on another drive, thinking if I got away from the holy Common Files hierarchy it would break the spell. Alas.
Okay, I’ll uninstall Office 2007 and live with Office 2000 — it’s seven years old, but hey, it works well enough for my needs.
Upon uninstall and reboot, and fixing the VB6 project once more, and yet another compile, I learned the hard way: Office 2007 is The Thing That Would Not Leave. Some undead army of registry gnomes keeps the unwanted references alive, and no tweak / hack / appeal can pry their cold dead fingers from the registry. I’m certain some Office Team developer awoke in the night screaming with the force of my mighty oath: I WOULD remove Office 2007 from my system, even if I had to do it one registry key at a time.
And oddly enough, that’s what it took. Thanks to KB article 98218 — four pages of tightly packed 8pt Arial — I found and removed every file, registry key, and writhing undead service from my system. OSE.EXE anyone?
The process included a manual execution of MSIEXEC.EXE /X filename.msi NOREMOVESPAWN=1 of every friggin Office .msi file in Windows\Installer, of which there are dozens. All the Office service packs. All the goofy add-ons, such as the "ADP Payroll Interface for Microsoft Accounting" which is a complete mystery to me since I use neither ADP for payroll and have never downloaded MS Business Accounting, much less installed it.
The climax was anti: upon the final reboot of all reboots, I reinstalled Office 2000. Literally, I fired up SETUP.EXE and it invited me to "repair my damaged Office 2000 installation" which is a little like asking if I wanted to repair the city of Baghdad. I recompiled my VB6 app. Lo! It worked. I didn’t even need to reset the project references again, as they were happily set to the correct .OLB file.
BTW, Office 2000 reinstalled (repaired?) itself in about 45 seconds, and did not require a reboot. After using Office 2007 for most of this year, I was pleasantly surprised at how *fast* Word 2000 is. Okay, so I gave up "Save As PDF", and "Save As HTML" produces something that looks like a drunken encounter between a shredder and an Interwebs For Dummies book, but I can live with that.
And to tie this back in with the original thread, MSI sucks.
Gad! Good to know. I don’t use Access in my app, but it does use Word, Outlook, Powerpoint and excel. I haven’t seen any issues like this so far, and I have a similar setup (Office 2000 installed, with a side by side 2007 Install, but I still reference all the 2000 Typelibs in my projects).
This is one where I can only partially point the finger at InstallShield. I believe the real problem is with MSI here. Still, I think as expensive as InstallShield is, it ought to be able to trap some of these types of things and prevent them or warn you about them.
For instance, I saw several posts on their KB site that discuss that it’s generally a BAD IDEA to use the SourceDir property from within your install, yet they never warn you about that.
And how difficult would it be to "PRECOMPILE" all the VBS scripts in a project when compiling it to make sure they at least don’t have any SYNTAX errors.
Sigh.