+1 for the ability to execute elevated code in BA. Albeit, I need to run the elevated code in the GUI phase, before the actual setup runs.
The IIS folks decided that one needs admin privileges just to read the IIS config. So when I want a list of installed websites on a local IIS, I'm currently using this approach in a managed BA: 1. Launch an invisible app which requires admin privileges 2. This app inspects the IIS configuration and gathers the required information 3. The app uses communicates the info back to the BA application. Launching the app from the BA causes an elevation prompt. And when the BA starts installing, another elevation prompt comes up. This is not a very good setup experience. Kind regards, Henning > -----Original Message----- > From: Bob Arnson [mailto:b...@joyofsetup.com] > Sent: Dienstag, 13. Mai 2014 05:11 > To: wix-devs@lists.sourceforge.net > Subject: Re: [WiX-devs] WIP3249 - Allow BA to Run Elevated Async Process > Through the Engine > > The use case is to run a config tool (that requires elevation) without leaving > the bundle running in the background. You can do that today with a simple > .exe that launches the config tool and exits. The goal of the feature request > is to make that easier. I'm concerned about putting the BA in charge of it, > because of the potential for abuse and the additional effort required. > > That said, I can see that (1) the feature might need more flexibility than you > can get from just bundle authoring and (2) I'm usually in favor of the > approach you're suggesting (adding engine primitives the BA can use). > > What if the focus is on an executable installed elsewhere in the chain? (i.e., > no separate payloads, only a component GUID/file id from an installed > package) > > > On 12-May-14 18:50, Sean Hall wrote: > > > My use case for this is that I am delivering a per-machine app in an > MSI. I want to allow the user to run this per-machine .exe (that gets > installed > wherever they put it) without getting an elevation prompt. My proposal is to > "register" this .exe with the engine at compile time (the > ApprovedExeForElevation element), so that the BA can tell the engine to run > it at runtime. Is this what you're calling an arbitrary process - something > that's not in the chain? If so, then we should just close this feature > request. > There's already ways to get the engine to run arbitrary exe's by putting them > in the chain and doing a separate detect/plan/apply cycle. > > > On Sun, May 11, 2014 at 11:20 PM, Bob Arnson > <b...@joyofsetup.com <mailto:b...@joyofsetup.com> > wrote: > > > On 03-May-14 14:59, Sean Hall wrote: > > > I wrote a WIP > <http://wixtoolset.org/development/wips/3249-allow-ba-to-run-elevated- > aync-process-through-engine/> to implement feature 3249 > <http://wixtoolset.org/issues/3249/> . Before I start coding it up, I'd like > to > get some feedback about it and whether it would be accepted into the > toolset. > > > I don't think the BA should be able to execute arbitrary > processes with elevation. Keeping the BA from being a dumping ground of > per-machine hacks is a Good Thing(tm). I like your #3 footnote -- maybe a > component GUID would do? But I think it needs to be in the chain. > > > > -- > sig://boB > http://joyofsetup.com/ ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
