Quand on débute avec WiX Toolset, l’une des actions les moins évidentes réside dans le référencement des fichiers à déployer. Pour cela, WiX dispose de toute une batterie de tâches MSBuild. L’une d’entre elles constitue le Saint Graal : HarvestProject.

Comme son nom l’indique, HarvestProject est destinée à récolter les informations relatives aux fichiers produits par un projet Visual Studio (je n’ai utilisé qu’avec .net et .net framework, je ne suis donc pas en mesure de confirmer le fonctionnent avec un projet C++).

La documentation donne un exemple où l’on mélange EnableProjectHarvesting, DoNotHarvest, et HarvestProject :

<Project Sdk="WixToolset.Sdk">
  <PropertyGroup>
    <EnableProjectHarvesting>true</EnableProjectHarvesting>
    <HarvestProjectsSuppressUniqueIds>true</HarvestProjectsSuppressUniqueIds>
  </PropertyGroup>

  <ItemGroup>
    <HarvestProject Include="..\MyProgram\MyProgram.csproj" ProjectOutputGroups="Binaries;Content;" />
  </ItemGroup>

  <!-- As soon as EnableProjectHarvesting set to true, Heat will try to Harvest all referenced projects. Notice the DoNotHarvest flag, this tells Heat not to do that. -->
  <ItemGroup>
    <ProjectReference Include="..\MyProgram\MyProgram.csproj" DoNotHarvest="true" />
  </ItemGroup>

  <ItemGroup>
    <PackageReference Include="WixToolset.Heat" />
  </ItemGroup>
</Project>

Le problème

La volonté de mélanger autant de notions dans un même exemple rend celui-ci très perturbant.

Honnêtement, même si l’on maitrise toutes les subtilités de cet exemple, il ne faut surtout pas oublier de lire l’avertissement qui précède HarvestProject :

Harvesting projects is disabled by default because it may not always work correctly. To enable it, set EnableProjectHarvesting to true in your project file.

Le "may not allways work correctly" est plutôt éloigné de la vérité. Cette tâche ne fonctionne pas du tout de la manière attendue. Avec la version RTM WiX 4, je me disais que les choses avaient peut-être changé. Il n’en est rien.

Le véritable problème d’HarvestProject est qui ne traite pas le dossier de "sortie" d’un projet, mais ses "sorties" (binaires, contenus, fichiers de debug,...). Chaque sortie étant basée sur les groupes de fichiers qui ne correspondent pas toujours à ce que l’on attend. Exemple : l’exe d’une application Blazor ne fait pas partie des binaires.

Autre élément perturbant, HarvestProject ne s’intéresse pas aux dépendances. Nombre de fichiers ne seront donc pas ajoutés à votre msi. Oubliez donc l’idée d’embarquer facilement .net 7 (les fichiers manquants ne seront pas liés à un problème de linker, mais bien à HarvestProject).

Conclusion

Vous l’aurez compris, HarvestProject est destiné à des utilisateurs très avertis. HarvestDirectory est préférable. Il n’y a qu’à lui indiquer le dossier bin d’un projet, et le tour est joué. Avec cette approche, on peut être certain que l'installation ne sera pas impactée par une quelconque mise à jour de Visual Studio, MSBuild, ou .net.