WiX: CopyFile attributes

wix

On install I want to optionally copy some .ini files from SOURCEDIR to TARGETDIR which means from the directory the .msi file is located to the destination folder the app is setup to.

I did <CopyFile Id="CopyIniFile" DestinationProperty="INSTALLDIR" SourceProperty="SOURCEDIR" SourceName="Dreem15.ini" Delete="no" /> but it seems it's not doing anything. The log file is not helping much.

I've been successful in doing a much more elaborate scenario with CopyFile and I'm baffeled by this simple one.

Edit: I have these rows in MoveFile table:

|FileKey     |Component     |SourceName          |SourceFolder|DestFolder|Options
|CopyIniFile |CoAppLicAndIni|Dreem15.ini         |SOURCEDIR   |INSTALLDIR|0
|MoveDataFile|CoAppLicAndIni|Dreem10_Personal.mdf|DB_DIR10    |INSTALLDIR|0

and the second one is working. DB_DIR10 is searched in registry like this

<Property Id="DB_DIR10">
    <RegistrySearch Id='DbDirSearch10' Type='raw' Root='HKLM' Key='Software\$(var.CompanyName)\$(var.MsdeInstance)' Name='Dreem10_Personal' />
</Property>

Best Answer

According to the windows installer documentation for the sourcedir property, it points to "the root directory that contains the source cabinet file or the source file tree of the installation package".

So either you were not aware that SourceDir is a predefined windows installer property, or you are trying to copy an unpackaged file from the installation medium that contains the msi. In the latter case it would probably make more sense to install the file like a normal component so that it will be properly uninstalled.

Edit: I've tested the "copy from install medium" scenario and it worked for me. Also, I've installed with

misexec /lvx* install.log /i mymsi.msi

and the log did show the file being copied. What does the log say in your case?

Edit2: While CopyFile worked for me, a better solution is to add an uncompressed medium to your wxs like this:

<Media Id='2'/>

And then adapt the File element for your customizable config file like this:

<File Source='path\to\default\config.ini' Compressed='no' DiskId='2' />

This will make the installer look for config.ini in the same folder as the msi, combining the advantages of customizability and a clean uninstall.

Related Solutions

How to implement WiX installer upgrade

Finally I found a solution - I'm posting it here for other people who might have the same problem (all 5 of you):

Change the product ID to *

Under product add The following:

<Property Id="PREVIOUSVERSIONSINSTALLED" Secure="yes" />
<Upgrade Id="YOUR_GUID">  
   <UpgradeVersion
      Minimum="1.0.0.0" Maximum="99.0.0.0"
      Property="PREVIOUSVERSIONSINSTALLED"
      IncludeMinimum="yes" IncludeMaximum="no" />
</Upgrade>

Under InstallExecuteSequence add:

<RemoveExistingProducts Before="InstallInitialize" />

From now on whenever I install the product it removed previous installed versions.

Note: replace upgrade Id with your own GUID

WiX tricks and tips

Keep variables in a separate wxi include file. Enables re-use, variables are faster to find and (if needed) allows for easier manipulation by an external tool.

Define Platform variables for x86 and x64 builds

<!-- Product name as you want it to appear in Add/Remove Programs-->
<?if $(var.Platform) = x64 ?>
  <?define ProductName = "Product Name (64 bit)" ?>
  <?define Win64 = "yes" ?>
  <?define PlatformProgramFilesFolder = "ProgramFiles64Folder" ?>
<?else ?>
  <?define ProductName = "Product Name" ?>
  <?define Win64 = "no" ?>
  <?define PlatformProgramFilesFolder = "ProgramFilesFolder" ?>
<?endif ?>

Store the installation location in the registry, enabling upgrades to find the correct location. For example, if a user sets custom install directory.

 <Property Id="INSTALLLOCATION">
    <RegistrySearch Id="RegistrySearch" Type="raw" Root="HKLM" Win64="$(var.Win64)"
              Key="Software\Company\Product" Name="InstallLocation" />
 </Property>

