I'm creating an MSI installer using WiX and I have, say, a *.bat file that I'm copying to SomeFolder2 under %temp% (something like the code snippet below...)
...
<Directory Id='TARGETDIR' Name='SourceDir'>
<Directory Id='ProgramFilesFolder' Name='PFiles'>
<Directory Id='MyDir' Name='SomeFolder'>
<!-- %TEMP -->
<Directory Id="TempFolder" Name="TmpFolder">
<Directory Id='MyDir2' Name='SomeFolder2'>
<!-- CREATE THE %TEMP%\SomeFolder2 FOLDER -->
<Component Id='FolderComponent' Guid='{GUID}'>
<CreateFolder />
</Component>
<Component Id='CheckComponent' Guid='{GUID}'>
<File Id='mybat' Name='mybat.bat' DiskId='1' Source='.\mybat.bat' KeyPath="yes">
<Shortcut Id="mybatShcut"
Directory="ProgramMenuDir"
Name="{name}"
WorkingDirectory='INSTALLDIR'
Advertise="yes" />
</File>
</Component>
</Directory>
</Directory>
</Directory>
</Directory>
</Directory>
...
Now, to run this, I have two custom actions (DESTDIR is %TEMP%\SomeFolder2):
<CustomAction Id="SetPath" Property="ThePath" Value="[DESTDIR]\mybat.bat" />
<CustomAction Id="StartAction" Property="ThePath" ExeCommand="" Return="asyncNoWait" />
Then in the install sequence:
<InstallExecuteSequence>
<Custom Action="SetPath" After="{some standard MS action}">NOT REMOVE="ALL"</Custom>
<Custom Action="StartAction" Before="{some other action}">NOT REMOVE="ALL"</Custom>
...
</InstallExecuteSequence>
I've put SetPath to run after a variety of standard actions (for example, PublishProduct) while StartAction will come before another custom action.
When I run the MSI file, I look in the log and ThePath does get set with the correct path. However, when StartAction is run, I get this error:
Return value 1631.
which, according to the documentation, translate to "ERROR_CREATE_FAILED" (the Windows Installer service failed to start. Contact your support personnel). The thing is, the file did get copied to %TEMP%\SomeFolder2 (before the setting of the path and the actual exection, might I add...), but for some reason, it doesn't execute at all (if you do execute it manually or via the command prompt or whatnot, it does execute normally).
I tried putting the same file under ProgramFiles\Some_Directory_For_The_Program. The same thing happens; it gets copied there, but it doesn't execute. Why is this happening?
First off, as long as you'd like to use a file installed by your package in a custom action, you should make it deferred. That is, StartAction CA in your example must be deferred. Also, I try to use QtExec standard CA when I need to run executables from CA.
I hope this helps.
Related
I am using Wix 3.6 to create a setup. I am still learning as I go along. The information out there is still scattered around. I am just waiting for my Wix Developer Guide book arriving.
I currently have a custom UI dialog where the user enters some application configuration. Part of that configuration is to specify a log folder. This at present this just sets a property [LogFolder]. This is defaulted to something like D:\Logs.
I want the installer to create that directory when the setup is run. I have the following to try and do this but it just created a folder named [LOGFOLDER] on the D: drive when I run the setup.
<Product ...
<Directory Id="TARGETDIR" Name="SourceDir" >
<Directory Id="LogFolderDir" Name="[LOGFOLDER]" >
<Component Id="LogFolderComponent" Guid="{7E7D6916-B321-40D6-ABAD-696B57A6E5FB}" KeyPath="yes">
<CreateFolder />
</Component>
</Directory>
</Directory>
...
</Product>
How can I do this with Wix?
The first step is create a property set to the value you want:
<Product>
<Property Id="LOGFOLDER" Value="D:\Logs" />
</Product>
The second step is to create a dialog where you set this property (or another thing to change its value):
<Dialog>
<Control Id="Edit_LogFolder" Type="Edit" Property="LOGFOLDER" />
</Dialog>
Then you need to change your directories structure to create this folder in a default location:
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLFOLDER" Name="MyApp">
<Directory Id="LOGFOLDER" Name="Logs" />
</Directory>
</Directory>
The last step is to create a Component that will create the directory, like this:
<ComponentGroup Id="ComponentGroup_LogFolder">
<Component Id="Component_LogFolder" Guid="" Directory="LOGFOLDER">
<CreateFolder Directory="LOGFOLDER" />
</Component>
</ComponentGroup>
Remark:
If D:\ is a disc drive and you have a disc inserted, the installation will fail because it will try to create the folder and it won't succeed.
The Name attribute isn't formattable so you can use properties in it. The Id 'LogFolderDir' doesn't have a parent such as "ProgramFilesFolder' so it's defaulting to the volume with the largest amount of disk space. In this case D but YMMV.
It's dangerous to default to D: because D: might not exist. How I'd set this directory up is Id="LOGDIR" Name="Logs" and make it a child of the INSTALLDIR/INSTALLLOCATION directory element. Then in your custom UI, wire up another BrowseFolder dialog to give the user the ability to override it. Or, make it associated with a required Logs feature so that the stock feature selection dialog can be used to select the feature and browse the destination folder.
If you still want it to "default" to D:\Logs what I would do is have a custom action that checks to see if D: exists and is a fixed disk. If so, set the LOGDIR=D:\Logs
There is a simpler solution by using the same ID for the property and the directory (without naming the directory). But you must use the full path of the folder in the property.
Let's say the log directory is C: \ ProgramDirectory \ Data \ Log and you want to set Data with a property (usually if the value of Data is different and conditionally set).
<Property Id="PR_DATA_DIRECTORY" Value="C:\ProgramDirectory\Data" />
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="DIR_PROGRAM" Name="C:\ProgramDirectory" >
<Directory Id="PR_DATA_DIRECTORY">
<Directory Id="DIR_LOG" Name="Log" />
<Directory/>
</Directory>
</Directory>
I've created a VSIX package that I install via a WIX-generated MSI.
However, when I install it, and look at it in VS2010, in the Tools > Extension Manager menu, it is [Disabled] and I need to enable it manually.
How can I avoid this?
** EDIT **
Here's what I did:
I tried adding capturing the VSInstallDir from the registry like this:
<Property Id="VSINSTALLER">
<RegistrySearch Id="VSInstallRegistry" Root="HKLM" Key="SOFTWARE\Wow6432Node\Microsoft\VisualStudio\10.0" Name="InstallDir" Type="directory" />
I added the directory structure under target-dir like this:
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="VSINSTALLER">
<Directory Id="Extensions" Name="Extensions">
<Directory Id="Copy_CompanyFolder" Name="my company">
<Directory Id="INSTALLVSIX" Name="app name">
</Directory>
</Directory>
</Directory>
</Directory>
And I added a CopyFile element to the component in the installation folder, like this:
<Component Id="VsPackage" Guid="00000000-0000-some-guid-00000000">
<File Id="VsPackageInstaller" Source="$(folder.prop)\extensionName.vsix"
KeyPath="yes" DiskId="1">
<CopyFile Id="Copy_InstallVsix"
DestinationDirectory="INSTALLVSIX" />
</File>
</Component>
And I added the true element to the manifest.
When I do this, the extension is not installed.
Any ideas why?
If you install your extension files to a directory you create under %VSInstallDir%\Common7\IDE\Extensions, it will be enabled automatically for all users. This is the recommendation for MSI-installed extensions.
Also, please be sure to add <InstalledByMsi>true</InstalledByMsi> to your vsixmanifest.
There is no need to run VSIXInstaller.exe or write registry keys to enable your extension (In fact, you really shouldn't do this.).
Use "VSIXInstaller.exe" tool from VS2010\Common7\IDE.
Also you can manually enable your extension by adding registry value to
HKCU\Software\Microsoft\VisualStudio\10.0Exp\ExtensionManager\EnabledExtensions
I have a component I need to install only if a registry key exists which means an application has been installed.
I need to assign the value of the registry key (it is a directory) to a property then use this property to copy files from.
I have the following script so far but get an error "The system cannot find the file '[MYTESTDIR]fileToCopy.dat'."
Any help would really be appreciated.
<Property Id="MYTESTDIR">
<RegistrySearch Id="NetFramework20"
Root="HKLM"
Key="SOFTWARE\TEST\VALUE\1.00"
Name="MyName"
Type="directory" />
</Property>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="TEST" Name="Test">
<Component Id="MyComponent" Guid="E5FF53DE-1739-42c4-BE37-60F810C9CD69">
<Condition>MYTESTDIR</Condition>
<File Id="fileToCopy.dat" Name="fileToCopy.dat" Source="[MYTESTDIR]fileToCopy.dat">
<CopyFile Id="fileToCopy.datCopy" DestinationProperty="WEBSERVICEBINFOLDER" />
</File>
</Directory>
</Directory>
</Directory>
<Feature Id="MyFeature" Title="MyFeature" Level="1">
<ComponentRef Id="MyComponent" />
</Feature>
Based on my reading of the Wix Schema documentation, your problem is that you have the CopyFile element nested under a File element. Ditch the File element and just have the CopyFile sit under the Component:
<Component Id="MyComponent" Guid="E5FF53DE-1739-42c4-BE37-60F810C9CD69">
<Condition>MYTESTDIR</Condition>
<CopyFile Id="fileToCopy.datCopy" SourceName="[MYTESTDIR]fileToCopy.dat" DestinationProperty="WEBSERVICEBINFOLDER" />
</Component>
The way you had it, nested under the File, Wix was looking for the file on your system during the build - rather than setting up a copy command to be run at install time.
MYTESTDIR is a windows installer property which will get its value on the target system when the package is being installed.
However, you are trying to use this property in a Source attribute, which is used to point to files on the system where the setup package is being build.
Obviously that is not going to work. Windows installer properties don't even exist while the Source attribute is being evaluated, so Source can definitely not support such use.
Bryan's answer is the correct solution for what you're trying to do here. Using CopyFile under a File element is not illegal, but it is intended for copying files which you also install. In this case, you want to copy a file which is already on the target system, so the File element is not appropriate.
I am using WiX to install a plugin for a software that I am not controlling. To install the plugin, I have to put the target folder in a registry key:
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="LocalAppDataFolder">
<Directory Id="APPROOTFOLDER" Name="Foobar Plugin" />
</Directory>
</Directory>
...
<DirectoryRef Id="APPROOTFOLDER">
<Component Id="register" Guid="240C21CC-D53B-45A7-94BD-6833CF1568BE">
<RegistryKey Root="HKCU" Key="Software\ACME\Plugins\FooBar">
<RegistryValue Name="InstallDir" Value="[APPROOTFOLDER]" Type="string"/>
</RegistryKey>
</RegistryKey>
</DirectoryRef>
After the installation, the registry key HKCU\Software\ACME\Plugins\FooBar\InstallDir will contain the installation target path, but with a trailing "\". Unfortunately, for some strange reasons, the host application (the provides the plugin architecture) crashes due to that. If there is no trailing slash, everything works fine!
Is there a way in WiX to get rid of the trailing slash?
One solution I was thinking of is simply adding a "." at the end of the path, however, this seems not to work in my scenario :( ..
You should not be using scripts in custom actions, but if you could limit down to only a few lines and to something as simple as this example, you should be Ok...
<CustomAction Id="VBScriptCommand" Script="vbscript">
<![CDATA[
value = Session.Property("INSTALLFOLDER")
If Right(value, 1) = "\" Then
value = Left(value, Len(value) - 1)
End If
Session.Property("SOME_PROPERTY") = value
]]>
</CustomAction>
<InstallExecuteSequence>
<Custom Action="VBScriptCommand" After="CostFinalize">NOT REMOVE</Custom>
</InstallExecuteSequence>
The only string manipulation you really have in Windows Installer is the manipulation of formatted data types. See MSDN for more information.
Windows Installer provides a trailing directory separator by design, so there isn't any way to remove this aside from a custom action. I'd suggest lodging a bug with the developers of the source package you're developing a plugin for, if you're encountering this error then other developers likely are too.
You can always do something like this:
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="LocalAppDataFolder">
<Directory Id="APPROOTFOLDER" Name="Foobar Plugin" />
</Directory>
</Directory>
...
<DirectoryRef Id="APPROOTFOLDER">
<Component Id="register" Guid="240C21CC-D53B-45A7-94BD-6833CF1568BE">
<RegistryKey Root="HKCU" Key="Software\ACME\Plugins\FooBar">
<RegistryValue Name="InstallDir" Value="[LocalAppDataFolder]\Foobar Plugin" Type="string"/>
</RegistryKey>
</RegistryKey>
</DirectoryRef>
And don't allow the user to change the final folder
As far as I know, Windows Installer doesn't provide any string manipulation natively, so this is going to require a custom action.
Newbie WiX question: How do I
1. Copy a single-use shell script to temp along with the installer
e.g.
<Binary Id='permissions.cmd' src='permissions.cmd'/>
2. Find and run that script at the end of the install.
e.g.
<CustomAction Id='SetFolderPermissions' BinaryKey='permissions.cmd'
ExeCommand='permissions.cmd' Return='ignore'/>
<InstallExecuteSequence>
<Custom Action="SetFolderPermissions" Sequence='1'/>
</InstallExecuteSequence>
I think I have at least three problems:
I can't find permissions.cmd to run it - do I need [TEMPDIR]permissions.cmd or something?
My Sequence comes too soon, before the program is installed.
I need cmd /c permissions.cmd somewhere in here, probably near ExeCommand?
In this example permissions.cmd uses cacls.exe to add the interactive user with write permissions to the %ProgramFiles%\Vendor ACL. I could also use secureObject - that question is "How do I add the interactive user to a directory in a localized Windows"?
Here's a working example (for setting permissions, not for running a script):
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder" Name="PFiles">
<Directory Id="BaseDir" Name="MyCo">
<Directory Id="INSTALLDIR" Name="MyApp" LongName="MyProd">
<!-- Create the folder, so that ACLs can be set to NetworkService -->
<Component Id="TheDestFolder" Guid="{333374B0-FFFF-4F9F-8CB1-D9737F658D51}"
DiskId="1" KeyPath="yes">
<CreateFolder Directory="INSTALLDIR">
<Permission User="NetworkService"
Extended="yes"
Delete="yes"
GenericAll="yes">
</Permission>
</CreateFolder>
</Component>
</Directory>
</Directory>
</Directory>
</Directory>
Note that this is using 'Extended="Yes"' in the Permission tag, so it's using the SecureObjects table and custom action not the LockPermissions table (see WiX docs for Permission Element). In this example the permissions applied to the MyProd directory by SecureObjects are inherited by subdirectories, which is not the case when LockPermissions is used.
I found the blog post From MSI to WiX, Part 5 - Custom actions: Introduction helpful when I wanted to understand CustomActions in WiX.
You can also find the definition of CustomAction and its attributes in CustomAction Element.
You need to do something like this
<CustomAction Id="CallCmd" Value="[SystemFolder]cmd.exe" />
<CustomAction Id="RunCmd" ExeCommand="/c permission.cmd" />
<InstallExecuteSequence>
<Custom Action="CallCmd" After="InstallInitialize" />
<Custom Action="RunCmd" After="CallCmd" />
</InstallExecuteSequence>
Have you got an example of how this is used? I mean, do use CreateFolder nested under the directory whose ACL I want to change? Or do I use CreateFolder first, separately? Is the following even close?
<Wix xmlns="http://schemas.microsoft.com/wix/2003/01/wi">
<Fragment>
<DirectoryRef Id="TARGETDIR">
<Directory Id='ProgramFilesFolder' Name='PFiles'>
<Directory Id="directory0" Name="MyApp" LongName="My Application">
<Component Id="component0" DiskId="1" Guid="AABBCCDD-EEFF-1122-3344-556677889900">
<CreateFolder>
<Permission User='INTERACTIVE'
GenericRead='yes'
GenericWrite='yes'
GenericExecute='yes'
Delete='yes'
DeleteChild='yes' />
<Permission User='Administrators' GenericAll='yes' />
</CreateFolder>
<File Id="file0" Name="myapp.exe" Vital="yes" Source="myapp.exe">
<Shortcut Id="StartMenuIcon" Directory="ProgramMenuFolder" Name="MyApp" LongName="My Application" />
</File>
</Component>
<Directory Id="directory1" Name="SubDir" LongName="Sub Directory 1">
<Component Id="component1" DiskId="1" Guid="A9B4D6FD-B67A-40b1-B518-A39F1D145FF8">
etc...
etc...
etc...
</Component>
</Directory>
</Directory>
</DirectoryRef>
</Fragment>
Rather than running custom action you can try using Permission element as a child of CreateFolder element, e.g.:
<CreateFolder>
<Permission User='INTERACTIVE' GenericRead='yes' GenericWrite='yes'
GenericExecute='yes' Delete='yes' DeleteChild='yes' />
<Permission User='Administrators' GenericAll='yes' />
</CreateFolder>
Does this overwrite or just edit the ACL of the folder?
According to MSDN documentation it overwrites:
Every file, registry key, or directory that is listed in the LockPermissions Table receives an explicit security descriptor, whether it replaces an existing object or not.
I just confirmed that by running test installation on Windows 2000.
Most people tend to steer clear of the lockPermissions table as it is not additive, meaning it will overwrite your current permissions (from a managed environment perspective, this is bad). I would suggest you use a tool which supports ACL inheritance such as SUBINACL or SETACL or one of the many ACL tools.
In relation to why your earlier posts failed there is a few reasons. There are four locations where you can put your custom actions (CAs): UI, Immediate, Deferred, and Commit/Rollback.
You need your CA to set permissions in the deferred sequence, because the files are not present until midway through the deferred sequence. As such, anything prior will fail.
Your setup is in immediate (so will fail)
Your setup is at sequence of 1 (which is not possible to be deferred so will fail)
You need to add an attribute of Execute="Deferred" and change sequence from "1" to:
<Custom Action="CallCmd" Execute="Deferred" Before="InstallFinalize" />
This will ensure it's done after the files are installed, but prior to the end of the deferred phase (the desired location).
I would also suggest you call the EXE file directly and not from a batch file. The installer service will launch and the EXE file directly in the context you need. Using a batch file will launch the batch file in the correct context and potentially lose context to an undesired account while executing.