On Mon, Apr 25, 2011 at 1:56 AM, Bob Arnson <[email protected]> wrote: > Deferred custom actions can only get a couple of system properties. To > get any other properties (public or not), you need an immediate CA that > writes CustomActionData for the deferred CA.
Funnily enough, this played straight into what I am seeing with my second custom action. I need to enumerate IIS websites. To do this, I need admin privs. A little googling seems to suggest that the proper way to do this would be by using a deferred action. If I understand this correctly, the deferred action will be executed by the installer service and has a good chance of running elevated. Fine, except I need the list of web sites in the UI, so that suggests I need an immediate action... Further googling then revealed several claims that my whole .msi must run elevated, to whit the solution is a bootstrapper..? Please tell me I missed something. :) I would want to avoid a bootstrapper for as long as possible. Incidentally, I put in a <Condition Message="You need to be an administrator to install this product.">Privileged</Condition> but... the log file shows: MSI (c) (80:D8) [09:04:06:564]: PROPERTY CHANGE: Adding AdminUser property. Its value is '1'. MSI (c) (80:D8) [09:04:06:564]: PROPERTY CHANGE: Adding Privileged property. Its value is '1'. Yet I am not really elevated of course. If I run from an elevated command line, then all is fine. -- Rune ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd _______________________________________________ WiX-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wix-users
