Hi Rob, Please correct me if I'm wrong. Elevation is done by the "chained" installers itself and not Burn ? If so, and I run several MSI + Exe packages thereafter each wants elevation. Then I'd highly vote at least for an ability to embed an admin manifest without need of mt.exe.
I mean I fully understand the concept of elevating just when needed but from my point of view I need such a Bootstrapper elevation to run all subsequent installers without additional UAC dialogs if needed. Regards Tobias 2011/7/21 Rob Mensching <r...@robmensching.com>: > 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 > ------------------------------------------------------------------------------ 10 Tips for Better Web Security Learn 10 ways to better secure your business today. Topics covered include: Web security, SSL, hacker attacks & Denial of Service (DoS), private keys, security Microsoft Exchange, secure Instant Messaging, and much more. http://www.accelacomm.com/jaw/sfnl/114/51426210/ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
