WIX HeatDirectory Task - Setting the preprocessorVariable - msbuild

I'm trying to set the preprocessor variable in wix and i'm unable to find an example of this or explanation on how to do it anywhere on the internet, i'm hoping somebody here can explain or show me where im going wrong!
I have tried the example shown here regarding setting var values
http://www.ageektrapped.com/blog/setting-properties-for-wix-in-msbuild/
The documentation for using the HeatDirectory taks in wix can be found here and is not very useful at all!
How do i set the preprocessorVariable to substitute the SourceDir for another variable name?

PreprocessorVariable for heat really need more doc and example... I've spend lots of time making it work too. This is how it works in my wixproj file:
<PropertyGroup>
<DefineConstants Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">HarvestPath=..\distribution\Debug</DefineConstants>
<DefineConstants Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">HarvestPath=..\distribution\Release</DefineConstants>
</PropertyGroup>
<Target Name="BeforeBuild">
<HeatDirectory Directory="..\distribution\$(Configuration)"
PreprocessorVariable="var.HarvestPath"
OutputFile="HeatGeneratedFileList.wxs"
ComponentGroupName="HeatGenerated"
DirectoryRefId="INSTALLFOLDER"
AutogenerateGuids="true"
ToolPath="$(WixToolPath)"
SuppressFragments="true"
SuppressRegistry="true"
SuppressRootDirectory="true"/>
</Target>
All you need is to define the variable. There is no magical "HeatDefinitions" :)

I use Wix v3.10.
No need to explicitly call HeatDirectory MSBuild Task. ItemGroup with special name "HarvestDirectory" can be prepared, and later the "HarvestDirectory" target will process it. *.wsx file is created in the IntermediateOutputPath and is included in Compile list (processed by Candle).
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x64' ">
...
<MyFinalFolder Condition=" '$(MyFinalFolder)' == '' ">$(MSBuildProjectDirectory)\Final\</MyFinalFolder>
<DefineConstants>FinalFolder=$(MyFinalFolder)</DefineConstants>
</PropertyGroup>
...
<Import Project="$(WixTargetsPath)" />
<Target Name="BeforeBuild">
<!--
No need to explicitly call HeatDirectory MSBuild Task.
Instead follow documentation http://wixtoolset.org/documentation/manual/v3/msbuild/target_reference/harvestdirectory.html, which has sample and
important comment:
This target is processed before compilation. Generated authoring is automatically added to the Compile item group to be compiled by the Candle task.
So, *.wsx file created in the IntermediateOutputPath and included in Compile list (processed by Candle).
The following ItemGroup with special name "HarvestDirectory" can be prepared, and later the "HarvestDirectory" target will process it, see
C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\wix2010.targets
-->
<ItemGroup>
<HarvestDirectory Include="$(MyFinalFolder)">
<DirectoryRefId>INSTALLFOLDER</DirectoryRefId>
<SuppressRootDirectory>true</SuppressRootDirectory>
<SuppressCom>true</SuppressCom>
<SuppressRegistry>true</SuppressRegistry>
<ComponentGroupName>FilesComponentGroup</ComponentGroupName>
<PreprocessorVariable>var.FinalFolder</PreprocessorVariable>
</HarvestDirectory>
</ItemGroup>
</Target>
The wxs file:
<?xml version="1.0" encoding="utf-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Fragment>
<DirectoryRef Id="INSTALLFOLDER">
<Component Id="cmp9AA09F4A73FA53E2BDDE4B7BB5C91DFB" Guid="*">
<File Id="fil9AA09F4A73FA53E2BDDE4B7BB5C91DFB" KeyPath="yes" Source="$(var.FinalFolder)\7z.dll" />
</Component>

