§ ¶Windows Installer... well, you know
I've never kept it a very good secret that I don't like Windows Installer. It's slow, it eats an unreasonable amount of disk space for caches and even more disk space during installation (>3x install footprint), it throws errors that are cryptic even to programmers, and it has lame limitations like needing to map the entire installer into contiguous address space on XP. My experience installing VS2005 SP1 was so bad that I now keep around a slipstreamed install just so I never have to run the horrid patcher again. I believe I've found a new reason to hate it:
If TARGETDIR itself isn’t redirected, it defaults to ROOTDRIVE which is the fixed drive with the most free space available, and “fixed drive” doesn’t necessarily mean its an internal drive. External drives these days are growing more common. Any descendants of TARGETDIR are also located relative to ROOTDRIVE then.
So if you have an external drive with a lot of free space connected when you installed Visual Studio, a number of components may have gotten installed there. Even if you do not see any files mysteriously appear after installing Visual Studio, components may still have gotten registered to the other drive. This can actually happen for any Windows Installer products.
If I understand this correctly, this means that if I'm on a system where the system drive is C:, the Program Files directory is on C:, and I tell the installer that I want Visual Studio installed on C:, the default behavior for the install system unless overridden by the install script is to install onto the external backup drive H: that I just happened to have plugged in. This might explain why I keep finding weird installation folders like Office10 in places such as my data drive and video capture drive that I explicitly do not want programs installed into!
Could someone at Microsoft pleeeease write a better install system....
thats interesting. always wondered what those files are. what a ****.
tobi - 19 08 09 - 22:45
oops. And I thought it'll take so long to install a few kilobyte of software because the installer always tries to connect Bill G to ask him for the personal grant to install this software on this PC. An because Bill and his guys are always very busy the installer has to wait forever. But this is even worse: my remote drive has more than 100 MB free space, more than any of my internal drives have. But I am connected through a slow 200 kBit/s line. Now I know. Disconnct external drives before installing via Microsoft installer.
Ecc - 20 08 09 - 00:43
And let's not forget about the registry, MSI bloats the registry more than anything else out there (Well, that and .net)! Just take a look in HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer and HKEY_CURRENT_USER\Software\Microsoft\Installer
asf - 20 08 09 - 02:28
I hate it for:
There might be more, but it's late here.
Igor Levicki (link) - 20 08 09 - 11:48
Well, that's what you get when Microsoft decide to copy Debian's package installer...
Mitch 74 (link) - 20 08 09 - 19:24
Which is why commercial programs like InstallShield cost such an extortionate amount. They fix things like this. For our project (hundreds of files, 3GB+, installed), it's a necessary, but expensive, evil. Don't let me get started on the terrible user interface, sluggish performance, and the brain-damaged scripting. And, this is the market leader.
Of course, Microsoft would never
use a competing product even if it was better.
I like the fact that I can just drop virtualdub into a directory, and it works. But then, I started back when there were no installers. I wonder if you have considered using an open-source installer like nsis for your projects. We, alas, can't because our project is too large, and the time it would take to convert.
Btw, virtualdub is our go-to utility for creating our final videos.
dl - 21 08 09 - 02:50
innosetup nsis ...
chornobyl - 21 08 09 - 05:19
installshield is crap. we use it in our company. i'm working on converting our setups to wix.
.msi has many advantages also. it's necessary for distributing software in companies easily.
GoD - 21 08 09 - 06:17
Those advertised installs (sudden repairs trigerred by COM garbage they're talking about in the blog) are pain in the a$$.
Most of the time, it can be cured with msicuu, but sometimes the actual program (.EXE) is hardcoded to look for installer data. Examples: MS Office, Daemon Tools - yeah, that's a surprise (looks for language component). I contacted its developer some time ago (I never installed version higher than 2.47, or was it 3.47; abandoned it due to crashing, and I don't want/need stealthing) and he replied: "MSI is the most advanced technology there is. :)
GrofLuigi - 21 08 09 - 12:28
Oh please, please, somebody -do- write a replacement to any of the installer kits.
Windows Installer = bloat, limited, .MSI packages suck, etc.
InstallShield = bloat, slow, craptacular, etc. ( How can you tell you're running an InstallShield installer? It sits there doing the "Calculating space requirements..." and "Verifying installation..." tasks for half a minute for even 300KB installers.)
Wise = exact same as the above.
InnoSetup = behind the times, sadly.
I ended up going with NSIS (which is also getting outpaced by Windows developments, but at least you can work around most of it). But BOY are you in a world of hurt when you choose NSIS. It's powerful, it's flexible, the scripting language almost makes sense (incorporating LogicLib.nsh is a -must- if you don't want to lose your sanity.), but then comes the hurt.
Do you want to write an installer that features an uninstallation component that only uninstalls installed files? No can do out of the box. The only community-supplied solution basically does a diff of the installation dir before installation and after installation, then tells the uninstaller to kill the diff. This, of course, fails if you're simply installing an update (don't ask me how to write an update installer; heck, don't ask anybody, these days, Apple will happily throw you an 80MB fresh new installer for the latest QuickTime instead of updating from what version you have). Had to write my own - would contribute it back, but apparently the method I use is ripe for breaking come a future version of NSIS, and they'd rather not have a script become popular, then get broken later. Hoo-ray!
If somebody could write a replacement for all of the above that would 1. work, 2. work fast, and 3. be reasonably flexible (plugins are neat-o, and I do use them in our NSIS installers quite a bit, but mostly to have functionality that should have been provided out-of-the-box, or to add fluff), I certainly wouldn't mind paying for it -at all-. ( NSIS being free/free was not a decision-driving element )
on-topic: wow. that's pretty dumb. I'm glad the msdn guy acknowledges this (without stating so explicitly)
PleaseDoWriteAReplacement - 22 08 09 - 09:44
FWIW, these are just some of the reasons why I switched to Null Soft Install Scripting (http://nsis.sourceforge.net/Main_Page
) some time ago. It also has an Eclipse plug-in (http://eclipsensis.sourceforge.net/index..
). Its rather slick and simple to make an installer when you use the NSIS wizard from within Eclipse.
Scott - 23 08 09 - 11:51