Utiliser Visual Basic .net en 2022, cela semble peut-être un peu fou. Et pourtant, nous sommes encore nombreux à avoir besoin de maintenir des solutions .net écrites en VB.

Mais est-ce pour autant viable ? Les développeurs VB .net, sont-ils aussi bien lotis que les développeurs C# ?

Si vous utilisez Visual Studio 2022, je suis tenté de dire "peut-être bien que oui, peut-être bien que non".

Sur le papier, rien ne différencie l’expérience C# de l’espérance VB. Nous avons accès à la totalité de fonctionnalité d’édition, de parcours et de refactoring de code pour .net core et .net framework. Dans la pratique, il faudra distinguer deux cas de figure :

• Les nouveaux projets.
• Les projets migrés et/ou très anciens.

Les nouveaux projets

La création de nouveaux projets ne pose aucun problème. On peut mixer les projets C# et VB sans difficulté et ainsi profiter des avantages de l’un et de l’autre.

L’IntelliSense est au top et Code Analysis fait bien son travail. Côté tests, rien à signaler non plus. Même le très capricieux Live Unit Testing ne pose aucun problème.

Si une feature de Visual Studio devient dysfonctionnelle, il suffit d’analyser le changement que l’on a tenté d’opérer sur son code VB. Il y a de fortes chances que ceux-ci ne respectent pas les best practices (un problème de POO, un code non CLS compliant, ou toute autre dérive uniquement possible en VB …).

La maintenance ou la migration d’anciens projets

Si votre projet VB date un peu, il est probable que vous soyez un peu agacé par le comportement de Visual Studio 2022. Attention, ne vous focalisez pas sur l’édition 2022. Visual Studio 2019, et 2017 auront le même comportement.

L’IntelliSence peut parfois être aux fraises :

• Elle ne fournit pas d’aide à la saisie (le "." ne provoque pas d’affichage de la liste des propriétés ou méthodes).
• L’aide ne s’affiche pas sur certains types.
• Le raccourci F12 ne permet pas d’atteindre la définition de la classe, ou de la méthode sur laquelle se trouve le curseur.
• Etc.

Le refactoring fonctionne bien. Il y a cependant une exception : il est possible que la fonction "Remove and Sort Imports" retire des namespaces utiles. Dans ce cas, il faut se fier à la colorisation du code et supprimer manuellement les namespaces grisés.

Ne parlons pas de Live Unit Testing. Celui-ci a souvent des difficultés à charger des dépendances VB (une DLL est une DLL, allez comprendre). Si l'on souhaite l’utiliser, il est préférable de traduire ses projets de tests unitaires en C#.

Mais ces problèmes ne proviennent pas forcément de Visual Studio. Il y a fort à parier qu’ils soient liés à de trop anciennes pratiques (tirées de VB5 ou V6).

Les solutions

Pour anticiper ou résoudre les problèmes, les solutions se trouvent dans de bonnes vieilles recettes :

• Activer les options "strict" et "explicit" sur chaque projet VB.
• Configurer les autres options VB pour respecte les mêmes règles que C# (erreurs en cas de Function qui ne retourne pas de valeur, erreur en cas de LateBinding, erreur en cas d’accès à une propriété ou une méthode statique comme s’il s’agissait d'un membre d’une instance, initialiser une variable avant de l’utiliser, etc.).
• S’assurer que les éléments partagés entre C# et VB sont CLS compliant.
• Ne pas utiliser d’anciennes méthodes de VB5, ou VB6, et autres éléments intrinsèques à VB (IsNumeric, Val, IsNothing, My, … et le pire de tous : Collection).
• Faire attention au nommage des classes, respectez les bonnes pratiques habituelles (ne pas faire ce que vous ne pourriez ou ne feriez pas en C#). Exemple : En VB, si une classe porte le même nom que son Namespace, cela perturbe beaucoup l’IntelliSence.
• Résoudre l’intégralité des warnings obtenus lors de la compilation.
• Suivre les conseils de Code Analysis.

Pour rappel : les options VB .net sont accessibles via les propriétés du projet, sur l’onglet Build.

Si vous êtes dans le cas où la compilation se termine par un échec, mais n’affiche pas d’erreur, il s’agit d’un problème d’IntelliSence. Pour pouvoir voir les erreurs, il suffit de filtrer la liste d’erreurs via l’option "Build only".

Conclusion

Ce n’est un secret pour personne, je suis un fervent défenseur de VB .net. Cela ne m’empêche pas pour autant d’être réaliste concernant ce langage. VB .net n’a été introduit dans .net core que pour vous faciliter la migration.

Pour ne plus souffrir de problème lié à VB, il faut donc migrer progressivement son code vers C#. Je suis désolé. Cela me semble moins couteux à long terme que d’avoir à former des développeurs à VB .net.

Il faut beaucoup de temps, et de pratique pour éviter les innombrables pièges que VB cache derrière son apparente simplicité.

Pour rappel : Les versions 1, 2, 3.0 et 3.1 n’incluaient aucun support pour VB .net. Ce langage n’est utilisable avec .net core que depuis sa version 5.