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!
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!
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.