Par défaut, le fichier .wixproj contient le nécessaire pour définir le nom du msi à produire et son dossier de destination :

• OutputName permet de définir le nom du msi.
• OutputPath permet de définir le dossier de destination du msi.

Ceci convient à la plupart des personnes. Mais cela pose vite problème lors de l’automatisation de builds :

• Pour changer le nom du fichier en fonction de la version de l’application.
• Pour déposer automatiquement le msi dans un dossier de staging pour l’upload d’artefact dans Azure DevOps.

Les problèmes sont les suivants :

• Si OutputName est défini dans le fichier wixproj, l’argument passé à msbuild, n’est pas pris en compte.
• Si OutputPath va prendre la valeur de l’argument output passé à msbuild. Le msi se trouve alors perdu parmi les fichiers produits par les autres projets. Ceci n’est pas terrible, et pose d’autres problèmes dans le cas où vous souhaitez utiliser les taches Harvest de WIX.

Pour résoudre ces deux problèmes, j’ai pris l’habitude de :

• Ajouter une condition sur OutputName afin de ne fixer sa valeur que si celle-ci n’est pas déjà définie. Ce qui se produit quand on passe l’argument /p:OutputName à msbuild.
• Avoir deux nœuds OutputPath conditionnés par la présence de OutputPathMsi, et fixer leur valeur en fonction de celle-ci. Il suffit alors de passer l’argument /p:OutputPathMsi à msbuild pour définir le dossier de destination du msi à produire.

Ce qui donne par exemple :

<PropertyGroup>
  <OutputName Condition=" '$(OutputName)'=='' ">MonNomParDefaut</OutputName>
  <OutputPath Condition=" '$(OutputPathMsi)'=='' ">bin\$(Configuration)\</OutputPath>
  <OutputPath Condition=" '$(OutputPathMsi)'!='' ">$(OutputPathMsi)\</OutputPath>
</PropertyGroup>

Une fois ajouté à votre fichier wixproj, vous pouvez utiliser les arguments /p:OutputName="..." et /p:OutputPathMsi="..." avec msbuild.

WIX Toolset a beau être sympathique, il y a un travail qui est toujours un peu compliqué à réaliser. Il s’agit de l’automatisation de l’énumération des fichiers à installer, et la création du fichier wxs associé.

Par le passé, il était courant d’utiliser l’application Heat incluse dans le WIX Toolset. Celle-ci ne faisant plus partie de WIX 4, il faut apprendre à faire sans. Même si l'application unique WIX 4 permet de faire le même travail, cette approche n'est pas conseillée. Heureusement depuis déjà plusieurs années, il existe plusieurs tâches msbuild pour cela.

Ma préférence va à HarvestDirectory. Comme son nom l’indique, cette tâche va se charger de récupérer toutes les informations utiles à partir d’un dossier (liste de fichiers / dossiers, clé de registre pour l’enregistrement de composant COM, etc.). Le fichier wxs généré est déposé dans le dossier obj. Il est référencé par WIX lors de la build pour générer le fichier msi.

Mais si vous ne souhaitez pas transformer votre solution en usine à gaz (avec des scripts de partout, des chemins relatifs plus ou moins dynamiques, et des fichiers xml spécifiques pour msbuild, etc.), il convient de respecter quelques bonnes pratiques.

L’exemple qui suit vise à récupérer les fichiers d’une application web écrite en C#.

Le problème quand on utilise WinForms sur des PC modernes, c'est qu'il faut savoir s'adapter à des matériels modernes. L'un des problèmes qui reviennent le plus souvent est lié aux écrans à haut DPI. Le facteur de zoom appliqué à Windows est parfois mal géré par le couple Windows + WinForms. On peut avoir des comportements étranges :

• Une fenêtre / Form change de taille toute seule.
• Une fenêtre / Form semble avoir des contrôles plus gros qu'une autre.
• Le facteur de zoom ne semble pas être appliqué de la même manière sur tous les contrôles et toutes les fenêtres / Form.
• Plus tout un tas de problèmes qui impactent l'accessibilité.

Dans le cas où vous mixez WinForms et WPF, ces problèmes sont accentués.

Dans la plupart des cas, le problème se résout en ajoutant la ligne suivante à la méthode Main, ou avant l'affichage de la première fenêtre / Form.

Application.SetHighDpiMode(HighDpiMode.SystemAware);

Pour une application .net core récente, cette ligne n'est pas utile, car elle est appelée par la méthode:

ApplicationConfiguration.Initialize();

Si vous utilisez un vieux Framework .net, SetHighDpiMode ne sera peut-être pas disponible (ou efficace). Il faudra alors ajouter un fichier .manifest à votre application :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
   <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
      <security>
         <requestedPrivileges>
            <requestedExecutionLevel level="asInvoker" uiAccess="false"/>
         </requestedPrivileges>
      </security>
   </trustInfo>
   <asmv3:application>
      <asmv3:windowsSettings>
         <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">false</dpiAware>
      </asmv3:windowsSettings>
   </asmv3:application> 
</assembly>

Wix Toolset 4 arrive avec tout un lot de nouveauté destinée à nous simplifier la vie. C’est une version de rupture (dans le bon sens du terme). Nous ne perdons rien et gagnons beaucoup en simplicité de déploiement et d’usage :

• Le .net 3.5 frameworks n’est plus utile.
• Le déploiement se fait via nuget (il n’y a donc plus rien à installer sur le PC de développement, et les serveurs de build, ou à embarquer dans son repository).
• Le fichier de projet est au nouveau style SDK (fini les fichiers verbeux et le besoin de décharger/recharger les projets dans Visual Studio pour modifier une tâche msbuild).
• Plusieurs éléments du schéma XML propre à Wix ont été simplifiés (pas de panique, l’extension Visual Studio permet de faire la migration sans trop de difficultés).
• L’usage direct des tâches Heat est proscrit (les tâches Harvest sont préférables… HarvestProject fonctionne enfin !!!!).

Si vous utilisez l’extension de Visual Studio, ou msbuild seul, vous ne serez pas perturbés.

A contrario si vous utilisez les exécutables, il y aura un peu de travail. Ils ont tous été réunis en un seul outil.

Je crois qu’il n’est plus trop utile de présenter Wix Toolset, alias le couteau suisse de la génération de MSI ». Au cas où vous ne connaitriez pas celui-ic, voici un lien vers mon article « Pourquoi continuer de payer pour générer des MSI ? ».

Wix Toolset est disponible en version 3 depuis une petite éternité, et la version 4 tardait à arriver (la preview 0 date de mai 2021).

Mais les choses bougent :

• La preview 1 a été publiée en novembre 2022.
• Une nouvelle extension est disponible depuis novembre 2022.
• La RC1 a été publiée en décembre 2022.
• La RC2 est prévue pour le 20 janvier 2023.

La version finale ne devrait pas tarder. Il est prévu qu’elle arrive le plus tôt possible (tout dépendra de la qualité de la RC2 bugs).

Je détaillerai les nouveautés dans un second article ;)