My installer deploys a configuration exe which is used to do some basic configuration on a windows service which is also installed. The exe also needs to create and write some registry keys. On a Windows server 2008 environment these keys can't be created. I have investigated and found that this is an Administrator privilege, and the exe isn't prompting for Admin permissions which are needed under UAC on 2008. I can work around this by right clicking the exe and running as Administrator. This isn't ideal however as its an extra step I need to notify our clients of performing. Are there any other ways of elevating the admin permissions when running the exe?
Put a manifest on or with the exe. I can tell you how to embed the manifest using Visual Studio if you let me know what version of that you're using. If you're not using Visual Studio, or you don't build the exe, then you can just put the manifest file in the same folder as the exe and that will work too. In that case the file must be named the same as your exe, with .manifest on the end, eg for foo.exe it's foo.exe.manifest. The content should look like this:
<?xml version="1.0" encoding="utf-8"?>
<asmv1:assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv1="urn:schemas-microsoft-com:asm.v1" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<assemblyIdentity version="1.0.0.0" name="MyApplication.app"/>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
<!-- UAC Manifest Options
If you want to change the Windows User Account Control level replace the
requestedExecutionLevel node with one of the following.
<requestedExecutionLevel level="asInvoker" uiAccess="false" />
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
<requestedExecutionLevel level="highestAvailable" uiAccess="false" />
If you want to utilize File and Registry Virtualization for backward
compatibility then delete the requestedExecutionLevel node.
-->
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
</requestedPrivileges>
</security>
</trustInfo>
</asmv1:assembly>
Notice the possible values for requestedExecutionLevel are all here in a comment, and this one uses requireAdministrator. Now it will always elevate and therefore work for you.
Related
I have a solution consisting of multiple projects, several of which reference NuGet packages. There's a web site but also a service which has to be built for x86 or x64; the service is what I'm currently trying to build.
We're on TFS 2013; for this particular solution, I'm using Visual Studio 2015.
"Allow NuGet to download missing packages" and "Automatically check for missing packages during Visual Studio build" are both checked.
I was running NuGet 3.4.4, I've updated to 4.6.2.
I can build fine from Visual Studio. But automated builds on the server fail; but more importantly, it also fails if I try to run MSBuild locally. Similar to this question and this one.
As far as I can tell, the release template is the correct version (12), but I don't think it's a server issue, since I can't build locally either.
The packages are not in source control.
I have a nuget.config in the solution root folder; it previously was in a .nuget folder under the solution root. I do not (and never did) have nuget.exe or nuget.targets in the nuget folder. Here's the config:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<clear />
<add key="NuGetCache" value="\\BuildServer\NuGetPackages" />
<add key="NuGetV2" value="https://www.nuget.org/api/v2/" />
</packageSources>
<packageRestore>
<add key="enabled" value="True" />
<add key="automatic" value="True" />
</packageRestore>
<solution>
<add key="disableSourceControlIntegration" value="true"/>
</solution>
</configuration>
If I (manually) clear the packages and run
MSBuild /p:Configuration=Release;Platform=x64
(from a VS2015 command prompt), it fails, because it can't find the referenced packages.
As suggested in this answer, I've removed the EnsureNuGetPackageBuildImports targets from my projects; they did not have a RestorePackages tag or an import for nuget.targets.
I tried adding a pre-build event to do the package restore (yes, I realize this is the "old" way of doing things)
"C:\Program Files (x86)\NuGet\nuget.exe" restore -ConfigFile "$(SolutionDir)nuget.config" -PackagesDirectory "$(SolutionDir)packages"
... but it consistently fails ("The command exited with code 1"). If I copy the NuGet command line from the MSBuild output and execute it on its own, it succeeds.
I have noticed one odd thing: in the pre-build event, NuGet says "The folder d:\path\to\solution\project1\bin\Release-x64 does not contain an msbuild solution or packages.config file to restore". I'm not sure why it's looking for those in the output folder.
I do have a workaround for this. We have a network share set up to use as sort of a package cache. If I hand-edit the project files and change each reference so that the HintPath points to \\BuildServer\NuGetPackages\ rather than ..\packages\, the build will succeed. But this is ugly, and more importantly it significantly degrades the performance of Visual Studio.
I make an Outlook add-in with the VSTO. But When i build, the value in the generated manifest are not the desired ones.
The generation done :
<requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
<requestedExecutionLevel level="asInvoker" uiAccess="false" />
</requestedPrivileges>
And i want :
<requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
<requestedExecutionLevel level="asInvoker" uiAccess="true" />
</requestedPrivileges>
How can i changed the this value?
Thanks
Execution manifests are only applicable to the exe files; COM addins are dlls loaded in the outlook.exe process space. Your code will run with whatever privileges the parent process (Outlook) is running.
I am migrating a working outlook add-in to run on outlook 2013 and getting the error ""Configuration system failed to initialize".
The app.config file is fine as the add-in loads and works when I am trying to run it from the visual studio 2010. However, when I create the deployment msi (created using WiX and ms bootstrapper) and installed it on the development machine it did not work.
On inspection I found that no user.profile is created in the c:\users\\AppData\Local... folder. So I have a hunch that something is stopping the add-in from creating this file. However, I am also writing a log file from the add-in and that seems to be creating fine.
My dll.manifest file has:
<trustInfo>
<security>
<applicationRequestMinimum>
<PermissionSet Unrestricted="true" ID="Custom" SameSite="site" />
<defaultAssemblyRequest permissionSetReference="Custom" />
</applicationRequestMinimum>
<requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
<requestedExecutionLevel level="asInvoker" uiAccess="false" />
</requestedPrivileges>
</security>
</trustInfo>
Am I missing something?
Any clues? Thanks for your time.
We currently have an MSI that is created with WiX 3.5. The application is in .NET 3.5. We generate a bootstrapper using the boostrapper task in an MSBuild file. It's pointing at the 6.0a SDK files.
When users have UAC on and they install, they have to right-click the setup.exe and select run-as administrator.
What I would really like is to have the setup.exe automatically prompt to elevate (using that yellow dialog I see in other installs).
Better yet, I'd like the MSI to do this and do away with the setup.exe completely, but I think that is what WiX 3.6 is about, right?
If I create the boostrapper using ApplicationRequiresElevation="true" this requries the 7.0a SDK, correct? Will the bootstrapper then prompt to elevate automatically? Does this mean the application has to be a .NET 4 application? I wouldn't think so...
We've used WiX 3.0 and were able to elevate privileges. However, we didn't elevate our bootstrapper. We elevated the MSI file itself, through the Package property:
<Package Id="$(var.PackageCode)"
Description="$(var.ProductName) $(var.Version)"
InstallerVersion="301"
Compressed="yes"
InstallPrivileges="elevated" <!-- Elevated right here -->
InstallScope="perMachine"
Platform="x86"/>
As a side note, our bootstrapper is signed (using signtool.exe from the v6.0A SDK) with our official certificate. I'm not sure if this causes the bootstrapper to also require elevated privileges.
UPDATE:
We've got an app.manifest file on our setup.exe bootstrapper project that requires the executable to be run at the administrator level. See the sample below:
<?xml version="1.0" encoding="utf-8"?>
<asmv1:assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1"
xmlns:asmv1="urn:schemas-microsoft-com:asm.v1"
xmlns:asmv2="urn:schemas-microsoft-com:asm.v2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<assemblyIdentity version="1.0.0.0" name="MyApplication.app"/>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
<!-- UAC Manifest Options
If you want to change the Windows User Account Control level replace
the requestedExecutionLevel node with one of the following.
<requestedExecutionLevel level="asInvoker" uiAccess="false" />
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
<requestedExecutionLevel level="highestAvailable" uiAccess="false" />
If you want to utilize File and Registry Virtualization for backward
compatibility then delete the requestedExecutionLevel node.
-->
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
</requestedPrivileges>
</security>
</trustInfo>
</asmv1:assembly>
I know this is a old topic, but may it save some time to next one.
I had to read all comment, especially custom action had Impersonate=yes...
On the other hand Custom Actions have Execute attribute related to privileges:
<CustomAction Id = "CA.First" Execute ="immediate" ... />
<CustomAction Id = "CA.Second" Execute ="deferred" ... />
CA.First will be always executed in user mode, but CA.Second can have elevated privileges.
May be here are other tricks related to privileges,
main point here - WiX allow control privileges on CustomAction level so make sure you set it right.
CustomAction Element
I've created an executable that's called by another app for processes that require UAC elevated privileges. If I build this project with the below manifest it requests UAC fine, if I add this projects output to my setup project it creates it without UAC?
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity version="1.0.0.0" processorArchitecture="X86" name="CreateApp" type="win32"/>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="requireAdministrator"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
Any idea why this is or if it's possible to have it as part of the setup project with the manifest?
Custom actions in InstallExecuteSequence already run as child processes of Windows Installer service. So they inherit their privileges and the manifest is not used.
To run a custom action with full privileges you should schedule it as deferred with no impersonation.
If you are not using the EXE as a custom action and you are just launching it from another process, make sure you use ShellExecute.