Yet another time the msi installer has taken me an hour. Something somewhere overwrote a dll, or replaced a path to it with an encrypted one, as described here. Solution? Simple: reinstall the app which stopped working.
Ah, if only it would be so simple. The installer goes for good two minutes to build a script... which then can't execute because it can't find the installer at the original location, from which it was installed years ago. This is utterly ridiculous: the installer can't find itself! And for some reason, it refuses to continue.
My best guess is that it's looking for an installation log. Now why would that log be anywhere else but the target folder is beyond me; why would it be in the source folder makes even less sense. What if we're installing from a removable drive, or (like SQL server) from a temp folder which will vanish? No matter whether it's looking for a log or set of choices made at installation - there's no good reason to keep that file anywhere else on the disk, but on the target folder.
And why would we be obliged to keep the installations on our disks forever? Again, what if it's on a CD? Or what if the CD letter changes?
In this case, the original path was pointing to an UNC - the setup was on another machine. Five years later, that machine is not there anymore. Is it possible that nobody in Redmond was thinking of this? They have these mass deployment techniques, where you run a typical setup by just issuing a single command and the whole setup runs unmanned off a server share. In such environments, the servers are regularly replaced every few years - and the msi installer still expects the server name, share and path to remain the same forever, or you can't even uninstall... without poking into registry.
Which I had to do, of course. One of the reasons to introduce registry was to have such things written in one place. Yeah, right. That one place turned out to be about twenty different places in various corners of the registry.
There's a solution, of course - skip the whole msi story, and use Inno Setup. Which I'm doing for years, for things that I build. But things built in Redmond will remain a problem.
Ah, if only it would be so simple. The installer goes for good two minutes to build a script... which then can't execute because it can't find the installer at the original location, from which it was installed years ago. This is utterly ridiculous: the installer can't find itself! And for some reason, it refuses to continue.
My best guess is that it's looking for an installation log. Now why would that log be anywhere else but the target folder is beyond me; why would it be in the source folder makes even less sense. What if we're installing from a removable drive, or (like SQL server) from a temp folder which will vanish? No matter whether it's looking for a log or set of choices made at installation - there's no good reason to keep that file anywhere else on the disk, but on the target folder.
And why would we be obliged to keep the installations on our disks forever? Again, what if it's on a CD? Or what if the CD letter changes?
In this case, the original path was pointing to an UNC - the setup was on another machine. Five years later, that machine is not there anymore. Is it possible that nobody in Redmond was thinking of this? They have these mass deployment techniques, where you run a typical setup by just issuing a single command and the whole setup runs unmanned off a server share. In such environments, the servers are regularly replaced every few years - and the msi installer still expects the server name, share and path to remain the same forever, or you can't even uninstall... without poking into registry.
Which I had to do, of course. One of the reasons to introduce registry was to have such things written in one place. Yeah, right. That one place turned out to be about twenty different places in various corners of the registry.
There's a solution, of course - skip the whole msi story, and use Inno Setup. Which I'm doing for years, for things that I build. But things built in Redmond will remain a problem.
0 back and forths:
Post a Comment