My problem with requiring that .exe is somewhere in the chain is how you
would enforce that.  For example, what if your Bundle A has Bundle B as an
EXE package, and you want to run an .exe inside an MSI that's in Bundle B?


On Mon, May 12, 2014 at 10:10 PM, Bob Arnson <b...@joyofsetup.com> wrote:

>  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> 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://boBhttp://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
>
>
------------------------------------------------------------------------------
"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

Reply via email to