trouble with UAC and prerequisites

Jan 30, 2012 at 2:02 PM
Edited Jan 30, 2012 at 2:35 PM

Hi,

I've been banging my head most of today on this.

I have a msi generated with Wix, that needs to be elevated as it installs a dll in system32.

It also has prerequisites on .net 4.0 client & VS 2010 redist SP1. I'm testing deployment on a windows 7 x64, with a non-admin user.

If I tell dotNetInstaller that administrator is required in the install: , runtime section, then the prereq installs fine, but my msi ends up being installed for the administrator.

If I tell dotNetInstaller that administrator isn't required and I add a manifest to run the exe as the current user, then .net 4.0 or my msi pops up the UAC window to elevate, and they install properly. But the vcredist_x86 doesn't spawn the UAC, and it fails to install, with this in the log:

2012-01-30 16:34:25 *** Component 'Visual C++ 2010 SP1 Runtime Libraries (x86)' (Visual C++ 2010 SP1 Runtime Libraries (x86)): ERROR - 0x800702e4 - CreateProcessW: "C:\Users\zeflash\AppData\Local\Temp\VCRuntime_Download\vcredist_x86.exe" "/q:a": The requested operation requires elevation.2012-01-30 16:34:25 --- Component 'Visual C++ 2010 SP1 Runtime Libraries (x86) (Visual C++ 2010 SP1 Runtime Libraries (x86))' FAILED: 0x800702e4 - CreateProcessW: "C:\Users\zeflash\AppData\Local\Temp\VCRuntime_Download\vcredist_x86.exe" "/q:a": The requested operation requires elevation.2012-01-30 16:34:28 --- Component 'Visual C++ 2010 SP1 Runtime Libraries (x86) (Visual C++ 2010 SP1 Runtime Libraries (x86)): FAILED, ABORTING

 

How am I supposed to handle this properly? I've read most of the other threads related to this, but this specific issue looks more like a bug to me. Is there anything I can do? I've already spent more than 10 hours on this bootstrapper, I don't want to start over from scratch and try something else like burn.

Coordinator
Jan 30, 2012 at 3:28 PM

Why don't you elevate the VS pre-req with a tool? Google gives http://www.wintellect.com/cs/blogs/jrobbins/archive/2007/03/27/elevate-a-process-at-the-command-line-in-vista.aspx for example.

Jan 30, 2012 at 5:02 PM

Thanks for answering.

I've tried this solution, but it opens up a command prompt window entitled "elevate", and that's ugly, and unrelated to the actual file I'm trying to install, vcredist_x86. Ultimately yes that's the only workaround I can think of.

What I don't understand is why a msi is going to be installed without a problem (msiexec is going to prompt the UAC prompt) while vcredist isn't. If I'm launching vcredist on its own, it does open the UAC prompt. So why doesn't it do it from dotnetinstaller? 

Coordinator
Jan 30, 2012 at 6:29 PM

The MSI embeds a manifest that tells it to elevate. The vc redist executable doesn't. DNI doesn't do anything here. Naturally DNI could get an option to elevate the CMD. I'll gladly accept a patch :)

Jan 30, 2012 at 8:09 PM
Edited Jan 30, 2012 at 8:19 PM

Patch it myself ... didn't think about that. I guess I could take a look! Got to be able to actually build dotnetinstaller first though.

So I'm assuming I'd have to edit the editor, in order to add an option in the UI of the command & exe components, save this new option in the xml.

Then I'd have to be able to read this new option in dotnetinstaller, so that the command or the exe would be run elevated. 

Any pointers as to which files would need editing? 

Jan 30, 2012 at 8:22 PM
dblock wrote:

The MSI embeds a manifest that tells it to elevate. The vc redist executable doesn't. DNI doesn't do anything here. Naturally DNI could get an option to elevate the CMD. I'll gladly accept a patch :)

I'm still confused though; when I run the vc redist by itself, in a command prompt, as a regular user, it asks for elevation. Why isn't it the case when run by DNI? Something must be blocking this mechanism, right?

Coordinator
Jan 30, 2012 at 8:23 PM

That makes no sense at all :) DNI doesn't do anything special about the executable, so I don't see why it wouldn't prompt to elevate. But it could have some weird logic in it though.

Jan 30, 2012 at 9:05 PM

