HeatWave does not include All output files from the referenced project, only the file source

[Antelope-IT]

HeatWave Version

1.0.4.5

Visual Studio Version

17.13.2

Repro Steps

1. Follow the WixToolset Tutorial paying attention to Sprint 2 Step: Replace the placeholder component.
2. Continue to Sprint 3 Step: Installing the app (if you dare) you need to dare.

Actual Result

The output from the App project in bin\debug includes an app.exe.config file as well as a .pdb file. Neither file is included in the msi and neither is installed alongside the App.exe as expected.

This would seem contrary to what you might expect from the tutorial documentation:

"The WiX MSBuild targets, while not themselves sentient, reflect the thoughts of the WiX developers, including the thought that it should be simple to package the files from referenced projects. It does so by generating bind paths for the output of every referenced project. Bind paths are paths that WiX searches for files being packaged. Because the bind path includes the directory, all we need to do is reference the file name itself:"

I would infer from this that because I've referenced the App.exe file WiX will locate the directory where this file is output to, create a bind path for it and then use that bind path as a location to search for other files and directories to include in the package.

I first noticed this problem in my own project that I'm trying to package - the main referenced file is packaged but none of the supporting dll's or directories are packaged. I then went back to Tutorial to find my mistake but at the moment I'm at a loss to see what I've missed as both projects are exhibiting the same behaviour. The App from the tutorial installs and works but probably because it doesn't need the app.exe.config my production app doesn't because it needs the supporting dlls to work.

One additional step that's not in the Tutorial, is that I followed the workround for MSB4057 and added the following to the wixproj files of my tutorial solution and my production solution.

<Target Name="CollectSuggestedVisualStudioComponentIds" />

The instructions aren't exact but you I don't think you can go too wrong with the bottom of the file as if you get it wrong then you get errors and the project will not load.

Expected Result

I would expect to see the entire contents of the directory containing the referenced File source, packaged into the msi and installed by the MSI. Not just the single referenced file.

[Antelope-IT]

As a result of further of investigation I have found either a work around or perhaps the way it is meant to work but not explained by the documentation.

Taking the WixTutorial as an example in the AppComponents.wxs you start with the following

<Wix xmlns="http://wixtoolset.org/schemas/v4/wxs">
	<Fragment>
		<ComponentGroup Id="AppComponents" Directory="INSTALLFOLDER">
			<Component>
				<File Source="App.exe" />
			</Component>
		</ComponentGroup>
	</Fragment>
</Wix>

As the documentation suggests HeatWave/Wix creates a bindpath for the File source directory the problem being that you don't know what that bindpath is named if it is named at all (the documentation doesn't tell us). This makes it harder to use the methods in the Wix 4 to 5 documentation, suggested in the File Harvesting (New Language Features) section.

While the Files element suggests a possible solution, relying on an unnamed bindpath is unlikely to work because of this issue Unnamed bindpaths not respected. If I've read the thread correctly the fix for this isn't due until Wix v6 so a month or so away.

Fortunately msbuild logs have the answer. Digging through the build logs appears to show that Wix creates two bindpaths for each project reference; one unnamed and one named. It derives the name for the bindpath not from the File.Source attribute value as I originally thought but from the project name in the Wix project project references. The reason why I originally thought it was taken from the File.Source attribute value because they matched simply because my project file output had the same name as the project itself. When I changed the project name of the installable project the bindpath name changed to match and broke the build.

So to clarify if you have a File element of the style:

<File Source="App.exe" />

Which is created by a project called "TutorialApp" and the WixprojFile.wixproj looks like this:

<Project Sdk="WixToolset.Sdk/5.0.2">
  <ItemGroup>
    <ProjectReference Include="..\App\TutorialApp.csproj" />
  </ItemGroup>
  <Target Name="CollectSuggestedVisualStudioComponentIds" />
</Project>

Then the bindpath will be created with the name TutorialApp and can be used like this:

!(bindpath.TutorialApp)

This allows us to do something like this:

<Wix xmlns="http://wixtoolset.org/schemas/v4/wxs">
	<Fragment>
		<ComponentGroup Id="AppComponents" Directory="INSTALLFOLDER">
			<Component>
				<File Source="App.exe" />
			</Component>
			<Files Include="!(bindpath.TutorialApp)\**">
				<Exclude Files="!(bindpath.TutorialApp)\App.exe"></Exclude>
			</Files>
		</ComponentGroup>
	</Fragment>
</Wix>

For brevity I've added the Files element to the same ComponentGroup as the Component>File element. I would assume that you could indeed nest it in any allowed parent element and install the harvested files in a different directory and as part of a different feature even.

This arrangement suits my needs though, in that it demonstrates the code necessary to make it work and I want to install all the "included" files in the directory alongside the App.exe file.

The Exclude element appears to be necessary to avoid duplicating the App.exe file, but it also allows for the exclusion of other files; using the same technique in my production project results in runtimes being included that don't match the target architecture so the next thing to do is to work out how to include all the files needed but exclude the files that don't match the target architecture runtime files.

The named bindpaths that are created afford the possibility of having multiple named bindpaths and being able to include files from the directory of each. So if the Wix project had multiple features dependant on multiple project outputs its seems possible that you could have multiple named bindpath making it easier to control and see which files are included for each component/feature. If you relied on unnamed bindpaths I'm not sure how you would ensure that the files that were harvested came from the right bindpath (just thinking out loud).