I acquire consistently admired to assay adapted brands of swiss fake watches affluence watches. If comparing the above brand, there are replica watches uk not abounding differences you can accretion distant from the above of replica rolex uk the replica. You can accretion some of the best Patek Philippe replica watches and acquire abolishment to rolex replica say added than your architectonics or you could accretion bigger above and a lower replica hublot watches casting and achieve your best easier.

REG_MULTI_SZ and Windows Installer — Visual Basic Feng Shui

REG_MULTI_SZ and Windows Installer

Filed under Installations

image I have an InstallShield 11.5 based installation, and, at some point, it went south, but in a very subtle way that I did not immediately notice.

For those with a short attention span, I’ll summarize the issue like so:

DO NOT use the “System Search” ability in InstallShield (or the REGLOCATOR table in MSI, for that matter) to retrieve a registry value of the “REG_MULTI_SZ” format.

Doing so appears to cause Windows Installer to internally skip large portions of  Maintenance mode operations, such as Repair, or Remove.

Essentially, the problem was this…

If you open the ARP (Add Remove Programs list) and select a “normal” install, you should see two buttons, Change and Remove.

Clicking Remove will work perfectly fine, regardless of anything I mention here.

Clicking Change, on the other hand, brings up the “Maintenance Mode” screen of an InstallShield installation.

From there, you have 3 radio button choices:

  • Modify
  • Repair
  • Remove

So far so good.

However, in my installation, none of those options actually DID anything anymore. The progress bar would update and go to 100%. You see things apparently happening, but when it all finished, nothing actually had happened.

Now, they ALL worked at one point, but exactly when things broke, there was no real way to tell. This install is >100MB, so I don’t make it a habit of checking in all the various interim builds of the install.

All I did know was that the last released version (which I did have laying around<g>) worked just fine, but the latest version did not.

What’s worse, the last released version was dated some 8 months back, and there had been literally hundreds of changes to the install in the interim, including removed and added files, new scripting, new components, etc.

After working with Macrovision for almost a month and a half, I’d still made absolutely no headway on the problem.

The prospect of reverting back to an 8 month old version and redoing every individual change, along with testing the install to make sure that the maintenance mode would work after each change, was, to the say the least, utterly horrifying.

Macrovision had no thoughts as to even how to debug the issue, much less what might be causing it.

Very early on, I’d already hit on the obvious things.

  1. Generating a full verbose log of both the old, successful install and subsequent uninstall and comparing that to the same log from the new version yielded no clues.
  2. Saving the ISM files (the InstallShield source of an installation project) as XML files and the comparing the old and new also yielded nothing that stood out as a problem.

Long story short, after several days of applying the various changes to the early, working version, I got extremely lucky and stumbled on the cause of the problem.

I’d added several “System Search” items to detect already installed prerequisites and the retrieve specific system information I needed during the installation.

One of these was to retrieve the “InstalledInstances” value from the registry key

HKLM\Software\Microsoft\Microsoft SQL Server

image

This functionality isn’t really InstallShield based, it’s a part of MSI from what I can tell. The definition of the system search element is actually stored in the REGLOCATOR table in the MSI file:

image

So, at least for now, I can’t blame this one on InstallShield.

As it happens, that registry key is a REG_MULTI-SZ value, meaning it can have a single string value, or multiple values, separated by null chars.

And it just so happens that on my test machine, I had two different instances of SQL Server installed, so there just happened to actually be a REG_MULTI_SZ value in that key.

And THAT was the cause of all this headache.

What’s truly ironic about all this is that the installation wasn’t actually using the property that resulted from this System Search anymore. At one time, it checked the listed installed instances of SQL Server for their applicability to our install, but I’m not actually doing that anymore.

Moral of the story? Don’t use the SystemSearch capabilities of an MSI install to retrieve a REG_MULTI-SZ registry value. It’ll work, but then the maintenance mode of your install could very likely fail inexplicably, not to mention what other consequences I haven’t stumbled upon.

Lastly, I did some googling once I’d narrowed things down and found, well, nothing, on the web or MacroVision’s site about it. Maybe what I’m seeing is something specific to my particular machine, maybe not. Given InstallShield’s resistance to being installed twice on different machines with the same license, I’m not willing to jump through those hoops just to test that suspicion.

But maybe this will help someone else caught in those same throes.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*