I created an example project on GitHub showing how to successfully use the HarvestDirectory target, which is a higher-level thing that calls the HeatDirectory task. You don't need to directly call the HeatDirectory task yourself. You can see all of the example code here:
https://github.com/DavidEGrayson/wix-example-harvest-directory
Here are the most important parts:
foo.wixproj
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<ProductVersion>1.0.0</ProductVersion>
<DefineConstants>ProductVersion=$(ProductVersion);ItemDir=items</DefineConstants>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">x86</Platform>
<ProjectGuid>27e80d9b-d8b6-423a-a6ff-1d9c5b23bb31</ProjectGuid>
<SchemaVersion>2.0</SchemaVersion>
<OutputName>foo-$(ProductVersion)</OutputName>
<OutputType>Package</OutputType>
<DefineSolutionProperties>false</DefineSolutionProperties>
<WixTargetsPath Condition=" '$(WixTargetsPath)' == '' ">$(MSBuildExtensionsPath)\Microsoft\WiX\v3.x\Wix.targets</WixTargetsPath>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
<OutputPath>bin\$(Configuration)\</OutputPath>
<IntermediateOutputPath>obj\$(Configuration)\</IntermediateOutputPath>
<DefineConstants>Debug;ProductVersion=$(ProductVersion)</DefineConstants>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
<OutputPath>bin\$(Configuration)\</OutputPath>
<IntermediateOutputPath>obj\$(Configuration)\</IntermediateOutputPath>
</PropertyGroup>
<ItemGroup>
<Compile Include="foo.wxs" />
<HarvestDirectory Include="items">
<DirectoryRefId>ItemDir</DirectoryRefId>
<ComponentGroupName>Items</ComponentGroupName>
<PreprocessorVariable>var.ItemDir</PreprocessorVariable>
</HarvestDirectory>
<WixExtension Include="WixUIExtension" />
</ItemGroup>
<Import Project="$(WixTargetsPath)" />
</Project>
foo.wxs
<?xml version="1.0" encoding="utf-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product Name="Foo"
Version="$(var.ProductVersion)"
Manufacturer="Foo Inc."
Language="1033"
UpgradeCode="0c8504c9-4e62-4e2c-9e1c-4fbe1c478b37"
Id="*">
<Package Description="Foo"
Manufacturer="Foo Inc."
Compressed="yes"
InstallerVersion="301" />
<MajorUpgrade AllowDowngrades="no"
DowngradeErrorMessage="A newer version of this software is already installed."
AllowSameVersionUpgrades="no" />
<Media Id="1" Cabinet="cabinet.cab" EmbedCab="yes" />
<Property Id="ARPCOMMENTS">
Foo package.
</Property>
<Property Id="ARPCONTACT">Foo Inc.</Property>
<Property Id="ARPURLINFOABOUT">https://www.example.com/</Property>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder" Name="PFiles">
<Directory Id="INSTALLDIR" Name="Foo">
<Component Id="readme">
<File Id="readme" Name="README.txt" Source="README.txt" />
</Component>
<Directory Id="ItemDir" />
</Directory>
</Directory>
</Directory>
<Feature Id="Software"
Title="Foo"
AllowAdvertise="no"
ConfigurableDirectory="INSTALLDIR">
<ComponentRef Id="readme" />
<ComponentGroupRef Id="Items" />
</Feature>
<Property Id="WIXUI_INSTALLDIR" Value="INSTALLDIR" />
<UIRef Id="WixUI_InstallDir" />
</Product>
</Wix>

There is a $(HeatDefinitions) property you can set to define these in the parent .wixproj file:
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<HeatDefinitions>MySourcePath=..\src\Your.App\bin\Release</HeatDefinitions>
</PropertyGroup>
<ItemGroup>
<Compile Include="Phoenix.wxs" />
<Compile Include="_HeatGeneratedFileList.wxs" />
</ItemGroup>
<Target Name="BeforeBuild">
<HeatDirectory Directory="..\src\Your.App\bin\Release"
OutputFile="_HeatGeneratedFileList.wxs"
PreprocessorVariable="var.MySourcePath" />
</Target>
</Project>
The only existing mention of this magic property I can find (on the entire Internet) is in a single question about Team Build on the wix-users mailing list. I stumbled across it by luck after spending nearly a day tearing out my hair trying to fix undefined preprocessor variable errors.

I found out what it was, after 1 day of trying various things, the link above is correct but to use the var in the heatdirectory task you have to do it like this.
<HarvestDirectory Include="$(ProjectDirectory)\" >
<DirectoryRefId>WEBDIR</DirectoryRefId>
<KeepEmptyDirectories>true</KeepEmptyDirectories>
<SuppressRegistry>true</SuppressRegistry>
<ComponentGroupName>DynamicWebFiles</ComponentGroupName>
<PreprocessorVariable>var.WixDynamicSourceDirectory</PreprocessorVariable>
</HarvestDirectory>

I have a very large installer kit to build in Visual Studio 2013 (includes some tools related to the main project, a windows service and a web application with a non-trivial directory structure). I'm still learning how to use WiX, and am still crafting, testing and refining the WiX project. Currently, I have the harvest tasks set up as build events, using a command of the form
"C:\Program Files (x86)\WiX Toolset v3.9\bin\heat.exe" dir "$(SolutionDir)\MyProjectDir\bin\$(ConfigurationName)" -cg MyComponentRef -ag -dr MYINSTALLDIR -srd -wixvar -var var.MySourceFiles -sreg -out "$(SolutionDir)\Deployment\My Installer Project\ComponentList.wxs" -t "$(SolutionDir)\Deployment\My Installer Project\FileFilter.xslt"
This command just grabs all the files in the project's bin\Debug (or bin\Release) folder, then filters it using an xml stylesheet transform. There are quite a few harvests to gather like this, so maintaining all the source file variables (the "var.MySourceFiles" argument in the command) was becoming tedious and error prone. Initially, I had added the declarations to the project's preprocessor variables, but I wanted something that was a little more "self-contained". Using the helpful tips I found at WiX tricks and tips, I declared a new include file, "PreprocessorVars.wxi" with content
and got the xslt to include it in the output generated by heat.exe with the snippet
<xsl:processing-instruction name="include">
$(sys.CURRENTDIR)\PreprocessorVars.wxi
</xsl:processing-instruction>
The xslt now produces output that looks something like this:
<?xml version="1.0" encoding="utf-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" xmlns:wix="http://schemas.microsoft.com/wix/2006/wi">
<?include
$(sys.CURRENTDIR)\PreprocessorVars.wxi
?>
<Fragment>
<DirectoryRef Id="MYINSTALLDIR" />
</Fragment>
<Fragment>
<ComponentGroup Id="MyComponentRef">
<Component Id="xyz" Directory="MYINSTALLDIR" Guid="*">
<File Id="abc" KeyPath="yes" Source="$(var.MySourceFiles)\MyProjectExecutable.exe" />
</Component>
</ComponentGroup>
</Fragment>
</Wix>
which Wix processes without any errors.

