How to make the setup.exe from a VS2010 Setup Project ask for Admin Privileges

installationsetup-deploymentuacvisual studio 2010windows-installer

I have a problem which I guessed would be really simple to solve… but duh.

I'm deploying a .NET application with VS2010. I have a C# Windows Forms project and a Deployment Project. I need the installer to run with admin privileges because the app is installed for all users and an entry to the registry is made.

When starting the setup.exe I'm not prompted for privilege elevation. The installer will just start and suggest to install to Program Files (x86) which is good. After clicking next the installer runs and finished with a success message. Which is basically a lie because it did not successfully install. Instead it puts the apps exe directly to C:\.

How can I make the installer ask for admin privileges. Or do I have to rely on my customer to right click the setup and select "Run as Admin" which is very error prone?

Clarifications about my setup:

In the File System view of the setup project I added (among other things) "Primary Output from project01 (Active)" and "Build Outputs from project01 (Active) to "Application Folder". I also added a shortcut to "Primary Output" into "User's Programs Menu\CompanyName\ProgramName".
In the Registry View I added an entry to HKEY_CLASSES_ROOT because I need to register an url handler.

I also modified the setup's settings: I set InstallAllUsers to True because it is supposed to do so.

When I build and start the setup.exe by double clicking (or by selecting Install from the project's context menu) I always get the same result: The installer runs without asking for admin privileges, ask for an install location (which I leave at the default C:\Program Files(x86)\Company\ProgramName) and then procedes after clicking Next. As a result, the exe is put directly in C:\ and the shortcut created of course points into Nirvana.

If I run the setup.exe manually as Administrator things work fine. But this cannot seriously be the way to go.

So how can I tell the setup to always run as Admin?

Best Answer

I think this is a perfectly valid question, is a real problem, and has an actual explanation.

I recently ran across this problem. In my case, the cause is that the AlwaysInstallElevated policy was set on the computer through GPO. The policy was set to 1 in the per-machine policy and 0 in the per-user policy. These policies can be manually set to reproduce the effect it has on MSI installers

Using msexec /log install.log /i Deploy.msi, I had a setup log and there were strings in it like this:

MSI (s) (A4:8C) [13:00:42:885]: Ignoring disallowed property TARGETDIR
MSI (s) (A4:8C) [13:00:42:885]: Ignoring disallowed property VSDNETURLMSG
MSI (s) (A4:8C) [13:00:42:885]: Ignoring disallowed property VSDNETMSG

It seems that Visual Studio does not set the SecureCustomProperties in the MSI correctly and post processing of some sort is needed. I think that moving to WiX may be a better long term solution instead.

A blog post on MSDN is what I found that helped me find the root cause to this problem.

Related Solutions

How to make a setup work for limited (non-admin) users

I believe I have found the answer on this page:

http://blogs.msdn.com/b/rflaming/archive/2006/09/30/778690.aspx

How do I build a Standard User package?

This takes a bit of work to make a package install only to the locations a Standard User has permission. Some of the requirements are

Use a Type 51 Custom Action in the InstallUISequence to always unset the ALLUSERS (the per-user option)
Files must be written only to folders that Standard User has access to. Assuming the ALLUSERS is always set to the per-user setting, you can use the redirectable folder properties but not ProgramFilesFolder as it does not redirect on per-user.
Install app to a location under LocalAppDataFolder.
All registry settings should be written to HKCU which is 1 in the Registry Table’s Root column.
Flip bit 3 of the word count property in the summary information stream to signal no credential prompt is required.
If you have a bootstrapper (typically named setup.exe), manifest the requestedExecutionLevel to run asInvoker.
Pass ICE Validation as the ICEs have checks for incorrectly mixing per-user and per-machine state.
Test both from a Standard User account and from an elevated command prompt to confirm behavior.
Provide your users’ documentation of the user specific nature of the package as this is atypical in today’s application installs.

NOTE: Step 5 can be done using Orca, Microsoft's MSI editing tool. Open the MSI file in Orca, select View-->Summary Information... then check the "UAC Compliant" checkbox.

NOTE #2: Step 5 can be done using the WiSumInf.vbs sample script file included in the Microsoft SDK: C:\Program Files\Microsoft SDKs\Windows\v7.0\Samples\sysmgmt\msi\scripts\WiSumInf.vbs

NOTE #3: Step 1 seems to be taken care of in a Visual Studio Step Project by right-clicking on the setup project, choosing View-->User Interface, getting properties for the "Install/Start/Installation Folder" page and setting "InstallAllUsersVisible" to False.

NOTE #4: Yet another way to do Step 5, use the MsiInfo.exe tool included in the "Windows SDK Components for Windows Installer Developers" http://msdn.microsoft.com/en-us/library/aa370310(VS.85).aspx

Addition to the NOTE #4: Assuming that you are using long file names and compressed media (default behavior for an MSI) the PostBuildEvent command would be something like:

"C:\Program Files (x86)\Windows Kits\8.1\bin\x86\MsiInfo.exe" "$(BuiltOuputPath)" /w 10

Note that you will have to change the path to the MsiInfo to match the one that it has in your system.

VS2010 Setup Project – Run As Administrator

As pointed out by Frank, the Visual Studio setup project's behavior is documented at Microsoft's web site:

Visual Studio Installer Deployment

In other words, the setup.exe produced by VS008 and VS2010 will always be run without prompting for privilege elevation (unless you explicitly run it using the 'Run As Administrator' context menu option). It in turns will run each prerequisite component as well as the main MSI installer as separate processes and prompts for privilege elevation for any of them that needs it. This means that there may be multiple prompts for elevations.

However, for some reasons this does not always work. In my case, the elevation prompt for the .NET Framework prerequisite does not come up at all when I run setup.exe. But if I run the prerequisite installer directly, the prompt will come up. This means that the problem lies not with the prerequisite component, but with either setup.exe or with Windows itself.

The solution (or workaround)? According to Microsoft in the link above, we can force setup.exe to launch each prerequisite component and the main MSI to run with elevation prompts. To do this, we need to manually edit the setup project file (.vdproj) and change the following RequiresElevation value to TRUE, as shown below:

"MsiBootstrapper"
{
    "LangId" = "3:1033"
    "RequiresElevation" = "11:TRUE"
}

This is not the ideal solution, but it is close enough to my original requirement, so I'm satisfied with this solution.

Best Answer

Related Solutions

How to make a setup work for limited (non-admin) users

VS2010 Setup Project – Run As Administrator

Related Topic