I think I feel the same way about internal UI as you do. For the most part, it was 'good enough'. And I liked that it was declarative. There were some annoying things such as the way control validation behaved and not having any concept of 'custom controls', how overlapping behaved and some issues with unicode multilingual type stuff but generally I really did like it.
I sometimes wish MSFT would just fix a few things and make a few improvements. Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves attention? E-Mail Me --- On Wed, 1/12/11, Vitalii Dolia <vdo...@hotmail.com> wrote: > From: Vitalii Dolia <vdo...@hotmail.com> > Subject: Re: [WiX-users] Burn issue > To: wix-users@lists.sourceforge.net > Date: Wednesday, January 12, 2011, 5:59 PM > > > From: r...@robmensching.com > > Date: Tue, 11 Jan 2011 23:13:34 -0800 > [...] > > In your first example, I don't understand, why you > have to create a UI in > > your MSI. Burn will show UI for all scenarios > (install, repair, uninstall, > > upgrade patch) so you do not need a UI in your MSIs. > > I agree that it may > > appear easier to just reuse UI in your MSI until you > factor in caching and > > some progress while running pre-requisite installs. > > The main reason is to reuse UI which was already > implemented and tested, of course. The second reason is that > sometimes the standard UI provided by Windows Installer was > "good enough" to get the job done. Sometimes I don't need > any fancy UI features, nor I want to drag WPF dependencies, > nor I want to get back to MFC or plain Win32 API writing UI > for my installer. <UI /> element did the trick for me > in a declarative way. I don't expect the standard > bootstrapper dll from WiX will be that customizable in a > near future and it will still keep depending on WPF even > after. > > Please, don't get me wrong, I'm still huge fan of WiX and I > do understand the original idea behind the Burn. Of course, > I'll roll up my sleeves and give it a try writing > burn-driven bootstrapper, but for now it's sometimes good to > have an option to use a "dumb" chainer. > > > I don't follow your second scenario. Or, rather, I > don't see how it is > > different from the previous scenario. Can you provide > more details? > > It's more like a selector, not a chainer. Installing only > one msi from a set according to a running environment (OS > version, platform etc.), so user will not see a bunch of > popping-up windows installers, but only one. Yes, maybe it's > still a variation of the first scenario. > > > > > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. > Understand > malware threats, the impact they can have on your business, > and how you > can protect your company and customers by using code > signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
