1. That is not the recommended way to deal with UAC from Windows. You're supposed to display UI and only elevate when the user does an action that requires it. This is how the Windows Installer behaves. You're also more likely to ensure that the elevation prompt appears on top of everything instead of stuck flashing in the task bar. Basically, much better user experience all the way around (funny, how following Windows guidelines helps <smile/>).
Legacy setup programs are auto-elevated because the assumption was that they were written before UAC and thus will fail outright without elevation. RegEdit and MMC are my favorite example of annoying applications that don't let me just do read-only operations (which I do a lot more) then elevate for write operations. Anyway, if you want the "elevate right away" behavior, your BA can call "IBootstrapperApplicationEngine->Elevate()" right away. If you have a splash screen then you'll still have a better chance showing up on without being stuck blinking in the task bar. 2. If you keep all of your machine configuration in your MSI (the goal), you won't have a problem. When per-machine MSIs are executed they are executed with elevated privileges.Your BA doesn't need to do anything. Where things are currently hoarked is when you need to populate UI with data from IIS7. 3. Not in my experience. IIS7 was the first thing ever. We had to completely redesign the IIS7 custom action to read their data files elevated and still handle rollback. It was painful. II6 you could correctly read the metabase unelevated and all was good. It does not seem like a good idea to throw away the best practices simply because one component (IIS7) did the wrong thing. IMHO, a better path would be to get the best expeirence globally and find a good way to tackle the IIS7 problem. On Thu, Jul 21, 2011 at 8:37 AM, Roy Chastain <r...@roychastain.org> wrote: > > 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 > > -- virtually, Rob Mensching - http://RobMensching.com LLC ------------------------------------------------------------------------------ 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