Note: WiX guru Rob Mensching has posted an excellent blog entry which goes into more detail and fixes an edge case when properties are set from the command line.

Examples using 1. 2. and 3.

<?include $(sys.CURRENTDIR)\Config.wxi?>
<Product ... >
  <Package InstallerVersion="200" InstallPrivileges="elevated"
           InstallScope="perMachine" Platform="$(var.Platform)"
           Compressed="yes" Description="$(var.ProductName)" />

and

<Directory Id="TARGETDIR" Name="SourceDir">
  <Directory Id="$(var.PlatformProgramFilesFolder)">
    <Directory Id="INSTALLLOCATION" Name="$(var.InstallName)">

The simplest approach is always do major upgrades, since it allows both new installs and upgrades in the single MSI. UpgradeCode is fixed to a unique Guid and will never change, unless we don't want to upgrade existing product.

Note: In WiX 3.5 there is a new MajorUpgrade element which makes life even easier!

Creating an icon in Add/Remove Programs

<Icon Id="Company.ico" SourceFile="..\Tools\Company\Images\Company.ico" />
<Property Id="ARPPRODUCTICON" Value="Company.ico" />
<Property Id="ARPHELPLINK" Value="http://www.example.com/" />

On release builds we version our installers, copying the msi file to a deployment directory. An example of this using a wixproj target called from AfterBuild target:

<Target Name="CopyToDeploy" Condition="'$(Configuration)' == 'Release'">
  <!-- Note we append AssemblyFileVersion, changing MSI file name only works with Major Upgrades -->
  <Copy SourceFiles="$(OutputPath)$(OutputName).msi" 
        DestinationFiles="..\Deploy\Setup\$(OutputName) $(AssemblyFileVersion)_$(Platform).msi" />
</Target>

Use heat to harvest files with wildcard (*) Guid. Useful if you want to reuse WXS files across multiple projects (see my answer on multiple versions of the same product). For example, this batch file automatically harvests RoboHelp output.
```
@echo off  
robocopy ..\WebHelp "%TEMP%\WebHelpTemp\WebHelp" /E /NP /PURGE /XD .svn  
"%WIX%bin\heat" dir "%TEMP%\WebHelp" -nologo -sfrag -suid -ag -srd -dir WebHelp -out WebHelp.wxs -cg WebHelpComponent -dr INSTALLLOCATION -var var.WebDeploySourceDir 
```
There's a bit going on, robocopy is stripping out Subversion working copy metadata before harvesting; the -dr root directory reference is set to our installation location rather than default TARGETDIR; -var is used to create a variable to specify the source directory (web deployment output).

Easy way to include the product version in the welcome dialog title by using Strings.wxl for localization. (Credit: saschabeaumont. Added as this great tip is hidden in a comment)

<WixLocalization Culture="en-US" xmlns="http://schemas.microsoft.com/wix/2006/localization">
    <String Id="WelcomeDlgTitle">{\WixUI_Font_Bigger}Welcome to the [ProductName] [ProductVersion] Setup Wizard</String>
</WixLocalization>

Save yourself some pain and follow Wim Coehen's advice of one component per file. This also allows you to leave out (or wild-card *) the component GUID.
Rob Mensching has a neat way to quickly track down problems in MSI log files by searching for value 3. Note the comments regarding internationalization.
When adding conditional features, it's more intuitive to set the default feature level to 0 (disabled) and then set the condition level to your desired value. If you set the default feature level >= 1, the condition level has to be 0 to disable it, meaning the condition logic has to be the opposite to what you'd expect, which can be confusing :)
```
<Feature Id="NewInstallFeature" Level="0" Description="New installation feature" Absent="allow">
  <Condition Level="1">NOT UPGRADEFOUND</Condition>
</Feature>
<Feature Id="UpgradeFeature" Level="0" Description="Upgrade feature" Absent="allow">
  <Condition Level="1">UPGRADEFOUND</Condition>
</Feature>
```

Best Answer

Related Solutions

How to implement WiX installer upgrade

WiX tricks and tips

Related Topic