ElevatedManagedAction issue

[barnabas90]

Hi,

Today, I ran into an issue, I used a specific ctor of ElevatedManagedAction and my custom action suddenly got permission issues. Turned out that impersonate=no is not generated with that ctor. I checked the source code, impersonate=false is missing from 2 ctors at line 309 and 326. Is this intended or a bug?

[barnabas90]

Workaround was to give id in prop init list instead of ctor.

[oleg-shilo]

The constructors are used to init the most commonly used properties. For everything else use initializers. Exactly as you did.

[barnabas90]

Let me approach this from a different perspective.

In wixsharp, we have the ElevatedManagedAction class, which is a specialized version of the ManagedAction class. This ElevatedManagedAction class just presets some properties to their proper values (Impersonate=false, Execute=Execute.deferred), in order to generate a custom action that runs elevated.
With this specialized class, the programmer doesn't have to use the ManagedAction class and set these properties manually all the time when they need to define a custom action that runs elevated, just like as its documentation says:

Defines WiX Managed CustomAction, which is to be run with elevated privileges (UAC).
Any CustomAction, which needs elevation must be run with "Action.Impersonate" set to "false" and "Action.Execute" set to "Execute.deferred". Thus "ElevatedManagedAction" is a full equivalent of "ManagedAction" with appropriately adjusted "Action.Execute" and "Action.Impersonate" during the instantiation.

Here's the problem:
There're 29 overloads of the ctor, 2 of them lack the statement that sets Impersonate to false, for no apparent reason. Therefore the impersonate=no attribute is not set for the custom action in the generated wxs when those ctors are used. This results in a custom action that doesn't run elevated.

That 2 ctors are traps, the programmer expects to get an elevated custom action - but it won't be, and it only gets clear what the problem is, when the programmer checks the generated wxs.

[oleg-shilo]

As a background info...
The original implementation of thess class constructors (and in fact of any WiX entity class) was to cover the most commonly used properties. It is warranted that it will not cover all available properties (e.g. introduced in later WiX) and all the possible combinations of the properties.
In order to avoid "constructors madness" one needs to encourage the use of initializers. 29 constructors are already madness if you ask me.

Now, about your very question about these two constructors. It is an API bug caused by the typo. Fixed now. The fix will be available in the very next release.

And another note. The use of ElevatedManagedAction fits canonical WiX API scenarios. My personal strong preference would be to go with the ManagedProject class and go with the After Install event, which is already elevated for you:

var project = new ManagedProject(...
. . .
project.AfterInstall += (SetupEventArgs e) =>
{
    // do whatever action that requires elevation
};

Providing you want to do your action after install of course.

[barnabas90]

Thank you for the fix and the note!