Menu
▾
▴
Re: [WiX-users] Need a custom action with UAC elevated privileges before InstallInitialize
|
From: Wilson, P. <Phi...@wo...> - 2008-02-26 23:39:29
|
Some of this is probably about ownership. The COM+, IIS, Visual Studio teams own the deployment/configuration for COM+, IIS, C++ redist and so on. It's these teams that need poking to provide infrastructure that integrates with MSI. Similarly, when the MMC team provides managed code classes to install MMC plugins it's the MMC team that needs to be told to provide a MSI-friendly way to install snap-ins, not the MSI team. I'm not boggled that they provided the single transaction install. Unlike other areas, this is one that they do really own and can do something about. Also, it is true that more and more enterprises (including Microsoft) are unhappy with the idea of providing one monolithic MSI (that's the one MSI=one product assumption), and sometimes this is due to organizational boundaries where each group owns their own MSI and they want to keep it that way for testing and maintenance, but marketing wants the result to look like a single product in some way. So making a series of MSIs into one transaction seems worthy to me. What's missing is an actual chainer that provides one UI (instead of one per MSI) and the infrastructure to deal with FilesInUse during the subsequent silent installs, reboots etc. Phil Wilson From: Brian Rogers [mailto:rog...@gm...] Sent: Wednesday, February 20, 2008 9:51 AM To: Bob Arnson Cc: Wilson, Phil; wix...@li... Subject: Re: [WiX-users] Need a custom action with UAC elevated privileges before InstallInitialize I have seen these types of tools used in the past. Mainly for database migrations and other more challenging configurations. I would agree that it would be best to have tool that ran after the installer or invoked at stages during the installation as the user. At that point the Windows Installer server really just becomes a bootstrapper for tools that work better. It acts like nothing more then a sequencing and file copy device which is how some people are using it now. I understand that Windows Installer offers some features that would be hard to do on your own (upgrades, rollbacks, etc.). Where I am at a loss is, over the years, these are some of the skimpy configuration options MSI offers: 1. Registry 2. INI 3. Services (weakly) 4. COM+ (very, very weakly) I really think the push should be back on the Windows Installer team. Technology has changed, they need to change with it. Advanced installations will just continue to get more complex. Why I went with WIX over other companies such as InstallShield was for these reasons. 1. Better COM+ 2. Better XML config 3. Better IIS config 4. Cheap (nothing is free as we need to support it if unable to get a fix soon enough) But there still needs to be work on most of these features (no offense meant AT ALL, what is there is great!). What about truly returning a machine to clean on an uninstall. Why can't we write to a reserved location of the installed MSI database to keep our configuration changes on the machine instead of going nuts on the registry? Why, after all these years, do they still not support COM+, XML, IIS or invoking COM (MS has or makes the technology for all of these). Why can't we have better UI? Why isn't there an easy way to do data manipulation for text (string values)? How about some Regex? How about multiple codepages per package? Don't get me wrong, GUIDs are great for component association, but isn't there something else that could be used so managing patches and automation was a bit more simple? How about just allowing for a hash value or string of n length so that, we the developers, can control how the key will be updated when we need to change it? If you are going to break component rules, you will more then likely do it with or without GUIDs. I see their use for product, package, upgrade, etc codes... Overall, it just boggles my mind that they give us "chaining" in 4.5 and we are supposed to jump up and down! There are still huge time problems with large installations. You need to change the database schema in order to support more than, what, 32K files? 2GB+ installs can take hours when all you are doing is coping down files. The Vista UAC prompt should happen when the MSI starts for MSI's that have defined they will need it. This comes into play when the installation takes a long time and the users leaves the machine for a while. Some users don't know to wait for UAC prompt and it will timeout and kill the install. Leaving things in a bad state. An MSI is basically a database, why not use it like one instead of writing stuff into the registry? Please don't mistake the fact that I like using Windows Installer as a tool, I just think it needs to become more robust at this point. Installation is challenging, no doubt about it. But it seems like using MSI can make mountains out of ant hills at times. With all the additional tools and custom actions that have been written to fit into Windows Installer, more then likely the community could have just rewritten the engine from ground up by now. I have seen installers written using NAnt, batch, VBScript and more that can be more effective but I have stuck with MSI. That's my 2 cents... -- Brian Rogers "Intelligence removes complexity." - BR http://www.codeplex.com/wixml/ On Tue, Feb 19, 2008 at 10:27 PM, Bob Arnson <bo...@jo...<mailto:bo...@jo...>> wrote: Wilson, Phil wrote: Hear Hear! Many (if not most) install issues come from complicating an install with configuration tasks. It's nearly always easier and cheaper to have configuration using programs that run in a normal user environment and can be debugged and tested without having to wait for a working setup. And it simplifies setup development, so you can have a working setup faster. (Day One, anyone?) -- sig://boB http://joyofsetup.com/ ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ WiX-users mailing list WiX...@li...<mailto:WiX...@li...> https://lists.sourceforge.net/lists/listinfo/wix-users |