Related

How can I include different packages in different Configuration/Platform combinations?

I have a library that is designed to work with Sap Business One's SDK. The SDK for V10 is different to the one for V9.3, I also have x86/x64 and SQL/HANA builds, this gives me 8 permutations and therefore 8 packages.
The projects that consume these packages will also have 8 builds. I would like to set up the project file and targets so that a specific package is selected for a specific Configuration & Platform. I am trying to work this out, but it makes absolutely no sense.
Currently I have the following in my project file:
<ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'B1v93SQL|x64' ">
<PackageReference Include="OchALCommon.v93SQLx64" Version="1.0.*" />
</ItemGroup>
<ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'B1v93SQL|x86' ">
<PackageReference Include="OchALCommon.v93SQLx86" Version="1.0.*" />
</ItemGroup>
<ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'B1v93HANA|x64' ">
<PackageReference Include="OchALCommon.v93HANAx64" Version="1.0.*" />
</ItemGroup>
<ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'B1v93HANA|x86' ">
<PackageReference Include="OchALCommon.v93HANAx86" Version="1.0.*" />
</ItemGroup>
<ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'B1v10SQL|x64' ">
<PackageReference Include="OchALCommon.v10SQLx64" Version="1.0.*" />
</ItemGroup>
<ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'B1v10SQL|x86' ">
<PackageReference Include="OchALCommon.v10SQLx86" Version="1.0.*" />
</ItemGroup>
<ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'B1v10HANA|x64' ">
<PackageReference Include="OchALCommon.v10HANAx64" Version="1.0.*" />
</ItemGroup>
<ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'B1v10HANA|x86' ">
<PackageReference Include="OchALCommon.v10HANAx86" Version="1.0.*" />
</ItemGroup>
Visual studio indicates all 8 packages and a build process the dependencies of each one - this seems wrong. I also tried this code within a "Directory.Build.targets" file, which initially seemed to work, but then Visual Studio stopped reponding to changes in the targets file (even after a reboot).
We have always used this kind of referencing in the past with Assembly references,and it seems to work, I have no idea how to make PackageReference function. Does anybody know how best to package this library in my scenario?
In an ideal world, I'd want to somehow store my 64 bit and 32 bit build plus some appropriate targets in a single nuget package so that the consuming project gets the right bitness and the right sub project references. Currently I can't work out how to do this, nor get any other workable scenario going.
Again, does anybody know how to do anything like this?
Thanks.
Thus far I have been able to solve the issue by using separate files (.targets) for each ProjectReference, and then ensuring that only those files containing the reference information are included in the project by referencing specific .targets files.
I have then put .targets files into an umbrella nupkg to select which of the actual payloads I want to use. The entire arrangement looks as follows:
I published 8 payload files as follows:
MyLibrary.v93HANAx64
MyLibrary.v93HANAx86
MyLibrary.v93SQLx64
MyLibrary.v93SQLx86
MyLibrary.v10HANAx64
MyLibrary.v10HANAx86
MyLibrary.v10SQLx64
MyLibrary.v10SQLx86
Each payload file simply contains a standard lib/net40 folder with libraries as specified in the https://learn.microsoft.com/en-us/nuget/create-packages/creating-a-package page.
My consuming project has 4 Configurations:
B1v93HANA
B1v93SQL
B1v10HANA
B1v10SQL
I then have an umbrella project "MyLibrary.Targets" containing content as follows:
##build/net40/MyLibrary.Targets.targets
<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Build">
<Import Project="MyLibrary/$(Configuration).targets" />
</Project>
##build/net40/MyLibrary/B1v10HANA.targets
<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Build">
<ItemGroup>
<PackageReference Include="MyLibrary.v10HANA$(Platform)" Version="1.0.*" />
</ItemGroup>
</Project>
##build/net40/MyLibrary/B1v10SQL.targets
<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Build">
<ItemGroup>
<PackageReference Include="MyLibrary.v10SQL$(Platform)" Version="1.0.*" />
</ItemGroup>
</Project>
##build/net40/MyLibrary/B1v93HANA.targets
<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Build">
<ItemGroup>
<PackageReference Include="MyLibrary.v93HANA$(Platform)" Version="1.0.*" />
</ItemGroup>
</Project>
##build/net40/MyLibrary/B1v93SQL.targets
<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Build">
<ItemGroup>
<PackageReference Include="MyLibrary.v93SQL$(Platform)" Version="1.0.*" />
</ItemGroup>
</Project>
I also have targets files in this folder, "Debug.targets" and "Release.targets" which use my preferred default library in those cases.
.nupec files for all of the packages are pretty standard as per the above linked Microsoft guide. A default nuspec file can be created with the 'nuget spec' command and can then be edited.
My functional package nuspec files have content in 'package/metadata/dependencies' which identify required packages:
<dependencies>
<group targetFramework=".NETFramework4.0">
<dependency id="CryptLib" version="*" />
<dependency id="SAPBusinessOneSDK.HANA" version="10.0.*" />
</group>
</dependencies>
My Selector package "MyLibrary.targets" does not have dependencies, but does have a files section 'package/files':
<files>
<file src="readme.txt" target="" />
<file src="build\**" target="build" />
</files>
Hopefully this saves somebody some time.

