Question

I’ve made a Visual Studio Setup Project with Visual Studio 2008 (SP1) for an Office 2007 AddIn. The setup only copies files to a per-user location (LocalAppData) and only writes registry settings to HKEY_CURRENT_USER, but when run under Windows 7, the MSI asks for admin credentials just before it begins copying files. The installer works perfectly running under a limited user account on Windows XP, but under Windows 7, admin privileges seem to be required.

I have not been able to find a way to remove the admin elevation requirement and I want to know how to do this or if it is not possible to do this with a Visual Studio Setup Project.

UPDATE 2010-11-03 (more details)

When I build the Visual Studio Setup Project, it creates a setup.exe and an MSI file. Visual Studio 2008 does not seem to give me adequate control over how the setup.exe is created or how the MSI file is created. The setup.exe file seems to be only for installing any prerequisites that my Office 2007 AddIn may need. It is the MSI file, which can be run independently, that installs the actual Office 2007 AddIn. I want to learn how to mark the MSI file such that it does not ask for admin privileges, because my MSI file only copies files to a per-user location and only writes registry settings to HKEY_CURRENT_USER.

Answer 1

I believe I have found the answer on this page:

Link

---

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

1. Use a Type 51 Custom Action in the InstallUISequence to always unset the ALLUSERS (the per-user option)

2. 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.

3. Install app to a location under LocalAppDataFolder.

4. All registry settings should be written to HKCU which is 1 in the Registry Table’s Root column.

5. Flip bit 3 of the word count property in the summary information stream to signal no credential prompt is required.

6. If you have a bootstrapper (typically named setup.exe), manifest the requestedExecutionLevel to run asInvoker.

7. Pass ICE Validation as the ICEs have checks for incorrectly mixing per-user and per-machine state.

8. Test both from a Standard User account and from an elevated command prompt to confirm behavior.

9. 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.