Command Line Build NOT Building with Elevated UAC (requireAdministrator)

[yol1ana]

ETAS uses InstallAware Studio Admin X13 to create custom packages of our software for special use cases for our customers. Our EXE''s need to be built with elevated UAC permissions (requireAdministrator) in order to work correctly on customer machines. We use miabuild.exe via command line to automatically create these builds and out of nowhere the elevated permission stopped working when calling miabuild.exe via command line but DOES work when built directly in the InstallAware IDE..

Has anyone else experienced this before? Calling miabuild.exe via command line with our project parameters worked for this up until yesterday is when I noticed the builds weren't being made with elevated UAC. As I said, I can click "Build" in the IDE with all project parameters remaining the same and it works as expected.

Any help on resolving this would be greatly appreciated!

[FrancescoT]

I suppose that by mistake, you are not invoking the same identical project file (*.mpr) when building from command line.

From Miabuild there is no way to override or to set the UAC settings for the generated package. The UAC settings are stored with the project file itself (*.mpr). Due of this, to produce from command line a setup package with different UAC settings, you forcebly need to invoke a specific project file where these have been already defined.

Hope this helps you.

[yol1ana]

Hi Francesco,

I did not see your reply to this until today and coincidentally I started experiencing these issues again over the past few days. I checked the output of the failing builds (not elevated UAC) compared to successful builds (requireAdmin) and the same project file (*.mpr) was called in both scenarios. The Project Settings for the *.mpr used is configured to "Always Elevate (requireAdministrator)".

Any other ideas?

[FrancescoT]

As I said, from command line build utility there is no way to specify the UAC setting of the generated package. It's always used the UAC level as defined with the project.

For this reason, the behavior you reported sounds very very strange.

[yol1ana]

I understand that there is not a way to specify the UAC settings of the generated package from the command line utility, that is why I confirmed that the project being used holds the "Always Elevate" configuration. I also agree that it is strange behavior which is why I was posing the question here...

While watching the output directory of a build triggered using the command line utility, the icon of the build had the shield denoting it requires an administrator to run it (as expected) while the compression was still taking place; however, as soon as the build was complete and the only file left in the output folder was the executable, the shield icon was no longer present (UAC not elevated) which results in an executable that cannot be installed on any of our test machines. I can then manually open our InstallAware project (the same project file that was called with the command line utility), change nothing, and trigger the build in compressed mode - the result is an elevated UAC executable.

So I guess an additional question for you as I need to root cause this so the builds created with our automated process can be installed on our test machines for testing:

Q: Is there something in the compression process that could block the build from elevating the UAC?

[JohnGaver]

This topic applies to InstallAware Multi Platform as well.

Interesting thread here.

The launch-time elevation setting of your setup is actually stored inside a compiler variable, aptly named #UAC#:

http://www.installaware.com/mh52/deskto ... iables.htm

While the variable doesn't seem to be documented there, you can inspect its three values (or two for InstallAware Multi Platform) by using the Project Options dialog's Project | Summary | UAC Elevation (or Project Options | Project | Elevation for InstallAware Multi Platform) combo box to select a desired elevation setting, and then inspecting the value of the #UAC# pre-defined compiler variable looking at Project | Compiler variables.

Then, just pass that value to mia(x)build(.exe) on the command line using the form:

Code: Select all

UAC=<value>

And see if this has the desired effect of changing your elevation setting, when building from the command line.

FWIW, it does sound like something on your device is interfering with the natural build flow; irrespective of the validity of the information I have provided above.