Après quelques mois de test, et 4 Release Candidates, WIX Toolset sort enfin en version 4.0.0. Le projet a pris un peu de retard. Mais c’était pour la bonne cause. Cette version 4.0.0 était très attendue. Il était donc hors de question que sa sortie soit entachée par des bugs.

Pour rappel, la version 4 apporte des modifications majeures suivantes :

• Les projets WIX utilisent le nouveau format de projet de type SDK de .net core.
• Le toolkit s’installe via nuget.
• Le toolkit ne dépend plus du .net Framework 3.5.

Inutile de vous faire un dessin de la totalité des nouveautés. Si vous avez déjà utilisé WIX 3, les avantages sautent aux yeux :

• Les actions post-build sont beaucoup plus faciles à configurer.
• L’automatisation des builds, et la gestion des serveurs de build sont beaucoup plus faciles.

Ce toolkit n’aura jamais été aussi facile à mettre en œuvre pour générer des fichiers MSI.

En temps normal, un fichier de configuration pour Linux doit se trouver dans un dossier /etc/monapplication. Ce que peu de développeurs .net font. Si vous souhaitez respecter les habitudes de vos gentils administrateurs système, il faut utiliser ce dossier.

Avec Windows, le fichier de configuration se trouve généralement à la racine de l'application.

Concilier les deux est possible et ne demande aucun effort. Nul besoin de s'arracher les cheveux ni d'ajouter un code détectant l'OS. Il suffit de profiter des possibilités offertes par le ConfigurationBuilder, et la méthode AddJsonFile :

• On effectue un appel de AddJsonFile pour chaque chemin possible.
• On indique que chaque fichier de configuration est optionnel.

Voici un exemple d'application Console :

using Microsoft.Extensions.Configuration;

namespace ConsoleApp1
{
  internal class Program
  {
    static void Main(string[] args)
    {
      var configuration = new ConfigurationBuilder()
        .AddJsonFile("appsettings.json", true)
        .AddJsonFile("/etc/monapplication/appsettings.json", true)
        .Build();
 
        var message = configuration.GetValue<String>("message");
 
        Console.WriteLine(message);
      }
  }
}

Avec le fichier de configuration appsettings.json:

{
  "message": "Coucou"
}

Au final :

• S’il y a un fichier de configuration dans "/etc/monapplication", celui-ci sera utilisé (même s’il y en a un à la racine de l'application). Les dernières informations trouvées remplaçant les informations trouvées précédemment.
• Sur Windows, le fichier de configuration utilisé sera celui qui se trouve à la racine de l'application.

Ce code est exploitable dès qu'une application utilise l'hôte générique destiné à l'injection de dépendances.

Suite à l’un de mes articles sur Azure DevOps Server, il m’a été demandé de faire le point sur les notions d’Update et de Patch. Si vous gérez ou souhaitez héberger votre propre ferme Azure DevOps, il est effectivement impératif de comprendre ces deux notions, et leur impact sur votre plateforme.

Pour être clair sur ce sujet, il faut comprendre ce dont on parle et fixer trois notions :

• - Version majeure : 2019, 2020, ou 2019
• - Update : 2020 Update 1.1, 2002 Update 1.2, ou 2029 Update 1.2
• - Patch : 2022 Patch 1, 2022 Patch 2, ou 2020 Update 1.2 Patch 5.

Note : j’ai volontairement retiré le préfix Azure DevOps Server, afin d’être moins "verbeux".

Les différentes évolutions d’Azure Pipeline ont amené beaucoup de bonnes choses. Dont une belle simplification de la gestion des stratégies de rétention des builds. Mais ceci est arrivé avec un petit effet de bord : des pipelines qui ne disposaient pas d’une stratégie de rétention voient leurs exécutions affublées d’un bail "Legacy Retention Model".

La problématique

Le bail "Legacy Retention Model" interdit la suppression des exécutions.

Aucune stratégie n’étant définie avant l’évolution de cette fonctionnalité, Microsoft ne peut pas prendre la décision de supprimer des exécutions à notre place. La démarche est donc logique.

Pour pourvoir supprimer les excitions concernées, il faut donc retirer les baux. Cette opération peut être fastidieuse si vos avez beaucoup de pipelines, projets, ou organisation / collections.

Voici une information qui fait rire un peu jaune dans le petit monde « on-premise ». À la sortie de Visual Studio 2022, il y avait un petit problème de support par Azure DevOps Server. Les pipelines ne permettaient pas d’utiliser les build tools de Visual Studio 2022 simplement. Il y a un an, je publiais un article expliquant une méthode de contournement simple (disponible ici). Par la même occasion, je déconseillais de tenter d’installer des tâches customisées. J’espérais alors que celle-ci arrive rapidement via une mise à jour.

Uptate 2022 ou Patch?

La sortie d’Azure DevOps 2022 en décembre dernier refaisait vivre cet espoir. Pourtant, le support tant espéré n’était pas de la partie.

Surprise, surprise ! Le patch de février ajoute les tâches MSBuild et VSBuild détectant automatiquement VS 2022. Il s’agit là d’une grosse surprise. Il n’est pas habituel que Microsoft ajoute de nouvelles fonctionnalités via un Patch. Cela a généralement lieu lors d’une Update. Il y a fort à parier que l’équipe Azure DevOps ait considéré l’absence de ces taches comme étant une erreur.

Il n’est pas fait état des tâches de tests. J’espère qu’elles sont mises à jour par la même occasion. Je vérifierai dans les prochains jours si ce n’est pas le cas.

Conclusion

Maintenant, on peut considérer que le support de VS 2022 est équivalent pour les versions Cloud et On-premise d’Azure DevOps. La nouvelle est rassurante, car il n’était pas courant que Microsoft prenne autant de temps pour rendre iso les deux versions.