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
Related
I am creating a Bundle installer, using WiX standard bootstrapper in order to install .NET Framework 4.5 (if not yet installed) and my application in the user's computer. The bundle installer also allows the user to set the installation path for the application, and uses WiX standard bootstrapper's UI only (no other installers' interfaces are shown to the user).
Right now I'm struggling to allow the user to launch my application at the end of the installation.
Closest related anwers I could find use a variable named LaunchTarget, which causes WiX standard bootstrapper to display a "Launch" button in the end of the installation.
Given solutions and why I wasn't able to use them follow:
Answer "A" suggests setting the LaunchTarget variable to the exact folder inside "Program Files" folder where the application should be installed. This doesn't work for me, because I want to allow the user to specify the target installation folder (application can be installed outside of the "Program Files" folder).
Answer "B" suggests setting the LaunchTarget variable by using the InstallFolder variable to determine where the user configured the standard bootstrapper to install the software to. This seemed perfect for my case, but after setting the LaunchTarget value simply to "[InstallFolder]" I verified that pressing the "Launch" button in the standard bootstrapper's UI actually opens the folder where the installer is running, and not the folder where the user chose to install the software, as I expected. (is that a bug?)
Question is: how can I correctly set the LaunchTarget variable to the right path, considering that the user can modify the installation folder through WiX standard bootstrapper's UI?
The code for the Bunde follows.
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:bal="http://schemas.microsoft.com/wix/BalExtension">
<Bundle Name="My Game Trainer" Manufacturer="MY_MANUFACTURER_ID_HERE" UpgradeCode="MY_GUID_HERE" Version="!(bind.packageVersion.TrainerMsiPackage)" DisableModify="yes">
<Variable Name="LaunchTarget" Value="[InstallFolder]" />
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLargeLicense">
<bal:WixStandardBootstrapperApplication ShowVersion="yes" LicenseFile="PATH_TO_MY_LICENSE.rtf" />
</BootstrapperApplicationRef>
<Chain>
<PackageGroupRef Id="NetFx45Web"/>
<MsiPackage Id="TrainerMsiPackage" SourceFile="$(var.SetupMSI.TargetPath)" DisplayInternalUI="no">
<MsiProperty Name="TRAINER_INSTALL_DIR" Value="[InstallFolder]"/>
</MsiPackage>
</Chain>
</Bundle>
</Wix>
Using WiX Toolset v3.11.1 (+Visual Studio 2017 Extension).
In my WiX installer, I do not want .NET installed automatically if it isn't installed. It should just give a warning or merely error out.
The reason to avoid it is explained here:
One HUGE word of
caution here: Because the .Net installer will technically be part of
your install chain, if the user installs .Net but then cancels your
install, your installer will still be listed in the Add/Remove
programs since one if it’s components (the .Net installer) completed.
Tread with caution.
He seems to be intentionally including it. But I'm not and I happened to set <supportedRuntime version="v4.5" /> which I guess isn't a real version (4.5 => 4.0 as far as this is concerned?). My WiX managed bootstrapper application exe automatically prompted me to download and install the "missing" .NET Framework.
For computers that ARE missing 4.0, I don't want this to happen. WiX also complains if I leave out:
<WixVariable Id="WixMbaPrereqLicenseUrl" Value="..." />
<WixVariable Id="WixMbaPrereqPackageId" Value="..." />
in which I literally leave in ... because I don't want it to work anyway.
In this thread, #Shruthi asks
Is there a way to replace the prerequisite .Net install UI with just an notification to the user that they need to install a particular version of .Net before they can install the bundle?
And Rob Mensching replies:
Yes, that is possible now.
... BUT HE DOESN'T ELABORATE. How is it possible now?
Thanks!
===============
In my Bundle's Bootstrap.Config:
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v6" /> <!-- Pretending it's the future! -->
</startup>
The Bundle itself does not reference any .NET stuff and does not reference WixNetFxExtension and uses the custom <BootstrapperApplicationRef Id="ManagedBootstrapperApplicationHost" />
To answer how to handle checking for the .Net 4.0 Framework include the WixNetfxExtension in your project
then under product add a reference to the property NETFRAMEWORK40FULL and put a condition on it.
<PropertyRef Id="NETFRAMEWORK40FULL"/>
<Condition Message="This application requires .NET Framework 4.0. Please install the .NET Framework then run this installer again.">
<![CDATA[Installed OR NETFRAMEWORK40FULL]]>
</Condition>
for the chained case again include wixnetfxextension and include NetFx40Redist package group
<PackageGroupRef Id="NetFx40Redist"/>
I have a project that I am creating an installer for. I have the msi created that will do the install but I also need to install some pre-reqs (.NET 4.0 and VSTO client tools or whatever they are called)
From what I can tell I need to use a bootstrapper and while it seems to work I really don't want the default dialogs that make me approve the license. I would like to skip that completely. (If I could hide the bootstrapper that would be fine but just having an "Install" button without the EULA would be ok).
Here is the xml I am currently using.
<?xml version="1.0" encoding="UTF-8"?>
<WixVariable Id="WixStdbaLogo" Value="logo.png" />
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense">
</BootstrapperApplicationRef>
<Chain>
<!-- TODO: Define the list of chained packages. -->
<PackageGroupRef Id="NetFx40Web"/>
<MsiPackage SourceFile="TestRibbonLocationInstaller.msi" DisplayInternalUI="yes" />
</Chain>
</Bundle>
So from what I can tell I need to basically create a custom bootstrap application for this that I then reference as the bootstrapperapplication. By doing this I will be able to better control the UI (Basically hide it).
Is this thought process correct?
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.
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.