I want to execute the below lines of code through WIX and here is the code where am able to do it through the command prompt:
dism.exe /online /enable-feature:NetFx3 /quiet /norestart -----> To enable
dism /online /get-featureinfo:netfx3 ------> To verify the value
If all that you want to do using Wix is to launch executables, Wix/windows installer provides multiple ways to do that.
I generally prefer using Quite Execution custom actions provided by the Wix toolset. Reason being, it allows me to launch executables without displaying any console windows, which otherwise would have required me to write custom action code.
Take a look at :
http://wixtoolset.org/documentation/manual/v3/customactions/qtexec.html
The examples in the above URL are sufficient enough to help you get started.
In order to use QtExec (Quite execution custom actions), you must include a reference to the WixUtilExtension when building your MSI. To do this, add the command line argument -ext WixUtilExtension.dll when calling Light.exe.
Related
Is it possible to initiate a silent installation of a WiX bundle through the use of a command line argument in the format of /a or /arg?
I'm aware of the available command line arguments accepted by the wixstdba bootstrapper.
Specifically, we need to do this using the argument /s /v/qn argument.
NB: Executing the bootsrapper with the command line setup.exe /s /v/qn actually does initiate a silent install, and I assume this is because the BA interprets the /s as equivalent to -s. But since I can't find this behaviour documented anywhere, I am nervous about relying upon it, and would prefer an explicit method for doing this.
TL;DR
The reason we would like to support this argument /format is due to the automatic upgrade operation of a previous version of the software. This version of the software launched an automatically downloaded upgrade to itself, which was an InstallShield package, with the switches /s /v/qn to launch the MSI as a silent installation. Those switches are coded into a constant field, so the fact that we are moving from InstallShield to WiX presents this problem.
We would like to replicate this functionality but need a way to translate this set of arguments to either a -silent or -passive argument, or find some other method to accomplish this task.
Burn supports both - and / as switch characters. Silent UI mode is supported as q, quiet, s, and silent with leading - and /. See the code at https://github.com/wixtoolset/wix3/blob/develop/src/burn/engine/core.cpp#L1098.
I've been trying to sign an MSI file in a post build event with the following code
signtool sign /t http://timestamp.verisign.com/scripts/timestamp.dll /f "E:\Products\Tools\DigitalId\Certificate.pfx" /p 1501ocbc /d "Server" "E:\Products\Setup\Server_Setup\ServerSetup\bin\Release\en-US\ServerSetup.msi"
This will sign OK with the Visual Studio command prompt and similar code works for C++ projects. However, when building the setup and signing the code with post build events, I get a code error, 9009. After much debugging I have come to the conclusion that WiX is using the ordinary command prompt. How do I get cmd.exe in WiX to open with Visual Studio tools?
Or is there another way to sign my packages?
You could define the event like this:
"%programw6432%\microsoft sdks\windows\v7.1\bin\signtool.exe" sign /t etc..
Note: you need to adapt the path to your install (program files, Windows SDK version, etc.), or you could also define your own environment variable.
It looks like there is a built-in way of signing MSI files which seems to work correctly with SignTool: Insignia.
Register the certificate and use the /sha1 hashkey - just to be sure the certificate is good (check browser-internetoptions/content/certificate)
SignTool path - make it explicit as Simon Mourier suggested or put signtool.exe in an accesible path
Choosing postbuild operation - you should sign the MSI file after you've completed all operations upon the MSI file. Any action upon the MSI (INSERT/UPDATE Property) will undo the signing.
I want to run an executable with command line parameters in WiX. How do I pass parameters?
I would add that I need to run a console EXE file which is contained by the MSI file to be installed.
I tried to add parameters somewhere in the example, step 3 at How To: Run the Installed Application After Setup, but I have not found out how to achieve this.
Simply set the ExeCommand attribute to the command line you want. For the custom action used in the article you mentioned, the ExeCommand attribute can contain command line options.
The mostly good point in creating installers is not to use a prompt by itself. This is ugly and you need to be patient on administrator rights, trying to start third-party applications.
Instead of this you can create a deferred CA, using C++, C# or VB.NET. It is a bit longer, needs to know "some" syntax and so on, but you can control whatever you want. To start with, here are some resources:
Deferred custom actions with WiX (simple how-to)
CustomAction Element (at WiX home on SourceForge)
I am trying to execute a custom action that was written C# (.NET 3.5) that has a dependency on a single DLL (Also C# 3.5). I have included both the .EXE and .DLL in the installation, and verified that they are being copied to the install location. However, every time I attempt to run the custom action, I get the following error:
Action start 7:21:16: InstallFinalize.
Error 1721. There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor. Action: UpgradeTo022, location: C:\Program Files\Test\, command: Upgrade-0.2.2.EXE
MSI (s) (CC:38) [07:21:19:061]: Product: Test -- Error 1721. There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor. Action: UpgradeTo022, location: C:\Program Files\Test\, command: Upgrade-0.2.2.EXE
The Custom Action is defined as follows:
<CustomAction Id="UpgradeTo022"
Directory="INSTALLLOCATION"
Impersonate="no"
Execute="deferred"
ExeCommand='Upgrade-0.2.2.EXE'>
Note: The custom action must be run with elevated privileges, thus the deferred execution and Impersonate="no" attributes.
It is scheduled as follows:
<InstallExecuteSequence>
<Custom Action="UpgradeTo022" Before="InstallFinalize">NOT Installed</Custom>
</InstallExecuteSequence>
The files are installed as follows:
<Component Id="CMP_UpgradeCommon" Guid="8ECF5076-732E-4010-A33B-BE362D818949" Win64="yes">
<File Id="FILE_UpgradeCommonDLL"
Source="..\Upgrade\UpgradeCommon\bin\Debug\UpgradeCommon.dll" Vital="yes"/>
</Component>
I've seen some allusions to running managed EXEs as being a problem with Custom Actions and MSis, but no real definitive answers.
I have also tried just running a very simple .EXE with no dependencies as a custom action, and have had no luck there.
Being somewhat new to creating installer packages, it's very likely I'm either trying to do something that isn't supported, or missing something simple.
Thanks in advance for any pointers in figuring this out.
JT.
Unfortunately this could be a number of things. Firstly are you sure .net 3.5 is installed on the target box? On from that, can you actually run the exe fine on the target machine?
One other thing to note is that deferred actions run under the context of the system account, so if the exe requires access to a profile for any reason, this will cause it to fail. I had this very issue when trying to generate a certificate as part of my install. I was scratching my head for ages on this and in the end had to spawn PowerShell with the -RunAs switch which then ran a script to call the exe. Might be worth checking to see if the app runs fine under the system account (http://www.tech-recipes.com/rx/1288/how-to-run-applications-in-the-local-system-account-lsa/)
So I have a Wix 3.0 project that installs an IIS7 Native Code Module. When uninstalling I would like to be able to shut down the IIS7 application pools before deleting the file so that a reboot is not necessary.
I am using the appcmd utility to shut down the app pools in a CustomAction element, but when I attempt to do an uninstall I get this error before the customaction is ever invoked:
The setup must update files or
services that cannot be updated while
the system is running. If you choose
to continue, a reboot will be required
to complete the setup.
I have the "After='InstallInitialize'" property set on the CustomAction, because the documentation says that any deferred/not-impersonated custom action must come between InstallInitialize and InstallFinalize.
So is there some way to have a custom action execute before this check for files in use is made? Or disable this check for a given file, or make the check happen later in the sequence?
Yes, you can specify the order for actions to occur by modifying the Sequence column in the InstallExecuteSequence table within the MSI file.
Get the ORCA tool to examine the MSI file to see what I mean, and use a Javascript script to modify the MSI as appropriate.