Jérémy Jeanson's blog
chasseur de bugs depuis .net 1.0

Dans un précédent article, j'avais présenté la nouvelle manière de rendre accessibles les éléments internes d'un projet pour les tests unitaire. Aujourd'hui, je vous propose d'effectuer la même opération, avec un projet signé. L'approche est très similaire, il suffit d'ajouter l'attribut Key à InternalsVisibleTo. Seul petit problème, la documentation manque légèrement de détails sur la démarche à suivre (comment trouver la clé demandée, et comment la mettre en forme?).

Voici les étapes à suivre :

1. Signer le projet de test

À ce niveau, la documentation est très bien faite. Si l'on suit la méthode présentée ici, Visual Studio ajoute des nœuds similaires à ceux-ci au projet de tests:

<SignAssembly>True</SignAssembly>
<AssemblyOriginatorKeyFile>..\strong-name-key.snk</AssemblyOriginatorKeyFile>

Note : Une bonne habitude pour se simplifier la vie consiste à réutiliser le même fichier snk pour signer l'ensemble des projets. Un seul fichier signifie qu'il n'y a qu'une seule clé à utiliser pour la totalité des projets. Ainsi, il est plus facile de s'y retrouver, et l'opération qui suit n'a besoin d'être effectuée une seule foi.

2. Obtenir le hash de la clé publique

Après compilation du projet de tests, on peut demander à Visual Studio d'afficher la totalité des fichiers. Il suffit alors de dérouler l'arborescence jusqu'aux dossiers de destination des binaires du projet de tests. Ensuite, un simple click droit sur le répertoire permet d'afficher le menu contextuel suivant. Il reste alors à choisir Open in Terminal.

Via le terminal intégré à Visual Studio, il ne reste plus qu'à utiliser la commande sn en lui fournissant le nom de l'assembly produit par le projet de tests unitaires.

PS C:\xxx\bin\x64\Debug\net8.0> sn -Tp .\MonProjet.Tests.dll
Microsoft (R) .NET Framework Strong Name Utility Version 4.0.30319.0
Copyright (c) Microsoft Corporation. All rights reserved.
Public key (hash algorithm: sha1):
xxx1
xxx2
xxx3
xxx4
xxx5
Public key token is yyy

La clé qui nous intéresse se trouve derrière Public key (hash algorithm: sha1).

3. Utiliser le hash de la clé publique

La clé récupérée via la précédente étape peut alors être utilisée pour renseigner l'attribut Key de InternalVisibleTo qui se trouve dans le projet à tester. La clé doit être retranscrite sans saut de ligne.

<ItemGroup>
<InternalsVisibleTo Include="$(AssemblyName).Tests" Key="xxx1xxx2xxx3xxx4xxx5" />
</ItemGroup>

Conclusion

Simple, et efficace. Par contre, il ne s'agit pas du genre d'opération que l'on a envie de faire chaque matin. D'où mon précédent conseil d'utiliser le même fichier snk pour signer l'ensemble des projets d'une même solution.

La migration vers .net 8 et Blazor Web App passe par la suppression des Tag Helpers d’ASP .net. De ce fait, le Tag asp-append-version n’est plus utilisable.

Il existe bien évidement des solutions pour réintroduire celui-ci. Mais veut-on réintroduire des méthodes qui n’ont pas vocation à fonctionner avec Blazor. Personnellement, ma réponse est non.

Le travail effectué par asp-append-version est très simple. Il consiste à ajouter à l’URL du fichier le hash de ce même fichier. De ce fait, l’URL du fichier change après chaque modification du fichier. Ceci force le navigateur à télécharger le fichier, et permet d’éviter les problèmes de mise en cache de ces fichiers.

En soi, rien de bien compliqué. On peut donc créer une méthode qui se chargera de retourner une URL incluant le hash du fichier.

Mais avec Blazor, la plupart des fichiers sont gérés automatiquement par le framework. Nous avons donc très peu de fichiers ajoutés manuellement, et devant avoir besoin de asp-append-version. Le besoin étant plus limité, il est donc possible de faire encore plus simple.

Si l’utilisateur télécharge un ou deux fichiers js / css après chaque mise à jour, ce n’est pas grave. On peut donc s’appuyer sur le hash de l’application pour générer nos URL.

Ce qui est possible avec un code aussi simple que celui-ci :

<link href="css/common.css@(AppendHashCode)" rel="stylesheet" />
<script src="js/common.js@(AppendHashCode)"></script>

@code{
    private String AppendHashCode = "?v=" + System.Reflection.Assembly.GetExecutingAssembly().GetHashCode();
}

Simple, efficace, et sans réinventer la roue.

Vous venez de coder l’action cutom du siècle avec C#, et wix toolset. Seulement, vous savez qu’il y a un cas qui provoquera une erreur bloquant le déploiement. Dans une telle situation, il serait bon d’afficher une boite de dialogue dérivant le problème rencontré.

Ne cherchez pas à utiliser une méthode tirée de WinForm, WPF, ou une autre solution tirée de Win32. Cela ne fonctionnera pas comme vous le désirez.

À la place, il convient d’utiliser les méthodes fournies par l’objet Session. Celui-ci dispose d’une méthode Message qui permet d’envoyer à msiexec les informations à afficher.

Voici un petit exemple :

public static void MessageError(Session session, String message)
{
   session.Message(InstallMessage.Error, new Record { FormatString = message });
}

Simple et efficace. Malheureusement cela n’est pas bien documenté du côté de wix toolset :(

Quand on utilise Git, il arrive qu’un collègue fasse une petite bourde en fusionnant deux branches (du style : annulation des modifications d’un autre collègue, ou suppression de fichiers).

Via Azure DevOps, on ne voit pas que des Commits ont été annulés. Ils sont bien présents dans la branche de destination. Mais si on regarde l’historique d’un fichier impacté par un de nos Commits via Visual Studio, ou Azure DevOps, le commit n’est pas visible. Bien évidemment le fichier résultant n’est pas bon.

Heureusement, il existe une petite commande qui peut vous sauver :

git log --full-history -1 -- .\chemin-vers-un-fichier.cs

Par rapport à VS et DevOps, cette commande l’avantage est que d'afficher le commit de fusion qui a annulé vos modifications. De plus, cette commande est utilisable pour identifier un Commit qui a supprimé un fichier par erreur.

À partir de ce Commit, on peut retrouver la date de la fusion. Via Azure DevOps, il suffit alors d’aller consulter la liste des Push pour avoir une idée plus claire des problèmes posés par cette fusion et établir un plan d’action.

Désolé pour le silence de ces dernières semaines. La fin d’année a été plutôt compliquée pour moi, et il m’a fallu quelques semaines pour reprendre ma plume.

Je profite de ce post pour vous souhaiter une bonne année 2024, et de beaux projets. Mais aussi la chance d’avoir quelques problèmes techniques à résoudre (juste ce qu’il faut pour progresser).

De mon côté, je reprends mon rythme d’articles hebdomadaire. Pour 2024, je conserve le format d’articles courts qui semble avoir été beaucoup apprécié l’an dernier. Bien évidemment, je rédigerai quelques articles plus longs, avec plusieurs solutions, et arguments. Je privilégierai ce format pour répondra aux questions qui me sont posées hors-ligne, et fournir des retours d’expérience (cela m’a beaucoup été demandé). Vous voyez, je vous écoute ;).

J’en profite pour remercier toutes les personnes qui m’ont contacté via mail, ou LinkedIn en 2023, pour échanger sur .net, et DevOps. J’ai encore un peu de retards, mais je répondrai à tout le monde.