Adventures in Installing a C#/WPF Application (WiX)

I've got a C#/WPF application that is one step up from simple - it's got the main application, a couple of libraries, and then some NuGet packages. If I look in the project's bin/release/netcoreapp3.1 directory, there's a single EXE, a couple of JSONs, and a bunch of DLLs (some of which have PDBs). Nothing too crazy. The client wants an installer which doesn't sound like an unreasonable request.
I first try the installer that comes with Visual Studio 2019 and am astounded at how useless it is. After deleting it, I poke around on the interwebs and discover that WiX seems to be relatively popular. Ok, says I, I will try it.
After installing the WiX Toolset Build Tools (which sounds a bit redundant) and the WiX Toolset Visual Studio Extension, and restarting Visual Studio, it's looking good. I right-click on my solution, select "Add" and "New Project" and see "Setup Project for WiX v3" which looks good. I click Next, name it Installer, and I get this:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product Id="*" Name="Installer" Language="1033" Version="1.0.0.0" Manufacturer="" UpgradeCode="2995de5a-87ef-443d-a25a-450d39720349">
<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" />
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
<MediaTemplate />
<Feature Id="ProductFeature" Title="Installer" Level="1">
<ComponentGroupRef Id="ProductComponents" />
</Feature>
</Product>
<Fragment>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLFOLDER" Name="Installer" />
</Directory>
</Directory>
</Fragment>
<Fragment>
<ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER">
<!-- TODO: Remove the comments around this Component element and the ComponentRef below in order to add resources to this installer. -->
<!-- <Component Id="ProductComponent"> -->
<!-- TODO: Insert files, registry keys, and other resources here. -->
<!-- </Component> -->
</ComponentGroup>
</Fragment>
</Wix>
Which looks promising. If I try to build it gives me the error "The Product/#Manufacturer attribute's value cannot be an empty string" which is a textbook example of what an error message should look like. Precise, tells me exactly what is happening, and points me in the direction of what I need to do. I'm liking this! I put some text in the Manufacturer attribute, rebuild, and it says "Build: 1 succeeded" and I have an installer. It does give me the warning "The media table has no entries" which makes perfect sense as I haven't told it to install any files.
I start reading the official WiX tutorial and it's painfully verbose. It's not actually a tutorial as much as a treatise on why WiX is the way it is. I don't actually care at this point, I just want the darn thing to work. I want a tutorial, not the entire history of the company. Eventually I find a link for "Getting Started" and I feel a little better. But again, instead of getting me started, I get a lengthy explanation of the internal workings of the system. At this point I DON'T CARE. I want to get a basic installer working, then you can hit me with some details. After several more pages of the author thinking he or she is a university professor in a lecture, I finally get some XML - and it's for a media tag that I may or may not need, it's not at all clear. And, since there isn't a Media tag in the WXS file that was generated for me, I don't know where it goes.
Giving up on the tutorial, I do a Google search for "wix "visual studio" project" and find this page which has a link for "Creating a simple setup" which is perfect. It actually takes me through what I need, step-by-step. I follow the instructions, hit Build, and it says "Build: 1 succeeded". I find the MSI file, run it, there's no UI which seems odd but I can live with that, and it creates a folder in my "Program Files (x86)" folder that has the primary DLL for my project. Progress!
So now I need to include the DLLs constructed from my library projects, and all the DLLs that were included from NuGet packages. It would be cool if I could tell WiX "please include all the files required by my various NuGet packets" but poking around the web, it appears WiX doesn't know how to do that, but that's OK, really all I need is for the installer to include all of the DLLs that end up in my bin/release/netcoreapp3.1 directory.
Trying the obvious wildcard approach:
<ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER">
<Component Id="ProductComponent">
<File Source="$(var.MyApplication.TargetPath)" />
<File Source="$(var.MyApplication.TargetDir)/*" />
</Component>
</ComponentGroup>
Just gives an error that is not as easy to read as the first error, but does seem to indicate the asterisk is a no-go. If I do a Google search for "wix add all files in directory" returns a whole bunch of different suggestions, all of which are complicated, which seems odd for such a basic thing. But following the instructions in this page, I end up with an installer that almost works. I get the error "Undefined preprocessor variable $(var.HarvestPath)". This page happened to have the answer to that one, and I have a working installer again. But now it's including absolutely everything in that folder, and I only want the DLLs. Doing a Google search for "wix heatdirectory exclude files" gives no answers, it appears this feature is relatively brain-dead.
So here is my current WIXPROJ:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" InitialTargets="EnsureWixToolsetInstalled" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<DefineConstants>HarvestPath=...\Deploy</DefineConstants>
<HeatDefinitions>MySourcePath=..\src\Your.App\bin\Release</HeatDefinitions>
</PropertyGroup>
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">x86</Platform>
<ProductVersion>3.10</ProductVersion>
<ProjectGuid>4ece284d-9247-4f7a-84a7-34820606a003</ProjectGuid>
<SchemaVersion>2.0</SchemaVersion>
<OutputName>Installer</OutputName>
<OutputType>Package</OutputType>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
<OutputPath>bin\$(Configuration)\</OutputPath>
<IntermediateOutputPath>obj\$(Configuration)\</IntermediateOutputPath>
<DefineConstants>Debug</DefineConstants>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
<OutputPath>bin\$(Configuration)\</OutputPath>
<IntermediateOutputPath>obj\$(Configuration)\</IntermediateOutputPath>
</PropertyGroup>
<ItemGroup>
<Compile Include="Product.wxs" />
<!-- This will be your default one -->
<Compile Include="HeatGeneratedFileList.wxs" />
<!-- This is the Heat created one -->
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..\MyApplication\MyApplication.csproj">
<Name>MyApplication</Name>
<Project>{6064dca8-d649-4592-bed5-34039bb3d30d}</Project>
<Private>True</Private>
<DoNotHarvest>True</DoNotHarvest>
<RefProjectOutputGroups>Binaries;Content;Satellites</RefProjectOutputGroups>
<RefTargetDir>INSTALLFOLDER</RefTargetDir>
</ProjectReference>
</ItemGroup>
<Import Project="$(WixTargetsPath)" Condition=" '$(WixTargetsPath)' != '' " />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\WiX\v3.x\Wix.targets" Condition=" '$(WixTargetsPath)' == '' AND Exists('$(MSBuildExtensionsPath32)\Microsoft\WiX\v3.x\Wix.targets') " />
<Target Name="EnsureWixToolsetInstalled" Condition=" '$(WixTargetsImported)' != 'true' ">
<Error Text="The WiX Toolset v3.11 (or newer) build tools must be installed to build this project. To download the WiX Toolset, see http://wixtoolset.org/releases/" />
</Target>
<Target Name="BeforeBuild">
<HeatDirectory Directory="..\MyApplication\bin\$(Configuration)\netcoreapp3.1"
PreprocessorVariable="var.MyApplication.ProjectDir"
OutputFile="HeatGeneratedFileList.wxs"
ComponentGroupName="HeatGenerated"
DirectoryRefId="INSTALLFOLDER"
AutogenerateGuids="true"
ToolPath="$(WixToolPath)"
SuppressFragments="true"
SuppressRegistry="true"
SuppressRootDirectory="true" />
</Target>
<!--
To modify your build process, add your task inside one of the targets below and uncomment it.
Other similar extension points exist, see Wix.targets.
<Target Name="BeforeBuild">
</Target>
<Target Name="AfterBuild">
</Target>
-->
</Project>
All I want is a simple installer that copies over the EXE and associated DLLs. Why is this so difficult? Can WiX do what I need? Or do I need a different installer toolkit?

