Retrouver facilement des compteurs de performances

La mise en place d’une démarche DevOps efficace passe toujours par l’utilisation d'outils de monitoring. Sur Windows, quelle que soit la solution retenue, celle-ci aura besoin de compteurs de performances (ou alors, le monitoring sera très limité).

La problématique

Pour ne pas être noyé dans la masse des métriques, il faut savoir identifier les compteurs utiles, et ceux qui sont disponibles sur les serveurs. Si Microsoft Learn fournit beaucoup d’information sur les compteurs de performances, il est toujours difficile de savoir ceux qui sont vraiment utilisables localement (et pourquoi certains outil ne trouvent pas certains compteurs).

Le cauchemar Fitbit by Google continue ?

Si vous développez des applications pour Fitbit OS, vous avez reçu ce soir un mail peu agréable. Fitbit y annonce la fermeture prochaine de son service Fitbit Studio. La fermeture se fera en deux étapes :

  • 20 mars 2023, le service passe en lecture seule.
  • 20 avril 2023, le service ferme définitivement ses portes.

Non, vous ne rêvez pas. Vous avez deux mois pour récupérer vos projets. Après il sera trop tard. C’est ce que nombre de personnes appellent la méthode Google. Je ne suis pas franchement fan.

Pour ceux qui ne connaitraient pas Fitbit Studio : il s’agit d’un site web permettant la création d’applications pour Fitbit OS. L’outil fournit tout le nécessaire pour créer, éditer, compiler de stocker ses projets.

Tout n’est pas encore perdu?

Bien évidemment, le développement d’application reste possible. Fitbit oriente les développeurs vers son SDK (utilisable avec VS code et node.js).

Pour les développeurs professionnels, la fermeture de Fitbit Studio est anecdotique. Elle arrive cependant dans un contexte peu encourageant :

  • Fitbit coupe des fonctionnalités de sa propre application (disparition des challenges entre amis).
  • Le dernier SDK date d’il y a un an et demi et n’apporte pas grand-chose.
  • Les dernières montres sous Fitbit OS datent d’il y a un peu plus d’un an et n’apportent pas de nouveautés.
  • Aucune mise à jour n’est apportée aux montres existantes.

La seule véritable nouveauté chez Fitbit depuis son acquisition par Google il y a deux ans, est une montre qui n’est compatible qu’avec Google. Celle-ci n'a pas convaincu la presse, et ne semble pas non plus avoir trouvé ses utilisateurs.

Conclusion

Autant dire que je ne suis pas confiant concernant l’avenir de Fitbit by Google. J’étais beaucoup plus fan de « Fitbit tout court », plus ouvert, plus dynamique, plus actif, et beaucoup plus prévenant envers ses développeurs, et utilisateurs.

La suite au prochain épisode. J’espère qu’il ne sera pas annonceur d’une nouvelle fermeture de service, ou de la fin d’un support.

Jérémy Jeanson

WIX : Fixer une variable, en fonction d'une règle métier

Parfois, on peut être amené à fixer une variable de WIX ToolSet en fonction des propriétés d'un fichier, ou toute autre règle métier.

Pour mon exemple, je vais fixer le numéro de version de mon msi à partir d'une information "dérivée" du numéro de version d'un exécutable. Au lieu de prendre l'habituel Major.Minor.Buil.Revision, je vais prendre Major.Minor.Revision.0 (oui, il y a des entreprises qui ont ce genre de demande un peu folle).

Pour cela, il faut modifier le fichier wixproj, et y ajouter une tâche BeforeBuild. Dans celle-ci, il y aura:

  • Une tâche GetAssemblyIdentity chargée de récupérer les informations de l'exécutable.
  • La sortie de GetAssemblyIdentity initialisera une variable $AppIdentity.
  • Une variable $AppVersion sera construite à partir des différents composants de $AppIdentity.
  • Une tâche DefineConstants se chargera de définir une variable WIX var.AppVersion à partir de $AppIdentity.

Ce qui donne :


<Target Name="BeforeBuild">
    <GetAssemblyIdentity AssemblyFiles="..\MonApp\bin\$(Configuration)\MonApp.exe">
      <Output TaskParameter="Assemblies" ItemName="AppIdentity" />
    </GetAssemblyIdentity>
    <PropertyGroup>
      <AppVersion>$([System.String]::Join('.', $([System.Version]::Parse(%(AppIdentity.Version)).Major), $([System.Version]::Parse(%(AppIdentity.Version)).Minor), $([System.Version]::Parse(%(AppIdentity.Version)).Revision), 0 ))</AppVersion>
      <DefineConstants>...;AppVersion=$(AppVersion)</DefineConstants>
    </PropertyGroup>  
 </Target>

