I’ve been hunting down an issue with an InstallShield Installation for almost a week now.
Very strange. I have a new installation that is a BASIC MSI install (meaning it contains no funky InstallScript at all, and is this fully MSI compliant).
It is intended to upgrade several previous installations, one of which is also a BASIC MSI, but the others are all InstallScript MSIs.
When I first started testing the upgrade process, I did the install of the old version, followed by an install of the new version. When I went to ADD REMOVE PROGRAMS, the new was there, but the old version was as well. The upgrade didn’t work.
Grrr.
So I start digging. Eventually, I determined that the old version was actually being uninstalled (I paused the install midstream and sure enough, all the old files are one point are completely removed). However, for some reason, the entry in the Add Remove Programs list was not being removed.
More digging.
So I reset my test, installed the old version and at Macrovision’s request, I searched the reg and found a key here:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{F1C8EEFE-8019-44AB-8AA9-D6F13E3BFAF0}]
that contained all the info about the old installation.
There’s a value called NOREMOVE set to 1. Hmm, that sounds suspicious. So I set it to 0 and install my new version.
No joy, the old version is still listed in ARP. However, when I went back to the registry to check that key, it was gone! What the hell!? Ok, the entry in ARP must be coming from somewhere else. A few reg searches later turned up this key:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\InstallShield_{F1C8EEFE-8019-44AB-8AA9-D6F13E3BFAF0}]
Notice that the GUID there is the same as the other GUID, but this one has “InstallShield_” at the front of the key name.
Delete THAT key, and suddenly, the ARP entry is completely gone.
It would appear that upgrading an InstallScript based install with a BASIC MSI install unintentionally leaves behind a key that it shouldn’t. Some searching the KBs with more specific keywords turned up exactly that.
An InstallScript based install created two entries in the Uninstall registry key, but one is ‘hidden’ from the ARP list view.
A Basic MSI install only creates one key. And if you upgrade an InstallScript based installation with a Basic MSI installation, that second key (the visible one) won’t get removed properly.
You have to add an entry to the RemoveRegistry table in the MSI file and connect it to a component that will be installed by your new installation.
Didn’t table-driven programming constructs die back in ’91 with Magic. No, wait. Ack, they’re still alive?!
Well, tried it then and hated it, still hate it today. To each his own.
7 Comments
Am I completely delusional, but wasn’t one of the big selling points of .NET the elimination of "DLL Hell"? The idea that each application was self-contained enough that you could (literally) copy it to a folder on your drive without an installer?
Kind of like DOS days?
Oh, how I miss that. Back to my rocking chair and strained peas…
Hehe
No, you’re not delusional. .NET does go a long way towards helping with DLL hell. The prob is that at this point, there’s tons of stuff that requires COM plumbing (take the Office Addin architecture for instance). If you want to do that stuff in .NET, you get to deal with COM shims, etc etc and you’re right back where you started from. Maybe not quite as bad off, but still.
I remember when MS said "Don’t use INI files any more, that’s what the registry is for!"
And now we’re back to glorified, hierarchical INI files (otherwise known as XML files).
I still think for a large majority of apps, INI files are perfectly fine for saving config settings. And they’re readable without running the XML through a formatting step before you save to keep it from getting rendered all on one line.
I *love* INI files! So much nicer to have somebody email me a copy of their INI file for troubleshooting rather than walk them through a RegEdit session.
And INi files don’t get corrupted or "cleaned up" by registry tuning software.
And they fit entirely in RAM if you want to cache them for speed.
And they’re editable with any tool that can handle a plain ASCII file.
AND they stay crunchy in milk, improve your credit rating, and prevent rabid marmoset infestations.
Plus if you rub ’em under your arms, you stay fresh all day!
Yes, I like the hierarchical abilities of XML, but, for almost all the config needs I’ve ever had, the simple [section]key=value layout was just fine.
And having to run xml through an extra step just to get it to format readably before you save is annoying. Maybe that’s and MSXML-only thing, but it bugs me.
Seems like it should be an option to save it in the "compressed, non-readable, globbed onto a single line with no whitespace" format for the few times when you don’t care whether you can read it or not.
But then, I’m a stickler for the obvious.
I played with MSXML for a bit before going "meh" and looking for some simpler solutions. Sometimes you need a pocket knife, and MSXML is more like a chainsaw. A 400 pound nuclear chainsaw that takes an hour to warm up but will cut through an engine block in five seconds.
I have an XML project coming up and I keep thinking I’ll try that chainsaw again. Any pointers to a more lightweight XML implementation? I’m not a slave to standards, and I doubt my client is.
Sometimes when my medication wears off I daydream about writing my own parser. I’ll get right on that after I finish inventing this thing I call a "wheel".
Mine’ll have playing cards in the spokes.
Over the years, I ran into several VB6 xml parser projects, in various states of completeness. Nothing even close to MSXML, but then, you don’t regularly need that functionality/baggage anyway.
Thing is, these guys are dated back to 2000/2002 and none of what I downloaded appears to contain anything like a readme/credits/etc. I have no idea who wrote the stuff or URLS.
I could zip it all up and send it along, if you like. For simplifying a project, there’s nothing like getting all the code under one umbrella.
As for commercial/current XML tools, I couldn’t help much on that front. MSXML isn’t too hard once you get a few helper routines written to handle some of the grunt coding, and it’s pretty much guaranteed to already be on any machine your app is likely to land on. I’d just go with it.
Doesn’t .NET have a built in XML parser? With a 20MB runtime, it ought to.
Thing about it: with a 20MB runtime, it should have a complete implementation of VB6 in there. Would solve a lot of backwards compatibility issues.
Yes, please email me your bag-o-XML parsers; perhaps there’s something there that’ll be useful. Thanks!
And I probably will end up using MSXML, since as you say, it’s built into Windows nowadays.
I fret over Automatic Update sometimes — the user downloads a security patch and Windows breaks in subtle ways. Has MSMXL been a good citizen? Does version 6 work with output generated by (say) version 4?