Make WIX installer place files in AppData

I'm writing a dapp for ethereum client for windows. In order to make dapp available for user I have to place specific files in the folder in appdata. So I just should place some files in %appdata%\Parity\Ethereum\dapps\mydappname. But I always get weird errors with WIX, the last one is
Error 93 ICE64: The directory dapp is in the user profile but is not
listed in the RemoveFile table.
I have following myapp.wixproj
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" InitialTargets="EnsureWixToolsetInstalled" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">x86</Platform>
<ProductVersion>3.10</ProductVersion>
<ProjectGuid>8beed2e4-8784-4cb5-8648-cdf55c5defe6</ProjectGuid>
<SchemaVersion>2.0</SchemaVersion>
<OutputName>FairsDapp</OutputName>
<OutputType>Package</OutputType>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
<OutputPath>bin\$(Configuration)\</OutputPath>
<IntermediateOutputPath>obj\$(Configuration)\</IntermediateOutputPath>
<DefineConstants>Debug</DefineConstants>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
<OutputPath>bin\$(Configuration)\</OutputPath>
<IntermediateOutputPath>obj\$(Configuration)\</IntermediateOutputPath>
</PropertyGroup>
<PropertyGroup>
<DefineConstants>HarvestPath=dapp</DefineConstants>
</PropertyGroup>
<ItemGroup>
<Compile Include="Product.wxs" />
<Compile Include="Dapp.wxs" />
</ItemGroup>
<Import Project="$(WixTargetsPath)" Condition=" '$(WixTargetsPath)' != '' " />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\WiX\v3.x\Wix.targets" Condition=" '$(WixTargetsPath)' == '' AND Exists('$(MSBuildExtensionsPath32)\Microsoft\WiX\v3.x\Wix.targets') " />
<Target Name="EnsureWixToolsetInstalled" Condition=" '$(WixTargetsImported)' != 'true' ">
<Error Text="The WiX Toolset v3.11 (or newer) build tools must be installed to build this project. To download the WiX Toolset, see http://wixtoolset.org/releases/" />
</Target>
<Target Name="BeforeBuild">
<HeatDirectory
DirectoryRefId="INSTALLFOLDER"
OutputFile="Dapp.wxs"
Directory="dapp"
ComponentGroupName="SourceComponentGroup"
ToolPath="$(WixToolPath)"
PreprocessorVariable="var.HarvestPath"
AutogenerateGuids="true" />
</Target>
</Project>
And following wxs:
<?xml version="1.0" encoding="UTF-8"?>
<Wix
xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product Id="*" Name="Dapp" Language="1049" Version="1.0.0.3" Manufacturer="Me" UpgradeCode="fb09dccc-6606-4b5d-8dcb-28146c28663a" Codepage="1251">
<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" />
<MediaTemplate EmbedCab="yes"/>
<Feature Id="ProductFeature" Title="FDapp" Level="1">
<ComponentGroupRef Id="ProductComponents" />
</Feature>
</Product>
<Fragment>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="AppDataFolder">
<Directory Id="Parity">
<Directory Id="dapps">
<Directory Id="INSTALLFOLDER" Name="F2"></Directory>
</Directory>
</Directory>
</Directory>
</Directory>
</Fragment>
<Fragment>
<ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER"></ComponentGroup>
</Fragment>
</Wix>
I found that I have to use heat task to create a correct files tree, but now I'm stuck with simple task "copy these files on user machine".
I am unfamiliar with this type of application (dapp for ethereum client for windows) - so the advice has to be generic I am afraid.
Per-User Files & Registry Settings: In general deploying files to the user profile and HKCU settings is difficult with MSI. As Chris points out it basically just works for the user installing the MSI, unless you actively add constructs to get files copied to all user profiles, and even then it is sort of clunky.
Approaches: I wrote a long answer a long time ago on the subject: Create folder and file on Current user profile, from Admin Profile (long and elaborate, but without any automagic solutions).
Preferred Approach: Before getting involved in too much complexity, the easiest approach is generally to use your application to copy the userprofile files in place for every user on first launch - instead of using the setup to install user-specific files.
This requires that there is a separate application executable to launch, generally via its own shortcut - which it might not be? It generally does not work for addins for example.
Approach 1: Install template files per-machine and then copy them to each
user's userprofile on application launch.
Approach 2: Alternatively I like to download files directly from a server
or database and put in the userprofile - also on first launch.
Apply Updates?: There are ways to ensure that you can re-copy files if there are
changes to your templates as described here: http://forum.installsite.net/index.php?showtopic=21552 (Feb 2019 converted to WayBack Machine link).
Errors: The specific problem you report has to do with the need for a per-user registry key path and a RemoveFolder entry for all folders targeting userprofile locations:
<Directory Id="AppDataFolder">
<Directory Id="Parity">
<Directory Id="dapps">
<Directory Id="INSTALLFOLDER" Name="F2">
<Component Guid="{77777777-7777-7777-7777-7777777777DD}" Feature="MainApplication">
<RegistryKey Root="HKCU" Key="Software\TestManufacturer\TestApp">
<RegistryValue Name="Flag" Value="1" Type="string" KeyPath="yes" />
</RegistryKey>
<RemoveFolder Id="RemoveINSTALLFOLDER" Directory="INSTALLFOLDER" On="uninstall" />
<RemoveFolder Id="RemoveParity" Directory="Parity" On="uninstall" />
<RemoveFolder Id="Removedapps" Directory="dapps" On="uninstall" />
<File Source="Test.exe" />
</Component>
</Directory>
</Directory>
This is just one of MSI's conventions and quirks. As already stated,
install all files per-machine and copy them to the userprofile with
the application instead. It will dis-entangle them from any setup
interference in the future. Then you do not need to deal with these RemoveFolder issues.
WiX Installer - Children of LocalAppDataFolder installed to wrong location after UAC prompt
I've found and verified that the solution is working when adding a CustomAction which uses PowerShell to iterate over all user profiles and copies a "template appdata folder" to them. The template folder is shipped and installed by the WIX MSI installer to [ProductDir]appdata, e.g "C:\Program Files (x86)\myApplication\appdata".
Here's what I've put to as a CustomAction to the WXS WIX script to achieve this:
<CustomAction
Id="ExecPsXcopyCmd"
Directory='ProductDir'
Execute='deferred'
Impersonate='no'
ExeCommand='[SystemFolder]WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy "ByPass" -Command "$productDir = &apos;[ProductDir]&apos;; $userRoot = (Split-Path $Env:PUBLIC); Foreach ($profile in Get-ChildItem -Path $userRoot -Directory -Exclude &apos;Public&apos; -Force -ErrorAction SilentlyContinue) { $srcPath = Join-Path -Path $productDir -ChildPath &apos;appdata&apos;; $dstPath = Join-Path -Path $profile.Fullname -ChildPath &apos;AppData\Roaming\myApplication&apos;; xcopy /S /E /I /R /H /Y $srcPath $dstPath}"'
Return='check'/>
<InstallExecuteSequence>
<RemoveExistingProducts Before="InstallInitialize" />
<Custom Action="ExecPsXcopyCmd" After="WriteRegistryValues">NOT REMOVE</Custom>
<LaunchConditions After="AppSearch"/>
</InstallExecuteSequence>
This assumes your product installation directory is called "ProductDir".

