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

Pour les amoureux des nouvelles technologies, ou du développement, il y a de quoi s'émerveiller tous les ans. Quelle que soit la technologie choisie, il y a de quoi s'amuser. Même s’il est vrai que certains, comme les développeurs .net, sont un  peu mieux lotis (Web, mobiles, tablettes, consoles, Windows, Linux, …)

Le jour où vous choisissez de partager vos connaissances, vous vous éclatez encore un peu plus. Certes, cela demande davantage de travail, et vous expose aux avis des autres développeurs. Mais cela en vaut la peine.

Petit effet de bord imprévu : Plus vous arrivez à intéresser d'autres développeurs, plus vous échangez, et plus vous gagnez en connaissance, et compétences.

En fin d'année 2023, j'ai publié un retour d'expérience sur dependency-check et son intégration dans Azure DevOps. À l'époque, je ne recommandais pas l'outil pour les développeurs .net. Depuis, les choses ont changé.

Mon article m'a permis d'avoir des retours d'utilisateurs Java.

Petite pause : Oui, dans ce monde de brutes, les développeurs Java, et .net, peuvent échanger sans en venir aux mains.

À ma grande surprise, ceux-ci partageaient le même avis que moi. Je les trouvais même plus critiques (si, c'est possible). Ils mettaient en avant le trop grand nombre de faux positifs. Situation que je commençais aussi à rencontrer.

Régulièrement, on me dit que je ne suis pas assez critique vis-à-vis de .net. Je suis désolé de contrarier les personnes qui pensent de la sorte. Depuis que j'utilise .net, je ne l'ai jamais regretté. Nous avons là un ensemble de solutions qui évoluent dans le temps pour nous offrir toujours plus de facilité, de productivité, avec un très beau niveau de performance.

Cependant, il existe une méthode qui fait tache dans ce beau tableau :

Path.GetDirectoryName(path);

Cette méthode est un véritable piège.

Comme indiqué dans la documentation, l'appel à Path.GetDirectoryName("C:\MyDir\MySubDir") retourne "C:\MyDir". Il faut un "\" en fin de string pour que la méthode retourne "C:\MyDir\MySubDir".

Concrètement, cette méthode n'est intéressante que pour obtenir le Path vers le répertoire d'un fichier. Que ce soit le nom de la méthode, ou le nom de son argument, tout est trompeur.

Pour vérifier le nom d'un répertoire, j'ai pris l'habitude d'utiliser (on pensera à effectuer un Trim() sur le path pour éviter les problèmes)

var name = new DirectoryInfo(path).Name;

C'est un peu dommage, mais c'est ainsi.

Suite à la montée de version de Gulp4 vers Gulp 5, vous avez peut-être rencontré un problème avec vos polices de caractères. Ceci est lié à une évolution majeure : Gulp 5 produit par défaut des sorties encodées en UTF-8. Toutes les Streams sont donc maintenant encodées pour s'assurer de ne produire que des fichiers en UTF-8. Ce qui peut avoir un effet des effets de bord sur les polices de caractères.

Ceci est décrit ici.

Pour résoudre le problème, il suffit donc d'indiquer à Gulp de ne pas toucher à l'encodage des fichiers.

Exemple avec une méthode chargée de copier des fonts :

function copyFonts() {
  return src([
    "./_www/fonts/*",
    "./node_modules/@fortawesome/fontawesome-free/webfonts/*"],
    {
      encoding: false
    })
    .pipe(dest("./wwwroot/fonts/"));
}

Peut-être avez-vous déjà été confronté à un bandeau présent dans la parti haute de Visual Studio, et affichant le message :

Current solution contains incorrect configurations mappings. It may cause projects to no work correctly. Open Configuration Manager to fix them.

Si tout se passe bien, le projet concerné est mis en évidence par un pictogramme d'avertissement affiché devant le nom du projet :

Dans le cas où vous ne disposez que de projets .net aux anciens formats :

• le message ne sera pas visible.
• le projet à problèmes ne sera pas mis en évidence.
• lors de la compilation msbuild devrait remonter un message impliquant un problème de mapping.

Quel est le problème?

L'erreur remontée ici par Visual Studio concerne la gestion des configurations, et plateformes. Un ou plusieurs projets sont mal configurés. Le lien entre les configurations des projets, et celles de la solution ne se fait pas.

De ce fait, il est possible que certains projets ne soient pas compilés avec la configuration, et la plateforme courante.

Comment s'en sortir ?

Si vous suivez les indications, vous n'irez pas loin. Vous vous retrouverez la boite de dialogue configuration manager, et ensuite ?

Pas de panique, je suis là pour vous accompagner. Je vais vous présenter une approche qui fonctionne dans 100% des cas. Celle-ci tient en quatre étapes :

• Supprimer facilement les configurations en trop.
• Supprimer facilement les plateformes en trop.
• Rectifier les projets.
• Rectifier la solution.

Par habitude, on garde souvent de très nombreuses plateformes alors que l'on n'en compile toujours qu'une. Personnellement, j'ai pris l'habitude inverse : ne garder qu'un profile.

Dans le cas présent, je vous propose d'opter pour la stratégie suivante :

• Ne conserver que les configurations Debug et Release.
• Ne conserver que le profile Any CPU au niveau de la solution
• Seuls les exécutables cibleront x86 ou x64 (site web, consoles .. Etc)

De la sorte aucun développeur ne s'emmêlera les pinceaux avec les profils. L'erreur de mapping sera d'autant plus facile à résoudre.

Supprimer facilement les configurations en trop

Commençons donc par utiliser Configuration Manager pour faire le ménage. Pour rappel, celui-ci se cache dans le menu Configuration.

À partir de l'écran Configuration Manager, il convient d'ouvrir la liste déroulante des Configurations, et de sélectionner "Edit".

Ceci permet d'afficher la boite de dialogue dédiée à la gestion des configurations. Avant de toucher à quoi que ce soit, il faut cocher la case "Remove deleted configuration from all projects where it is unused". Ensuite on peut supprimer les configurations qui n'ont plus d'intérêt.

Supprimer facilement les plateformes en trop.

Après validation de la liste des configurations, on peut maintenant s'occuper des environnements. Cela passe à nouveau par la boite de dialogue Configuration Manager. Cette fois si, il faut choisir l'option Edit présente en fin de liste des plateformes.

Ici aussi, avant de faire quoi que ce soit, il faut penser à cocher l'option "Remove deleted platforms from all projects where it is unused". On peut ensuite supprimer les plateformes qui ne seraient pas utiles.

En peu enfin fermer Configuration Manager, et enregistrer les fichiers modifiés par Visual Studio. Il peut y avoir quelques projets, en plus du fichier de la solution.

Rectifier les projets

On peut maintenant s'attaquer aux projets. L'idée ici, est de limiter ceux-ci au strict minimum. On en profite donc pour ne garder que là où les plateformes utiles (AnyCPU, x86, x64…).

Exemple pour un projet qui n'est compilé qu'en 64 bits, je limite la liste des profiles :

<Platforms>x64</Platforms>
<Platform>x64</Platform>

Rectifier la solution

Pour finir, il ne nous reste plus qu'à nettoyer la solution. Pour cela, il vous faudra ouvrir le fichier sln avec l'éditeur de votre choix.

Pour commencer, il faut trouver l'id du projet en défaut. Celui-ci se trouve en début de fichier, en toute fin de ligne.

Exemple pour un projet portant le nom MonProjet, l'id est {A3307DAA-4B1F-4D05-B465-9F82DB3D0034}.

Project("{.....}") = "MonProjet", "Mondossier\MonProjet.csproj", "{A3307DAA-4B1F-4D05-B465-9F82DB3D0034}"
EndProject

Cet id devrait se retrouver sur quatre lignes similaires à ceci :

{A3307DAA-4B1F-4D05-B465-9F82DB3D0034}.Debug|Any CPU.ActiveCfg = Debug|x86
{A3307DAA-4B1F-4D05-B465-9F82DB3D0034}.Debug|Any CPU.Build.0 = Debug|x86
{A3307DAA-4B1F-4D05-B465-9F82DB3D0034}.Release|Any CPU.ActiveCfg = Release|x86
{A3307DAA-4B1F-4D05-B465-9F82DB3D0034}.Release|Any CPU.Build.0 = Release|x86

S’il y a plus de lignes, ce n'est pas normal. Il doit y avoir deux lignes par configuration. L'une indique la configuration à activer, l'autre la configuration à utiliser s’il faut compiler le projet (si le projet n'est pas compilé, la ligne xxx.Build.0 est donc absente).

Dans le cadre de mon exemple, le nombre de lignes est bon. Par contre, lors de la compilation ciblant Any CPU, le sln cherche à utiliser une plateforme x86 qui n'existe pas dans le projet. Pour corriger le fichier sln, il suffit donc d'indique la plateforme x64.

{...}.Debug|Any CPU.ActiveCfg = Debug|x64
{...}.Debug|Any CPU.Build.0 = Debug|x64
{...}.Release|Any CPU.ActiveCfg = Release|x64
{...}.Release|Any CPU.Build.0 = Release|x64

Et voilà.