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 = '[ProductDir]'; $userRoot = (Split-Path $Env:PUBLIC); Foreach ($profile in Get-ChildItem -Path $userRoot -Directory -Exclude 'Public' -Force -ErrorAction SilentlyContinue) { $srcPath = Join-Path -Path $productDir -ChildPath 'appdata'; $dstPath = Join-Path -Path $profile.Fullname -ChildPath 'AppData\Roaming\myApplication'; 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".
Related
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?
My first question is, should I work to get the compiler working with auto-generated guids?
I am trying to create an installer for a website with WiX. Please excuse my ignorance, this is my first WiX project. I am following this article:
http://blog.bartdemeyer.be/2013/10/create-an-installer-for-website-with-wix-part-1/
The process uses msbuild to call several WiX tools to ultimately create an MSI. The example uses "Generate guids now" (the "-gg" switch) when calling heat:
<Target Name="Harvest">
<!-- Harvest all content of published result -->
<Exec
Command='"$(WiX)bin\heat.exe" dir $(Publish) -dr INSTALLFOLDER -ke -srd -cg MgrWebComponents -var var.publishDir -gg -out $(WebSiteContentCode)'
ContinueOnError="false"
WorkingDirectory="." />
</Target>
I was reading elsewhere it is best practice to use auto-generated guids (the -ag switch) to ensure product updates install correctly. I notice the guids change every time heat is run.
<Fragment>
<ComponentGroup Id="MgrWebComponents">
<Component Id="cmp56294569B275493319100C26538BA16C" Directory="INSTALLFOLDER" Guid="{A43DA07B-C4CD-4FE0-AC09-EEA693AB2BA7}">
<File Id="fil93D55732EC03C2B809F21B9423BF5550" KeyPath="yes" Source="$(var.publishDir)\BrandImageService.ashx" />
</Component>
<Component Id="cmp6BD39B2D572EA73C29A81AE5D1C3F0C4" Directory="INSTALLFOLDER" Guid="{99B7B916-AEC0-4EE9-B17F-E7B325E93A4D}">
<File Id="filE861424851E26D456D43F5D1855B3E7B" KeyPath="yes" Source="$(var.publishDir)\Dashboard.aspx" />
</Component>
...
If I should use auto-generated guids I need to get the compiler working. I am getting errors for every file for trying to use auto-generated guids when compiling.
LGHT0231: The component 'cmp2BE6B5C092821452E1438D39A5110DDB' has a
key file with path 'TARGETDIR\inetpub\manager\tools\toolshome.aspx'.
Since this path is not rooted in one of the standard directories
(like ProgramFilesFolder), this component does not fit the criteria
for having an automatically generated guid. (This error may also
occur if a path contains a likely standard directory such as nesting a
directory with name "Common Files" under ProgramFilesFolder.)
My directory fragment is:
<Fragment>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="INETPUB" Name="Inetpub">
<Directory Id="INSTALLFOLDER" Name="Manager" />
</Directory>
</Directory>
</Fragment>
The heat generated fragment looks like:
<Fragment>
<ComponentGroup Id="MgrWebComponents">
<Component Id="cmp56294569B275493319100C26538BA16C" Directory="INSTALLFOLDER" Guid="*">
<File Id="fil93D55732EC03C2B809F21B9423BF5550" KeyPath="yes" Source="$(var.publishDir)\BrandImageService.ashx" />
</Component>
<Component Id="cmp6BD39B2D572EA73C29A81AE5D1C3F0C4" Directory="INSTALLFOLDER" Guid="*">
<File Id="filE861424851E26D456D43F5D1855B3E7B" KeyPath="yes" Source="$(var.publishDir)\Dashboard.aspx" />
</Component>
...
The targets for msbuild:
<Target Name="Build">
<!-- Compile whole solution in release mode -->
<MSBuild
Projects="..\Manager.sln"
Targets="ReBuild"
Properties="Configuration=Release" />
</Target>
<Target Name="PublishWebsite">
<!-- Remove complete publish folder in order to
be sure that everything will be newly compiled -->
<Message Text="Removing publish directory: $(SetupF)"/>
<RemoveDir Directories="$(SetupF)" ContinueOnError="false" />
<Message Text="Start to publish website" Importance="high" />
<MSBuild
Projects="..\\Manager\UI\Manager.UI.csproj"
Targets="ResolveReferences;_CopyWebApplication"
Properties="OutDir=$(Publish)bin\;WebProjectOutputDir=$(Publish);Configuration=Release" />
</Target>
<Target Name="Harvest">
<!-- Harvest all content of published result -->
<Exec
Command='"$(WiX)bin\heat.exe" website $(Publish) -dr INSTALLFOLDER -ke -srd -cg MgrWebComponents -var var.publishDir -ag -out $(WebSiteContentCode)'
ContinueOnError="false"
WorkingDirectory="." />
</Target>
<Target Name="WIX">
<!-- At last create an installer -->
<Message Text="TEST: #(WixCode)"/>
<Exec
Command='"$(WiX)bin\candle.exe" -dpublishDir=$(Publish) -dMgrWebResourceDir=. #(WixCode, ' ')'
ContinueOnError="false"
WorkingDirectory="." />
<Exec
Command='"$(WiX)bin\light.exe" -spdb -out $(MsiOut) #(WixObject, ' ')'
ContinueOnError="false"
WorkingDirectory="." />
<!-- A message at the end -->
<Message Text="Install package has been created." />
</Target>
The build command is: msbuild /t:Build;PublishWebsite;Harvest;WIX setup.build
I understand the generated guid uses the seed of the directory. Should I change the location of the directory?
Thank you!!
Thank you to #CheGueVerra , he pointed me in the right direction. I just changed the directory location to be in ProgramFiles and it was able to compile.
<Fragment>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLFOLDER" Name="Manager" />
</Directory>
</Directory>
</Fragment>
Later on I found a better way with the use of the "ComponentGuidGenerationSeed" attribute to keep the directory in the inetpub folder.
<Directory Id='TARGETDIR' Name='SourceDir'>
<Directory Id="IISMain" Name='inetpub'>
<Directory Id="WWWMain" Name='wwwroot'
ComponentGuidGenerationSeed='{Put-your-own-generated-guid-here}'>
<Directory Id='INSTALLFOLDER' Name='Manager'>
</Directory>
</Directory>
</Directory>
</Directory>
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.
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)"
I am a student developer and I have built several installers for the company I am working with now. So I am fairly familiar with WIX.
We recently decided to have a Build server that auto builds our solution. It builds both debug, and release, as well as Obfuscated (and non obfuscated) projects.
And you really don't have to understand any of this. All you have to understand is that I have the same Wix project building different MSIs dynamically.
So the way we build them is we call MSBuild.exe with several parameters. Parameters the wix project depends on.
So let's say we go into command prompt and write
C:\>\windows\Microsoft.NET\Framework\v3.5\MSBuild.exe MyApp.Install\MyApp.Install.wixproj /p:Configuration=Release /p:SpecialPath=Obfuscated /t:Build
The idea is that wix sees the "SpecialPath" parameter being assigned "Obfuscated"; and in the installer paths its source to
..\myApp\bin\$(var.SpecialPath)\myApp.exe which translates to ..\myApp\bin\Obfuscated\myApp.exe when built.
TheQuestion
How do you create those custom build parameters and have them passed to my .wxs file. As of now with this setup, $(var.SpecialPath) is not defined and the build CrashSplosions.
For obvious legal reasons I had to cut 90% of the project.wxs file out and rename some stuff, but for all intents and purposes this is what I have.
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product Id="*" Name="myApp" Language="1033" Version="$(var.Version)" Manufacturer="myApp" UpgradeCode="$(var.UpgradeCode)">
<Package Id="*" InstallerVersion="200" Compressed="yes" />
<Media Id="1" Cabinet="media.cab" EmbedCab="yes" />
<Directory Id="TARGETDIR" Name="SourceDir" >
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLLOCATION" Name="myApp">
<Component Id="myAppEXE" Guid="FD5EBC02-MY29-GUID-ACCA-61324C5F1B68">
<RegistryKey Root="HKLM" Key="Software\MyApp">
<RegistryValue Value="0" Type="string" KeyPath="yes"/>
</RegistryKey>
<File Id="MYAPPEXE" Name='myApp.exe' Source="..\myApp\bin\$(var.SpecialPath)\myApp.exe" />
</Component>
<Component Id="EngineDLL" Guid="*">
<File Id="ENGINEDLL" Name='Engine.dll' Source="..\myApp\bin\$(var.Configuration)\Engine.dll" />
</Component>
<Component Id="CommonDLL" Guid="*">
<File Id="COMMONDLL" Name='Common.dll' Source="..\myApp\bin\$(var.Configuration)\Common.dll" />
</Component>
</Directory>
</Directory>
</Directory>
<Feature Id="ProductFeature" Title="myApp" Description='All' Display='expand' Level="1" ConfigurableDirectory='INSTALLLOCATION'>
<ComponentRef Id="myAppEXE" />
<ComponentRef Id="EngineDLL" />
<ComponentRef Id="CommonDLL" />
</Feature>
</Product>
</Wix>
The reason it's not working for you is that you are setting msbuild properties on the command line, which are not getting passed through as wix variables. MSBuild properties and wix variables are two different concepts.
One way to fix this is to ignore the concept of msbuild properties and use environment variables to pass values directly to candle.exe. You can use environment variables in your wxs file like this:
$(env.SpecialPath)
You can then launch your setup build from a batch file which prepares the necessary environment variables like this:
#echo off
setlocal
set SpecialPath=foo
set Configuration=Release
set msbuild=C:\windows\Microsoft.NET\Framework\v3.5\MSBuild.exe
%msbuild% test.wixproj /t:Build || goto ERROR
exit /b 0
:ERROR
echo Failed to build setup!
exit /b 1
Alternatively, if you prefer to pass parameters via msbuild properties, you should first take a look at the msbuild candle task documentation. It shows you can set values in your wixproj file like this:
<DefineConstants>Variable1=value1;Variable2=value2</DefineConstants>
This still requires you to hardcode values in the wixproj file though. If you want to pass the values as msbuild properties on the command line, then you should probably do something like this:
<DefineConstants>Variable1=$(value1);Variable2=$(value2)</DefineConstants>
and then pass /p:value1=foo /p:value2=bar on the command line, or define these msbuild properties elsewhere.
As already answered, you need to pass the variables into WiX. We use Nant instead of MSBuild, but the concept remains the same.
Here's a Nant example passing in half a dozen variables to candle (it's not the cleanest example, but is lifted verbatim from a project I worked on)
<candle out="${dir.obj}\"
rebuild="true"
extensions="WixUIExtension;WixNetFxExtension">
<defines>
<define name="ProcessorArchitecture" value="${release.platform}" />
<define name="SourceDir" value="${dir.source}" />
<define name="version" value="${version}" />
<define name="releasetype" value="${release.type}" />
<define name="Language" value="${language}" />
<define name="product" value="${string.product}" />
<define name="productedition" value="${release.productedition}" />
</defines>
<sources>
<include name="*.wxs" />
<include name="..\Common\*.wxs" />
</sources>
</candle>
<!-- Define fallback culture for non-US -->
<property name="cultures" value="${language}" />
<property name="cultures" value="${language};en-US" unless="${language == 'en-US'}" />
<light
out="${dir.build}\setup_${release.platform}_${release.compressionlevel}.msi"
extensions="WixUIExtension;WixNetFxExtension;WixUtilExtension"
cultures="${cultures}"
rebuild="true"
suppressices="ICE03;ICE82"
suppresspdb="true" >
<arg line="-loc "setup-${language}.wxl"" />
<arg line="-sw1101" />
<arg line="-b ${dir.resources}" />
<arg line="-b ${dir.resources.common}" />
<arg line="-b ${dir.resources.common}\Microsoft" />
<arg line="-b ${dir.source}" />
<arg line="-dcl:${release.compressionlevel}" />
<arg line="-dWixUILicenseRtf=EULA_${language}.rtf" />
<sources>
<include name="${dir.obj}\*.wixobj" />
</sources>
</light>
I had a similar situation where the source path of the files was to be passed as a command line argument to the build script. This is what I did:
Edited the wixproj file and added the following content under the "PropertyGroup" node:
<Source Condition=" '$(Source)' == '' ">R:</Source>
where R: is the default directory/path from where to pick the source.
Now, the source can also be passed as a command line argument during build:
msbuild /t:Clean,Build "MyPath\MyWixProject.wixproj" /property:Source=MyConfigurablePath /p:Configuration=Release