Can this MSBuild target be written more simply/elegantly?

My MSBuild knowledge is a bit rusty. I wrote this working target today but I'm sure it can be reduced in size.
Can anyone see how to express this more simply please?
<Target Name="FolderX">
<PropertyGroup>
<Dest>$(StandardModelDir)\FolderX</Dest>
</PropertyGroup>
<ItemGroup>
<File Include="$(CustDir)\File1.sql">
<Dest>$(Dest)\Views--Alpha</Dest>
</File>
<File Include="$(CustDir)\File2.sql">
<Dest>$(Dest)\Views--Alpha</Dest>
</File>
<File Include="$(CustDir)\File3.sql">
<Dest>$(Dest)\Views--Bravo</Dest>
</File>
<File Include="$(CustDir)\File4.sql">
<Dest>$(Dest)\Views--Bravo</Dest>
</File>
</ItemGroup>
<Copy
SourceFiles="#(File)"
DestinationFolder="%(File.Dest)\.."
/>
</Target>
Note that the Files are not recursively stored in the source directory so I cannot use %(RecursiveDir)
You can use masks. In your case you can use file extension mask, *.sql
Example from MSDN: http://msdn.microsoft.com/en-us/library/3e54c37h.aspx
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<MySourceFiles Include="c:\MySourceTree\**\*.*"/>
</ItemGroup>
<Target Name="CopyFiles">
<Copy
SourceFiles="#(MySourceFiles)"
DestinationFiles="#(MySourceFiles->'c:\MyDestinationTree\%(RecursiveDir)%(Filename)%(Extension)')"
/>
</Target>
</Project>