From what I'm beginning to understand, CreateProcess doesn't support privilege elevation by itself. If the return code is 740, then it needs to be run again with "other options" (I don't know how yet).

Using ShellExecute instead would fix this; It uses CreateProcess in the end, but it does check for the return code and handles elevation gracefully.

If I'm not mistaken this happens in shellUtils.cpp. Sadly I'm unable to build DNI, tons of errors.Might be because I don't have vc2005 and used vc2008 to open the whole solution, converting the projects first.

Coordinator
Jan 30, 2012 at 9:08 PM

There's a contributing and help doc on how to build DNI in the CHM. You should be able to build it with 2008 without too many issues. Start by running "build all" from command line.

Jan 30, 2012 at 9:33 PM

So if I use the "open file" component, it works (asks for elevation). But, it's not waiting for the end of the installation and triggers the next MSI right away.

<sigh>. I guess I'll have to actually edit DNI to do what I want.

Jan 31, 2012 at 1:39 PM

So I've switched CreateProcess and replaced it with ShellExecuteEx. It was pretty straightforward, replaced the LPPROCESS_INFORMATION with LPSHELLEXECUTEINFO in shellUtil.cpp & in all components, used the proper flags. given the hprocess is still present I didn't have to touch any of the waitforsingleobject logic.

I just had to hack the main HWND (needed by ShellExecuteEx to get proper window focus) using a global var. Works fine. Prompts UAC properly too. At last!

Tell me how I can send you the patch if you're interested. 

Coordinator
Jan 31, 2012 at 1:45 PM

In order for this to be committed to DNI you need to add a feature that lets users choose how to execute the command, along with tests and a documentation update. And of course you'll have to find a better solution for the HWND.

Jan 31, 2012 at 1:57 PM

You misunderstood the issue; The issue with CreateProcess is that it does *not* handle UAC properly; if you try to run an exe that has requiresAdministrator level in its manifest, CreateProcess will just fail.

Using ShellExecuteEx instead provides the exact same functionality, and it *does* handle UAC properly, triggering the UAC dialog box if necessary. I don't see why the editor would need to be changed in that case. It's just a case of API obsolescence, MS recommends using ShellExecuteEx instead of CreateProcess for vista & up.

I agree about the HWND but I don't have time to figure out the "proper" way to do this. 

Coordinator
Jan 31, 2012 at 2:10 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Coordinator
Jan 31, 2012 at 2:10 PM

I am almost down with replacing CreateProcess with ShellExecuteEx. It's unclear how many existing installers we're going to break by replacing CreateProcess with ShellExecute, so I'd be very careful about that. Either way making the actual change will take the extra work of doing it properly, making sure all UTs pass and stuff like that. If you're not up for it, I created http://dotnetinstaller.codeplex.com/workitem/10269, attach whatever you have to it and hope someone cares enough to do it all the way.

Mar 21, 2012 at 12:35 PM

Is it possible to get this ShellExcuteEx patch somehow ?  

Mar 21, 2012 at 6:01 PM
Hi, sorry for taking so long responding to you.
Here's a patch of my changes. Tell me if it's enough for you to go on.

-a-

On Wednesday 21 March 2012 at 13:35, uabhedq wrote:

From: uabhedq

Is it possible to get this ShellExcuteEx patch somehow ?

Read the full discussion online.

To add a post to this discussion, reply to this email (dotnetinstaller@discussions.codeplex.com)

To start a new discussion for this project, email dotnetinstaller@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com


Mar 22, 2012 at 7:34 AM
Hi!

I can't se that you have attacehd any files. 

zeflash wrote:
Hi, sorry for taking so long responding to you.
Here's a patch of my changes. Tell me if it's enough for you to go on.
-a-

On Wednesday 21 March 2012 at 13:35, uabhedq wrote:

From: uabhedq

Is it possible to get this ShellExcuteEx patch somehow ?

Read the full discussion online.

To add a post to this discussion, reply to this email (dotnetinstaller@discussions.codeplex.com)

To start a new discussion for this project, email dotnetinstaller@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com

 

Mar 22, 2012 at 7:39 AM
I did. Is it code pled that filters those out?
Anyway, if you provide a real email I'll forward the patch.

-a-

On jeudi 22 mars 2012 at 08:34, uabhedq wrote:

From: uabhedq

Hi!
I can't se that you have attacehd any files.
zeflash wrote:
Hi, sorry for taking so long responding to you.
Here's a patch of my changes. Tell me if it's enough for you to go on.
-a-

On Wednesday 21 March 2012 at 13:35, uabhedq wrote:

From: uabhedq

Is it possible to get this ShellExcuteEx patch somehow ?

Read the full discussion online.

To add a post to this discussion, reply to this email (dotnetinstaller@discussions.codeplex.com)

To start a new discussion for this project, email dotnetinstaller@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com


Mar 22, 2012 at 7:57 AM

Ok! Thanks!

My mail is uabhedq@hotmail.com 

//A

 

Coordinator
Mar 22, 2012 at 12:26 PM

Can you please attach any patches for this to http://dotnetinstaller.codeplex.com/workitem/10269. Would still like a proper contribution to DNI where I can choose which method of execution to use for a component.

Mar 22, 2012 at 12:33 PM
Just like I said in the work item, I don't see any point in letting the user choosing the method of execution. ShellExecute is replacing CreateProcess, which should be deprecated.
My patch is incomplete as it breaks compilation for unit tests & the htmlinstaller - I had no need for that. Right now I can't spend more time on this.


-a-

On Thursday 22 March 2012 at 13:26, dblock wrote:

From: dblock

Can you please attach any patches for this to http://dotnetinstaller.codeplex.com/workitem/10269. Would still like a proper contribution to DNI where I can choose which method of execution to use for a component.

Read the full discussion online.

To add a post to this discussion, reply to this email (dotnetinstaller@discussions.codeplex.com)

To start a new discussion for this project, email dotnetinstaller@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com