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

Cela fait déjà une paire de fois que l'on me dit que winget ne permet d'installer, et de maintenir à jours node.js en version LTS. Vu que cela n'est pas vrai, je vais vous expliquer ici une manière de procéder.

Pour commencer, avant toute installation, j'ai l'habitude de procéder à une petite recherche via winget.

winget search node.js

Cette commande retourne une liste d'applications.

Nom           ID                Version Correspondance Source
-------------------------------------------------------------
Node.js       OpenJS.NodeJS     22.9.0                 winget
Nodist        Nodist.Nodist     0.10.3  Tag: node.js   winget
Volta         Volta.Volta       2.0.1   Tag: node.js   winget
Node.js (LTS) OpenJS.NodeJS.LTS 20.17.0                winget

Dans cette liste, on trouve Node.js (LTS) et son ID OpenJS.NodeJS.LTS. Il suffit alors d'utiliser cet ID de la manière qui suit.

winget install OpenJS.NodeJS.LTS

Et pour la mise à jour

winget update OpenJS.NodeJS.LTS

Simple, efficace, et reproductible avec tout type d'application.

Suite à plusieurs demandes, j'ai mis à jour mon extension BenchmarkDotNet pour Visual Studio. Désolé pour le retard.

Cette extension a vocation à simplifier la création de projets de benchmarks, l'ajout de benchmarks, et leur exécution.

Si cela vous intéresse, l'extension est disponible via le Markateplace.

Bien évidemment, son code est accessible via GitHub.

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.