MSI 4.5 is out, and it has a new feature that allows you to embed a custom UI handler inside the package and invoke it without needing bootstrapping setup.exe.
Pretty cool, right?
But wait, I see a Chicken and the Egg problem. How do you first get MSI 4.5 on the machine to use this feature? Well, with a bootstrapping setup.exe of course!
Hmmmmm
Now, I know some will argue that you can just set the Schema to 405 and make the user go resolve the problem on their own. But is this really a good user experience?
Then of course who really wants to be writing a custom UI in C++? WinForms is so much easier. Hopefully DTF will be updated very soon to support this capability.
But wait, there is another Chicken and the Egg problem. How do you first get NetFx20 on the machine? Well, with a bootstrapping setup.exe of course!
Hmmmmm
Now, I know some will argue that adding a .NET dependency to the install is a bad thing, but WinForms really rocks.
Now InstallShield has a very capable bootstrapper, and I'm glad I have it. But I do like the vision ( even if we aren't all the way there yet ) of having a single MSI that we can just run.
Am I missing something? Is there another way to solve this problem? Or is it just a matter of waiting several years until everyone upgrades to Windows 7 and we can be confident that MSI 4.5 and .NET 2.0 is already on the box? If that's the `solution` to the Chicken and the Egg problem, I wish this feature had been in MSI 1.0.
It kind of reminds me of why the Commodore 128 was such a failure. It had all these new capabilities that were never used because there were just way too many Commodore 64 owners who couldn't be ignored. We software developers do tend to write for the least common denominator after all.
You are defiantly correct, I was scratching my head the last couple of days, I found the 4.5 story yet incomplete and I was expecting the 4.5 will be pushed via WU but I think MS didn't finish the story for backwards compatibility? Who knows really the reason? But until good deployment solution introduced, the 4.5 will be on my shelve; I'm also looking for InstallShield to come up with yet another better resolution and easier way to resolve the chicken and the egg problem with 4.5 release.
ReplyDeleteWael();
I seem to recall a comment where the MSI or WiX team said that 'custom actions are required because the platform failed you' (or something to that effect). This seems like the MSI platform has failed us in, of all things, the deployment story.
ReplyDeleteHi Chris,
ReplyDeleteover the last few weeks I have noticed you making lots of comments about the lovely isscript component supplied by IS.
I see your point's and you always back them up with some good technical standings which i admire.
But I just have to ask have you ever been on the enterprise side of deployment ? I am making an assumption you are a developer who needs to get out a single application regularly (don't get me wrong i see you as a highly regarded technical person)
But I have to ask have you ever sat with an enterprise deployment team for a day to see the issues they face with this abomination referred to as install script.
The day this is a single installer approaches many packagers will be very happy.
To go over a few points here, installscript offers many developers a nifty little way to get stuff on the machine easily by whipping up a quick bit of code. However do they always need to do this ? I think many times the answer would be no.
Windows installer is a complex beast but I feel that is not an excuse to use ISScript at every chance when there is a perfectly good native way of approaching the same issue.
Now some reasons why ISScript is such a pain in the proverbial butt.
1) it deploys DCOM objects (no issues here)
2) after doing so it promptly permissions those DCOM objects using APPID registry to allow local access only.
Now as most enterprise admins do, they try to push these applications remotely. Again no issues there.
Next the isscript gets deployed DCOM goes down, perms get set on DCOM objects. then the trusty application goes down. Whammo ! your hit with the trusty old ISScript is not installed.
Why you ask ? i just installed it ? The answer to this dilemna is the installing user doesnt have permission to the DCOM objects because it is not a local user specified in the NTFS of the DCOM.
From the opposite side of the fence to where you sit its a complete pain. Agreed its the package dev who causes the issue alot of the time but my question is what exactly is the reason it is needed so much when Wise for example doesnt offer a product of the same type nor do wise packagers experience the same pain ?
Over to you Chris (ps keep up the great work on your blog)
It might be a useful blog post to give an overview of my career. After all, my desire to write setup comes out of my SysAdmin days.
ReplyDeleteTo be brief, I spent 2 years at Continental Airlines where I was the team lead for a (re)packaging team that was part of a larger SMS 2003 team and a larger Enterprise Engineering team. In that role I held a broadly defined role of `application integration` for both internal and external proucts deploying to an 18,000+ seat domain forest. I've also put a great many more years in the ISV / Consulting role for everything from one off installs to Product Line Developement environments where we are maintaining dozens of installs using a common code baseline.
Now, let's talk about InstallScript. The problems you describe come from versions of InstallShield prior to 12.0. Starting with IS12.0 (released 2 years ago ) the entire design was refactored to eliminate all of the problems you describe.
If you go back through my history of blog posts, you'll find that I've discussed this ad nauseum. :-)
Yes, the old InstallScript was horrible. It caused the majority of my install failures at Continental, that is until I figured out how to hack the DCOM Launching Impersonation settings. Then it was quite reliable. But now that it's refactored, you'd never even know it's there.
Now as I recently blogged about while discusing the new Yahoo! Toolbar CrapWare.... it takes a long time to heal from these kinds of mistakes as you are no doubt seeing in production environments.