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.
Related
I have a non-.NET-based project that I'm trying to hammer nuget into for managing the dependencies. Because of that, I have to use packages.config to define the dependencies for a project.
Right now, I've got it packing and pushing exactly as I want it, but when I restore the packages, it only restores the dependencies in the packages.config I list, none of the dependencies of that package. So, for instance, if I have an application, MyApp, with a dependency on Foo, which then has a dependency on Bar, calling nuget restore on MyApp will not put Bar into the packages folder.
According to the CLI documentation, the -Recursive flag does not work for projects using packages.config - which is a problem for me, as I need to use packages.config, as far as I can tell. Or at least, I don't really want to spend another 3 hours converting all 12 of my packages to use a different format if I can help it.
For reference, here's an example of what my files look like, currently:
MyApp's package.config
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="Foo" version="1.0.0.0" allowedVersions="[1.0]" />
</packages>
Foo.nuspec
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
<metadata>
<!-- Required elements-->
<id>Foo</id>
<version>1.0</version>
<description>Foo</description>
<authors>Tesset</authors>
<dependencies>
<dependency id="Bar" version="[1.0]" />
</dependencies>
</metadata>
<files>
<file src=".\lib\Foo\**" target="lib\Foo" />
</files>
</package>
Bar.nuspec
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
<metadata>
<!-- Required elements-->
<id>Bar</id>
<version>1.0</version>
<description>Bar</description>
<authors>Tesset</authors>
</metadata>
<files>
<file src=".\lib\Bar\**" target="lib\Bar" />
</files>
</package>
And, for completeness, I'm calling nuget restore like:
nuget restore ".\MyApp\packages.config" -PackageSaveMode nuspec -OutputDirectory ".\MyApp\packages" -recursive
(Having or not having the -recursive flag makes no difference to whether Bar ends up in the packages folder)
So, is there a way in nuget to make sure Bar gets restored while leaving MyApp (and Foo) using a packages.config file? If not, then is there a way to restore the dependencies listed in the nuspec file, so I can do that recursion manually on the files nuget restore puts into .\MyApp\packages?
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'm creating an installation package with WiX 3.6 primarily so I can take advantage of the Burn bootstrapping features. So far I have several MSI packages bundled together that will be installed with the built-in bootstrapper application (WixStandardBootstrapperApplication.RtfLicense).
I have read that Burn allows the default bootstrapper application to be replaced by specifying a custom UX.dll, but I haven't yet been able to locate any resources that describes how the custom ux.dll is constructed (that is, how it integrates with the Burn engine, what technologies do I use, what interfaces should I implement, etc.).
My goal is to create a branded bootstrapper that can collect arbitrary information from a user and pass that information onto the various bundled MSI files, EXE files, etc.
So I have two questions really:
To what degree is the default bootstrapper application customizable?
Are there any resources available that describe how to construct a custom UX.dll?
The key thing to know is that there is a BootstrapperCore.dll in the WiX binaries that defines a BootstrapperApplication class that handles the integration with the Burn engine. I needed to create my own derived class and override the 'Run' method to launch my custom UI.
It was also helpful to use the WixBA project that defines the UI for the WiX bootstrapper as a reference for using the BootstrapperApplication class (src\Setup\WixBA\WixBA.csproj).
The markup I used to reference my custom bootstrapper DLL file is:
<BootstrapperApplicationRef Id="ManagedBootstrapperApplicationHost" >
<Payload SourceFile="$(var.InstallSourceResources)Bootstrapper\FusionInstallUX.dll"/>
<Payload Id="FusionInstallUX.config"
SourceFile="$(var.InstallSourceResources)Bootstrapper\FusionInstallUX.BootstrapperCore.config"
Name="BootstrapperCore.config" Compressed="yes"/>
</BootstrapperApplicationRef>
The configuration file consists of:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<sectionGroup
name="wix.bootstrapper"
type="Microsoft.Tools.WindowsInstallerXml.Bootstrapper.BootstrapperSectionGroup, BootstrapperCore">
<section
name="host"
type="Microsoft.Tools.WindowsInstallerXml.Bootstrapper.HostSection, BootstrapperCore" />
</sectionGroup>
</configSections>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" />
</startup>
<wix.bootstrapper>
<host assemblyName="FusionInstallUX">
<supportedFramework version="v4\Full" />
<supportedFramework version="v4\Client" />
</host>
</wix.bootstrapper>
</configuration>
I also followed other examples and appended
[assembly: BootstrapperApplication(typeof([name of class deriving from BootstrapperApplication]))]
to the AssemblyInfo.cs file.
And lastly, Stack Overflow question Specify the INSTALLLOCATION of packages in WiX inside the Burn managed bootstrapper describes how to set and use Burn variables to help drive the installation.
Armed with this information I am now prepared to wreak havoc on the world with my very own custom Bootstrapper application!
To supplement #Bill Campbell's answer, I've written a series of blog posts on writing a custom WiX Bootstrapper in .NET which goes into more depth about the pieces involved, at least for a managed code solution.
Not precisely answer to this question, but if you want to customize appearance of ManagedBootstrapperApplicationHost, then this is what you need to do.
To keep short, you need to declare your variables like this (I put it before BootstrapperApplicationRef)
<WixVariable Id="PreqbaThemeXml" Value="tt.thm" />
<WixVariable Id="PreqbaThemeWxl" Value="tt.wxl" />
assuming tt.thm is your theme file, and tt.wxl is your translation file.
Note those files, as well as all files they reference must be included to BootstrapperApplicationRef as Payoload, like
<Payload SourceFile="tt.wxl"/>
<Payload SourceFile="tt.wxl"/>
<Payload SourceFile="cat.png"/>
As an example of layout you can use mbapreq.thm, found under WiX sources.
In addition to the other resources listed here, a good bare-bones example of a custom bootstrapper application for Burn is Custom WiX Managed Bootstrapper Application.
I found that this is a good place to start with before digging deeper into other more thorough examples like the WixBA project in the WiX sources.
One detail I was missing when setting this up was that I had to include a reference to WixBalExtension.dll. That's because the ManagedBootstrapperApplicationHost is defined in that DLL and used in the bundle like this:
<BootstrapperApplicationRef Id="ManagedBootstrapperApplicationHost">
<Payload Name="BootstrapperCore.config"
SourceFile="MyBA.BootstrapperCore.config" />
<Payload SourceFile="MyBA.dll"/>
</BootstrapperApplicationRef>
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.
i have an application that has a dependancy on gdiplus. i need the application to also run on Windows 2000.
i want to include GDIPlus in the application directory, so that Windows 2000 computers will function, but if the machine is Windows XP, Windows Vista, Windows 7, etc, i want it to use the version of GDIPlus that ships, and is updated, with Windows.
Not possible?
From http://msdn.microsoft.com/en-us/library/ms997620.aspx Try adding the following to your manifest :-
<?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="Microsoft.Windows.mysampleapp" type="win32" />
<description>Your app description here</description>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.Windows.GdiPlus"
version="1.0.0.0" processorArchitecture="x86"
publicKeyToken="6595b64144ccf1df" language="*" />
</dependentAssembly>
</dependency>
</assembly>
Won't it be easier to do it from the installer ? IF you are installing on Windows 2000 copy Gdiplus to application directory otherwise skip it.
From the GDI+ page:
Run-time Requirements
Gdiplus.dll is included with Windows
XP. For information about which
operating systems are required to use
a particular class or method, see the
More Information section of the
documentation for the class or method.
GDI+ is available as a redistributable
for Windows NT 4.0 SP6, Windows 2000,
Windows 98, and Windows Me. To
download the latest redistributable,
see
http://www.microsoft.com/msdownload/platformsdk/sdkupdate/psdkredist.htm.
First hit on Google for "win2000 gdiplus".