> The goal is very much that a Bootstrapper Application is never elevated.
Rob, I would very much like for you to rethink that goal. Granted BAs should not write to the system, but there are some compelling reasons for allowing the BA to run elevated. 1) - Allows a user without elevation privileges to bother someone with them one time and one time only at the very beginning of the process 2) - IIS as you said is a mess. I have a Custom Action in my MSI that needs to read IIS configuration to present info to the user. Therefore my .MSI must run elevated during the UI phase. Since the user will never get it right to run the .MSI elevated, the answer became imbed the .MSI in a BA that forced the elevation via a manifest. Do not ship the .MSI separately because again the user will try to run it instead of the .exe 3) - I am sure that more than just IIS is going to be causing problems with .MSIs and/or BAs needing to run elevated. Please consider this as you respond to the feature suggestion about elevating the BA. I believe that a simple switch to create the BA with an elevated vs. as invoker manifest is a reasonable answer. Currently we can do this by a custom build event step to add our own manifest to the BA after it is built, but that just become more complicated and is subject to failure if you add/change things in Burn's manifest. ---------------------------------------------------------------------- Roy Chastain ------------------------------------------------------------------------------ 5 Ways to Improve & Secure Unified Communications Unified Communications promises greater efficiencies for business. UC can improve internal communications as well as offer faster, more efficient ways to interact with customers and streamline customer service. Learn more! http://www.accelacomm.com/jaw/sfnl/114/51426253/ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