WIX: Howto set the name of the msi output file dynamically

I want to include some dynamic part in the filename of the msi file my wix projects produce. This dynamic part should be controlled by variables which are part of my wix project and are declared like this:
<?define ProductVersion="7.1.0.1" ?>
Does anybody know about a way of sending that value of that wix variable to the linker to use it as a part of the output filename?
By the way: I'm using Wix3
You could update the OutputName of your .wixproj and use an MSBuild variable to pass through the version number or any other variable you like.
My build script looks like this:
set PRODUCTVERSION=7.1.0.1
MSBuild.exe /p:Configuration=Debug /p:ProductVersion=%PRODUCTVERSION% Installer.wixproj
And my WiX project looks like this:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">x86</Platform>
<ProductVersion>1.0.0.0</ProductVersion>
<ProjectGuid>{b7415c44-8d59-4ac2-b698-03e399a305e3}</ProjectGuid>
<SchemaVersion>2.0</SchemaVersion>
<OutputName>Installer.$(ProductVersion)</OutputName>
...
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
<OutputPath>bin\$(Configuration)\</OutputPath>
<IntermediateOutputPath>obj\$(Configuration)\</IntermediateOutputPath>
<DefineConstants>Debug</DefineConstants>
<WixVariables>ProductVersion=$(ProductVersion)</WixVariables>
</PropertyGroup>
...
</Project>
The output would be:
Installer.7.1.0.1.msi
The msi file name is not determined by your wix files, but by the light.exe -out switch. You can use the same value for -out and inside your wix files if you do the following in your build script, assuming it is a batch script:
set an environment variable with set
productversion=1.2.3
Pass -out foo%productversion%.msi to the
light.exe linker
use the same environment variable in
your wix files as
$(env.productversion)
Open *.wixproj (example: Setup.wixproj)
Go to the end of the file.
$(Configuration) = Debug| Release …
Set path of your application on AssemblyFiles.
<Target Name="BeforeBuild">
<GetAssemblyIdentity AssemblyFiles="..\App\bin\$(Configuration)\App.exe">
<Output TaskParameter="Assemblies" ItemName="AsmInfo" />
</GetAssemblyIdentity>
<CreateProperty Value="$(SolutionName)_%(AsmInfo.Version)_$(Configuration)">
<Output TaskParameter="Value" PropertyName="TargetName" />
</CreateProperty>
</Target>
Output = App_1.0.0.0_Debug.msi
I found a couple of great reference posts to do just this operation:
http://blog.tentaclesoftware.com/archive/2009/05/03/38.aspx
and a follow-on with a better method of creating the output file using a pre-build event:
http://blog.tentaclesoftware.com/archive/2010/08/05/99.aspx
I know the links are old, but the method is sound.
Here are the basic steps:
Put the version you wish to use into a file you can access from your project. I use the main executable of my installation because I also bind to that version in my wxs. In my case, since I am building with C# and use SVN, I have a template version of my assembly.cs, assembly.cs.txt, that I run subwcrev on as a pre-build event to create the assembly.cs that gets compiled into my executable (I actually do it in a separate project in my solution). Subwcrev inserts some date and revision information that I use to create a version in the form "major.minor.version.0" where I use "year.month.revision.0" for my version.
Now, I usually just set AssemblyFileVersion with this method, but to be able to use my version number in the wixproj build event referenced in the post above, I also need to set AssemblyVersion since that is what can be accessed with GetAssemblyIdentity. This method would be questionable if I were really using an assembly someone else links to, but for me it is OK since it is in my final application executable.
Follow the steps outlined in the second post (the first post discusses using the binding method for version in wxs and how to unload and edit the wixproj - valuable context for the second post).
Works like a charm!
Update some years later - it looks like the links I referenced are dead. Here is a snapshot of what I changed to make it work.
In my main product wxs file, I changed (some names have been changed or omitted to protect the innocent and the guilty):
<ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER">
<!-- TODO: Remove the comments around this Component element and the ComponentRef below in order to add resources to this installer. -->
<Component Id="ProductComponent" Guid="DF1AB3A6-17D0-4176-B3AC-C073AC47AA80">
<RemoveFile Id="PurgeAppFolder" Name="*.*" On="uninstall" />
<File Source="$(var.MyApp.TargetPath)" KeyPath="yes"/>
<File Source="$(var.MyApp.ProjectDir)\bin\Release\MyData.dll"/>
<File Source="$(var.MyApp.ProjectDir)\bin\$(var.MyApp.Configuration)\ICSharpCode.SharpZipLib.dll"/>
</Component>
</ComponentGroup>
to
<ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER">
<!-- TODO: Remove the comments around this Component element and the ComponentRef below in order to add resources to this installer. -->
<Component Id="ProductComponent" Guid="DF1AB3A6-17D0-4176-B3AC-C073AC47AA80">
<RemoveFile Id="PurgeAppFolder" Name="*.*" On="uninstall" />
<File Id="MAINEXECUTABLE" Source="$(var.MyApp.TargetPath)" KeyPath="yes">
<Shortcut Directory="ApplicationProgramsFolder" Id="MYAPPEXEAPF" Name="My App Name" Icon="MyAppIcon.exe" IconIndex="0" Advertise="yes" />
<Shortcut Directory="ApplicationDesktopFolder" Id="MYAPPEXEADF" Name="My App Name" Icon="MyAppIcon.exe" IconIndex="0" Advertise="yes" />
</File>
<File Source="$(var.MyApp.ProjectDir)\bin\Release\MyData.dll"/>
<File Source="$(var.MyApp.ProjectDir)\bin\$(var.MyApp.Configuration)\ICSharpCode.SharpZipLib.dll"/>
</Component>
</ComponentGroup>
and up at the top I added:
<Product Id="C86505BF-303F-4D6B-8F5F-43A57635F85D" Name="My Application Name" Language="1033" Version="!(bind.FileVersion.MAINEXECUTABLE)" Manufacturer="My Software Shop" UpgradeCode="D1C628E5-5478-4DA5-A31A-F9191D5B1544">
Note that the Version is bound to the file version of MAINEXECUTABLE, which is defined in the main product component.
I hope this helps!
If you have several configurations then inside .wixprj file you can do the following
<OutputName Condition="'$(Configuration)' == 'User'">User.Setup</OutputName>
<OutputName Condition="'$(Configuration)' == 'Designer'">Designerr.Setup</OutputName>
Since it's just a file name, why not have a post-build action that renames the file in your build script (assuming MSBuild)?
Do the variables have to be defined in WiX? I'm building my setup binaries from MSBuild, and I've simply set the output file name to MyProject_$(Platform) -- I expect that any MSBuild variable substitution will work equally well.
Product Id="GUID" Name="whatevername $(var.ProductVersion)"