Apple Safari setup built with WiX
Apple’s Safari browser is now available in public beta on Windows. A little spelunking shows that it uses Windows Installer packages and that they’re built with WiX. Sadly, they didn’t use WixUI.<g>
On a more serious-but-sad note, the packages have ICE validation errors (other than the typical ones), contain VBScript custom actions, and the main Safari package uses a custom action to install the Apple Software Updater package (instead of using a chainer). Already there’s a forum report of a 2738 error with the VBScript CA. And I guess the only way to report bugs is via forum posts…? It’s not clear. The “Report Bugs to Apple” command on the Help menu seems focused on rendering problems. Too bad. After all, Setup Development Is Just Development.
Tags: best practices, custom actions, WiX
June 11th, 2007 at 17:35 #Dirk
I did my own spelunking and the package seems to contain a second executable (called by a custom action) that installs Apple Software Update. Does that not qualify as a chainer?
Also, keep in mind that this is a beta release. VBScript is great for quick development and perhaps they will move away from it if/when a final version is delivered.
June 11th, 2007 at 18:13 #Bob Arnson
The ability to install another package from a custom action is deprecated. (See http://msdn2.microsoft.com/en-us/library/aa368010.aspx.) Apple worked around that in its CA by sequencing it in the UI sequence only so basic/silent UI modes will never install it. A chainer is a separate executable that avoids those problems.
VBScript is great for prototyping CAs but should never go outside the walls. VBScript is too fragile, something Apple knows about. (See http://docs.info.apple.com/article.html?artnum=304405.) Given that other Apple products on Windows RTM’d with VBScript, I’m not confident it’ll go away, except by pointing out the problem.
Apple is all about the user experience and setup is the user’s first experience (especially on Windows) (and even on OSX ). Taking shortcuts for the sake of quicker delivery can kill the experience.
June 12th, 2007 at 13:54 #Dirk
The behavior is definitely deprecated (link didn’t work), but is there documentation (i.e. from MS) on how to ‘correctly’ implement a multiple MSI install and/or chainer?
June 12th, 2007 at 20:04 #Bob Arnson
Sorry — WordPress mildly munged the URL. It’s http://msdn2.microsoft.com/en-us/library/aa368010.aspx without the ending period.
The MSI SDK includes doc about chaining, starting at http://msdn2.microsoft.com/en-us/library/aa372828.aspx . Those topics deal specifically with bootstrapping MSI but the principles are the same with multiple MSI packages.
June 20th, 2007 at 21:21 #Christopher Painter
MSI doesn’t really have a proper fully featured bootstrapper. This has been historically left up to tools vendors but based on the changing attitudes towards merge modules and concurrent installs, I expect MSI will be addressing this story alot more in the next version of MSI ( 4.x maybe? ) very soon but that it’ll still be up to the tools vendors to implement the patterns.