L'utilisation est ensuite un jeu d'enfant :


<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
    <Product
        Id="*" 
        Name="MonApp"
        Language="1034"
        Version="$(var.AppVersion)"
        Manufacturer="..."
        UpgradeCode="...">

Jérémy Jeanson

Erreur Azure DevOps : “Some recent issues detected related to pipeline trigger.”

Si vous utilisez Azure Pipeline, il est possible que vous tombiez sur un message peu ragoutant :

Some recent issues detected related to pipeline trigger.

Celui-ci apparait au-dessus d'une build, qui malgré tout, s’exécute en respectant le trigger que vous avez fixé.

Si l’on click sur le bouton « View Details » qui suit le message d’erreur, on arrive sur le message :

Configuring the trigger failed, edit and save the pipeline again.

Vous avez beau modifié les triggers, rien n’y fait.

Mais pourquoi est-il aussi méchant?

La raison est toute simple :

  • Vous avez bien fait votre travail, et avez créé votre build sur une nouvelle branche.
  • Le message d’erreur concerne votre branche principale (main / master).
  • La définition de votre build n’a pas encore été mergée sur votre branche principale (main / master).

Conclusion

Quand vous effectuerez le merge de la branche contenant votre build sur votre branche principale, le message d’avertissement disputera.

Et voilà ;)

Jérémy Jeanson

WIX : Trouver et utiliser le numéro de version d'une application après un Harvest

Utiliser le numéro de version d'un exécutable ou d'une DLL avec WIX Toolset n'a rien de bien compliqué. Il suffit de référencer le fichier en lui donnant un Id (exemple: IdDuFichier). On peut ensuite utiliser la syntaxe !(bind.FileVersion.IdDuFichier).

Exemple : avec un fichier dont l'Id est MyApp.exe.


<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">  
  <Product 
    Id="*"
    Name="MyApp"       
    Language="1034"
    Version="!(bind.FileVersion.MyApp.exe)" 
    Manufacturer="..."
    UpgradeCode="...">
  …

Dans la plupart des cas, tout va bien. Mais si le fichier est référencé via une tâche d'Harvest, l'Id est imprévisible.

Heureusement, il existe un solution simple : utiliser un transformation XML au moment de l'Harvest.

Exemple, avec une tâche HarvestDirectory


<Target Name="BeforeBuild">
  <HarvestDirectory Include="$(WebAppDir)">
    <DirectoryRefId>INSTALLFOLDER</DirectoryRefId>
    <ComponentGroupName>MyApp</ComponentGroupName>
    <PreprocessorVariable>var.AppDir</PreprocessorVariable>
    <SuppressRootDirectory>true</SuppressRootDirectory>
    <SuppressCom>true</SuppressCom>
    <SuppressRegistry>true</SuppressRegistry>
    <Transforms>transformations.xslt</Transforms>
  </HarvestDirectory>
</Target>

Le fichier transformations.xslt est placé à la racine du projet WIX. Il contient le code suivant :


<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet
    version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"    
    xmlns:wix="http://schemas.microsoft.com/wix/2006/wi">

    <xsl:output method="xml" indent="yes" />

    <xsl:template match="@*|node()">
        <xsl:copy>
            <xsl:apply-templates select="@*|node()"/>
        </xsl:copy>
    </xsl:template>

    <!-- Suppression des pdb -->
    <xsl:key name="search-pdb" match="wix:Component[contains(wix:File/@Source,'.pdb')]" use="@Id"/>
    <xsl:template match="wix:Component[key('search-pdb',@Id)]|wix:ComponentRef[key('search-pdb',@Id)]"/>

    <!-- Renommage de l'id de l'application pour pourvoir la retrouver facilement et connaitre sa version -->
    <xsl:key name="search-app" match="wix:File[contains(@Source,'MyApp.exe')]" use="@Id"/>
    <xsl:template match="wix:File[key('search-app',@Id)]">
        <xsl:copy>
            <xsl:apply-templates select="@*"/>
            <xsl:attribute name="Id">MyApp.exe</xsl:attribute>
            <xsl:apply-templates select="node()"/>
        </xsl:copy>
    </xsl:template>
</xsl:stylesheet>

Ce fichier peut être modifié pour correspondre au besoin de chacun (changement de sélecteur, et Id affecté au fichier).

Jérémy Jeanson