I followed the tutorial here: http://www.codeproject.com/KB/library/driver-install-with-wix.aspx but it just doesn't seem to want to work - the DPInst exe never actually seems to run? All the files are being laid-down correctly - I even noticed that in the tutorial they missed a quote.
My custom action looks like this:
<CustomAction Id='Install_M2_Driver'
Execute='deferred' Directory='DRIVER_ROOT'
ExeCommand='"[dirDpInst]DPInst.exe" /SA /PATH "[dirM2]"'
Return='ignore' />
I even tried replacing the DPInst.exe with a simple exe that echoed the arguments back to me, everything looks good, if I actually run the command from the command-line while the echo message box was up it would bring up the DPInst install GUI.
Found it, need to turn impersonate off:
<CustomAction Id='Install_M2_Driver'
Execute='deferred'
Directory='DRIVER_ROOT'
Impersonate='no'
ExeCommand='"[dirDpInst]DPInst.exe" /SA /PATH \"[dirM2]\"'
Return='ignore' />
Related
Hi I would like to perform the following CustomAction when installing my program:
<!--Include the custom action for overwrite Client.config-->
<CustomAction Id="SetCmdLineParams" Property="QtExecCA" Value='if exist "[CURRENTDIRECTORY]\Client.config" ("xcopy" /Y "[CURRENTDIRECTORY]\Client.config" "[INSTALLFOLDER]")' Execute="immediate" />
<CustomAction Id="QtExecCA" BinaryKey="WixCA" DllEntry="CAQuietExec" Execute="deferred" Return="check" Impersonate="no"/>
<!--Include the InstallExecuteSequence for overwrite Client.config-->
<InstallExecuteSequence>
<Custom Action="SetCmdLineParams" After="CostFinalize"/>
<Custom Action="QtExecCA" Before="InstallFinalize" />
</InstallExecuteSequence>
Unfortunately this doesn't work because: CAQuietExec: Command string must begin with quoted application name.
But if I quote "if exist", then the command does not work. What can I do now?
if exist is a feature of cmd.exe. You'd need to say cmd /c first or create a .bat file and call that.
Honestly though, this is really fragile code. For one CURRENTDIR isn't always going to be what you think it is. You should write a C++ or C# custom action that uses the OriginalDatabase property to get where the MSI is running from and copy the config file from there.
Another approach I've used very successfully in the past is to write a utility that can transform a seed MSI by embedding a user provided config file into it. Now the deployment story is simplified.
I'm rebuilding my xampp and CI environment (on win7) from scratch but am having trouble running phpdoc through phing. In particular, Phing is looking to phpdocumentor.ini in a place that doesn't exist (and never has).
Phing and PhpDocumentor have both been installed through Pear, paths setup seems fine, and have these versions:
php version 5.4.7
pear version 1.9.4
phpdoc version 2.0.1
phing version 2.6.1
Relevant paths on the system are:
H:\xampp\php;
H:\xampp\php\pear;
On my sample project:
I can run phpdoc without a hitch, for example: phpdoc -d apps -t docs runs fine.
Here's my phpdoc task, which has worked well in the past:
<phpdoc title=Docs" destdir="${docsdir}" sourcecode="false" output="HTML:frames:earthli">
<fileset dir="./apps">
<include name="**/*.php" />
</fileset>
<projdocfileset dir=".">
<include name="README" />
<include name="INSTALL" />
<include name="CHANGELOG" />
</projdocfileset>
</phpdoc>
When I run Phing, phpdoc fails with the following notice:
Parsing configuration file phpDocumentor.ini...
(found in C:\php\pear\data/PhpDocumentor/)...
ERROR: cannot open phpDocumentor.ini in directory
-Is phpdoc in either the path or include_path in your php.ini file?
There is no c:\php... directory, and never has been, so I don't know where this has come from.
I can only get this working if I create the whole PHPDocumentor structure Phing anticipates on C: but I'd ideally like to get the ini file's anticipated location changed so I have everything on the one drive.
Is there any way I can inform Phing of the true location of my phpdocumentor.ini?
I've not found this specific problem listed on SO, but am hopeful someone else has seen and rectified this. The Phing site docs/forum/trac don't list any recent reports of this problem.
Thanks all
It looks like you're trying to use phpDocumentor 2.x and seeing some behavior from what looks like phpDocumentor 1.x. Perhaps there is some 1.x code that came with the XAMPP source that is lingering and affecting your ability to run 2.x cleanly.
In considering the Phing angle, in glancing at the Phing manual, it looks like the correct Phing task to use for phpDocumentor 2.x is the DocBlox task [1] rather than the old PhpDoc task.
[1] -- http://www.phing.info/docs/guide/stable/apcs52.html.
Downloading the latest zip archive release of XAMPP for Windows I see that the file:
\xampp\php\pear\PhpDocumentor\phpDocumentor\Setup.inc.php
the function parseIni() refers directly to the aforementioned path:
enter code herephpDocumentor_out(" (found in " . 'C:\php\pear\data/PhpDocumentor' . PATH_DELIMITER . ")...\n");
So its more likely to be a XAMPP problem than any of the components I've been upgrading or force-reinstalling.
I try to execute an EXE file from an MSI file in WiX, but I got 1603 error when doing InitializeSetup.
Action ended 12:09:54: InstallValidate. Return value 1.
Action start 12:09:54: InstallInitialize.
Action ended 12:09:54: InstallInitialize. Return value 3.
Action ended 12:09:54: INSTALL. Return value 3.
What is wrong in this WiX Script?
<Product Name='something' Id='11934d63-12d1-4792-829e-046de3bb987e'
UpgradeCode='{a101616a-365c-44a7-bfcb-fafb356c2ea1}'
Language='1033' Version='8.3.4' Manufacturer='something2'>
<Package Id='*' InstallerVersion='200' Compressed='yes' />
<Binary Id="Instalator.exe" SourceFile="d:\Instalator.exe"/>
<CustomAction Id="LaunchFile" BinaryKey="Instalator.exe" ExeCommand="" Execute='deferred' Return='asyncNoWait' Impersonate='no'/>
<InstallExecuteSequence>
<Custom Action='LaunchFile' Before='InstallFinalize'/>
</InstallExecuteSequence>
</Product>
I don't know why, but when I add:
<Directory Id='TARGETDIR' Name='SourceDir'>
<Component Id='MainExecutable' Guid='1193cd63-12d1-4792-829e-046de3bb987e'>
</Component>
</Directory>
<Feature Id='Complete' Level='1'>
<ComponentRef Id='MainExecutable' />
</Feature>
after Package node -> then it works fine. I need to figure out why...
I have some other concerns about what you are doing here, but if you really need to go out of process to an EXE to complete your install, then I'd suggest using the Quiet Execution Custom Action.
You should know though that this isn't a good practice for a number of reasons. 1) It's not declarative, 2) it doesn't support rollbacks. There are others but those are the biggest IMO.
BTW, WiX isn't "scripting". Understand that and you'll understand why not to call EXE's.
Because you are running the exe as a deferred action, it runs in the context of the SYSTEM account. This error is due to the system account not having the required permissions on the file system http://support.microsoft.com/kb/834484.
It is possible to get around this using PowerShell to execute the exe using the -RunAs switch, but this is a bit nasty. It really all depends exactly what you are doing in the exe as to the best course of action. I'm with Mr. Painter, using an EXE should be the last resort.
Another option is to move the exe setup code so that it runs the first time the user runs the app.
Important note for WIX, After completion of all application installation then the .sql file or database files runs through wix or wpf or winform application.
I've got a WiX installer that is meant to update VS 2010 templates after installing them. The code I'm using is as follows:
<CustomAction
Id="InstallTemplates"
ExeCommand=""[VISUALSTUDIODIR]devenv.exe" /installvstemplates"
Directory="VISUALSTUDIODIR"
Execute="commit"
Return="check"
HideTarget="no"
Impersonate="no"/>
<InstallExecuteSequence>
<Custom Action="InstallTemplates" Before="InstallFinalize"></Custom>
</InstallExecuteSequence>
In the above, VISUALSTUDIODIR refers to the correct location, and templates are correctly deployed. However, it seems that the command does not get called, so no templates are actually installed. What am I doing wrong?
WiX has built-in functionality to do that. Add a reference to WixVSExtension.dll and add the following authoring:
<CustomActionRef Id="VS2010InstallVSTemplates" />
Make sure that VISUALSTUDIODIR is an actual directory in your MSI package (it's saved in Directory table). This is a requirement for this type of custom action.
Also, try creating an installation log and search for your custom action to see what happens.
I'm sure this is fairly easy, but I've kind of had a hard time with it. I've got a custom action that executes a different (non-msi) installer on installation. Unfortunately, I've noticed that it also executes the installer on UNinstallation!
I've looked through the options but I cant' seem to find out how to stop this. If anybody could help me I would be incredibly grateful.
Also, how do I set a custom action to go off only during UNinstall? Any help is greatly appreciated guys!
Add a condition on the action so it's only triggered during installation, not uninstallation.
Action run only during Install
NOT Installed AND NOT PATCH
Action runs during Install and repair
NOT REMOVE
Run on initial installation only:
NOT Installed
Run on initial install or when repair is selected.
NOT Installed OR MaintenanceMode="Modify"
To only run an action during uninstall use the following condition:
REMOVE~="ALL"
To only run an action during upgrade:
Installed AND NOT REMOVE
An example:
<InstallExecuteSequence>
..
<Custom Action="QtExecIdOfCA" Before="InstallFinalize">NOT Installed</Custom>
..
</InstallExecuteSequence>
..
..
<CustomAction Id="QtExecIdOfCA" BinaryKey="WixCA" DllEntry="CAQuietExec" Execute="deferred" Return="ignore" Impersonate="no"/>
Notice! Condition is added to the <Custom> tag and not the <CustomAction> it confused me, because Custom is followed by Action attribue
A bit of a correction:
Finally, to only run an action during uninstall use the following condition:
REMOVE="ALL"
This seems more appropriate as the property REMOVE contains the features being uninstalled.
So if I do a modify to remove one feature, REMOVE is true and the action that was to execute only on uninstall executes on modify.
More details here on MSDN
Please be careful with REMOVE=ALL. It is not available before installvalidate sequence.
And check below links for more details:
http://msdn.microsoft.com/en-us/library/aa371194(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/aa368013(v=vs.85).aspx
A condition on the custom action, probably with a matching custom action to do the uninstall. Not sure what tools you're using, but assuming the secondary install is tied to a component, I would use that component state. A state of =3 means a target state of installed. A state = 2 means a target state of absent. Note that the state won't be set if there is no change.