Oui, en 2021 on peut toujours utiliser le dernier Visual Studio pour développer avec Workflow Foundation et WCF.

Pour .net Framework

Si vous avez à maintenir des projets .net Framework, l’expérience est complète rien ne manque. Il n’y aura qu’un petit bémol avec WF : le gestionnaire de propriétés des activités ne supporte pas le copier-coller. Visual Studio semble utiliser le rehosting de designer de WF 4.5.

Pour .net core

Si vous utilisez .net 5 (ou une version précédente de .net core), l’outillage se limite évidemment à la création de clients pour WCF.

Pour Team Build / Builds XAML

Si vous devez gérer des builds XAML, il n’y a pas de problèmes pour éditer ou créer de nouveaux Workflows. Il n’y a qu’une seule limitation. Il n’est pas possible d’association une nouvelle build avec un nouveau Workflow versionné via TFVC (avec Git pas de problèmes). Il est préférable de garder sous le coude, le Visual Studio associé à votre version de TFS.

Pour installer les outils

Comme toujours avec VS 2019 pour installer ces fonctionnalités, il suffit de lancer VS Installer. Via l’onglet Composant individuel on peut rechercher Foundation, cocher WF et WCF puis lancer l’installation.

Dans le contexte du développement logiciel, il a nombre de sujets qui ne sont pas toujours populaires. Pour cet article, j’ai décidé d’associer deux d’entre eux :

• Les tests unitaires : dont tout le monde ne voit pas toujours l’intérêt
• Le risque à ne pas faire : une notion que l’on rencontre en gestion de projet. Souvent elle n’est pas très renseignée et se concluent en quelques mots « perte de clients » ou « perte de profits » .

Imaginons que l’on doive conduire un projet dont l’objectif et la mise en place de tests unitaires.

Il existe aujourd’hui beaucoup de très bons articles expliquant l’intérêt de coder des tests unitaires. Si vous deviez n’en lire qu’un seul, je vous recommanderais vivement le récent article de Patrick Smacchia.

Face à autant de contenu de bonne qualité, je ne pensais pas avoir un jour à écrire un article sur le sujet. Mais finalement je me rends compte qu’il faut écrire en français pour lutter contre la fameuse coutume bien de chez nous du « moi, c’est différent », ou « on a tenté, ça n’a jamais marché », ou encore « c’est plus pas pareil que c’est différent… donc on ne peut pas ».

Cet article va donc faire partie d’une petite série d’articles courts.

La question du jour

Pourquoi je continue à coder des tests unitaires ?

Ma réponse simple (pour une foi)

Après 20 ans avec .net, je ne sais plus coder sans tests unitaires. J’ai des applications des mes débuts que je ne pourrai pas maintenir sans.

J’espère que cela en fera réfléchir. Dans le prochain article sur les tests unitaires, j’attaquerais le fameux « risque à ne pas faire » que l’on aime beaucoup évoquer en gestion de projet. Mais pour lequel on ne sait jamais vraiment quoi dire.

Depuis quelques semaines, je suis amené à utiliser Locust. Il s’agit d’un outil destiné à effectuer des tests de monter en charge, stress tests ou des tests de performance.

Comme beaucoup de solutions open source, Locust repose sur l’usage d’une interface en ligne de commandes, de scripts et fichiers de configuration. Bien entendu, avant de pouvoir jouer avec tout cela il faut préparer son environnement de travail (installer Python, Locust, …).

La courbe d’apprentissage relative à cet outil est plutôt rapide, mais il y a là de nombreuses tâches rébarbatives et d’autres que l’on ne fait qu’une foi, mais qu’il faudra savoir communiquer à ses collègues pour qu’ils arrivent à les reproduire.

Comme pour C#, Microsoft a annoncé une nouvelle version de Visual Basic pour .net 5. Il s’agit de VB 16. Mais quelles sont les nouveautés ?

Malheureusement, il n’y en a pas. VB 16 n’apporte rien de nouveau à Visual Basic. VB 16 a été créé combler le manque de support de Visual Basic dans .net Core 3.1.

Microsoft n’a pas présenté de roadmap pour VB. Une légère allusion au futur de VB a été ajoutée à la documentation. Les informations fournies ne sont pas rassurantes :

• De nombreuses fonctionnalités du runtime VB dépendent de WinForm.
• Celles-ci feront leur apparition lors d’une prochaine itération de VB .net.

Si l’on fait très attention à la manière dont ces informations sont rédigées :

• On ne parle ici que de fonctionnalités manquantes et non de nouveautés.
• On ne sait pas quelles portions de runtime VB n’ont pas déjà été reprises pour .net 5.
• La dépendance à WinForm laisse penser que l’intégralité de WinForm n’est pas portée vers .net 5 (surprenant ?!).
• Il n’est pas dit que la prochaine monture de VB sera concernée par ces ajouts.

Malgré l’ajout du support de .net 5, je ne suis pas très optimiste. Il semble que cette version de VB soit là uniquement pour permettre aux développeurs .net Framework de migrer vers .net 5.

Quelques références sur le sujet :

• Visual Basic updates
• What's new for Visual Basic
• Visual Basic 16
• Les articles du blog dotnet dédié à VB.