Developers-Association.org

Visual Basic .NET
Migrer ou ne pas migrer : telle est la question !

Lorsque Visual Basic .NET a pointé le bout de son nez il y a déjà plus de deux ans, la première réaction de la majorité des développeurs Visual Basic (VB) a été l'enthousiasme de l'accueil d'une nouvelle version. Il faut dire qu'on l'attendait depuis longtemps et que les informations concernant ses spécifications étaient distribuées au compte goutte. Depuis sa "naissance" en 1991, il y a eu 6 versions de VB en seulement 7 ans alors qu'entre VB6 et Visual Basic .NET, il aura fallu attendre 4 ans.
La seconde réaction, toujours valable si vous découvrez Visual Basic .NET aujourd'hui, c'est l'étonnement, la surprise, l'incompréhension : le langage semble complètement différent, certains même n'hésitant pas à clamer haut et fort que Visual Basic est mort et que Visual Basic .NET est un tout autre langage. La syntaxe possède bien quelques similitudes mais si vous essayez d'écrire "à la VB6" la moindre ligne de code, il y a de fortes chances pour que le nouveau compilateur refuse de créer votre .exe. Visual Basic .NET viendrait-il d'une autre planète ?

Le principal sujet d'incertitude devient donc : faut-il migrer vers Visual Basic .NET ?

A cela je répondrais que la question est mal posée. Je sais, je suis pointilleux, voir pénible comme dirait ma femme, mais elle se décompose en réalité en deux questions (la question, pas ma femme) :

Faut-il transposer, réécrire tous vos projets VB6 en Visual Basic .NET ?
Faut-il vous former ou former vos équipes de développement à Visual Basic .NET ?

Pour la première, j'ai une position claire : NON.
Il y a à cela plusieurs raisons :
Premièrement, essayez d'utiliser l'assistant de migration de code livré avec Visual Studio .NET. Si vous le testez sur une "petite" application, cela devrait se passer relativement bien mais avec une "véritable" application de plusieurs milliers de ligne de code, vous constaterez que les "TODO", les modifications de code à effectuer à la main, apparaissent par milliers comme les pâquerettes dans les pâturages au printemps. Ensuite, en supposant que vous soyez arrivé au bout de vos peines, je vous garantis que votre code ne sera pas optimisé et il se pourrait même que les gains en performances soient insignifiants.
Conclusion, et j'insiste sur ce point, si votre application fonctionne dans sa version VB6, tant mieux, ne changez rien, ne passez pas des journées entières juste pour pouvoir dire : j'ai une application .NET !

Pour la seconde question, ma réponse est tout aussi claire : OUI.
Oui parce que vous bénéficiez ainsi de l'ensemble des avantages de la plateforme .NET et ils sont si nombreux que je ne pourrai qu'en exposer qu'une partie. Mais tout d'abord faisons tomber quelques mythes :

Premier mythe : Visual Basic .NET est compliqué.
Et bien désolé, mais pour moi il devient trivial.
Bon, je sais, je suis provocateur mais jusqu'à présent, vous deviez connaître sa syntaxe, ses fonctions intrinsèques (comme FreeFile, FileOpen, MsgBox), les API Win32 (pour aller plus loin), etc.
Maintenant, tout ce que vous manipulerez, ce sont des types, ou plus exactement les membres de ces types. Une fois que l'on a bien compris ce principe, Visual Basic .NET devient trivial (si, si, je vous assure). Vous connaissez la syntaxe de Visual Basic .NET - ce qui devrait prendre moins d'un millième de seconde pour un développeur VB6 - et bien la seule chose qu'il vous reste à faire consiste à connaître les 270 000 membres des 9 000 types du .NET Framework - pardon je plaisante - à connaître les membres des types qui concernent VOTRE projet.
Il ne s'agit pas de connaître les fonctions cachées du langage (quand je dis cachées, je veux dire difficilement trouvables dans la documentation), mais juste de regarder un type, de comprendre ses membres (procédures, fonctions, propriétés) et de les utiliser à bon escient.
La recherche d'information sur comment effectuer telle ou telle opération s'en retrouve donc fortement simplifiée et se résume ainsi :
1. Trouver le type susceptible de traiter cette opération.
2. Trouver le membre du type effectuant cette opération.
De plus, comme les types sont rangés consciencieusement (par espaces de noms), la première étape est rapide. Sceptique ?
Prenons l'exemple du test de l'existence d'un fichier. Avec VB6, vous avez la solution d'utiliser les API avec les dangers que cela représente, FileOpen avec un On Error et des problèmes d'accès concurrentiels, ou l'objet COM FileSystemObject. Dans tous les cas, cela nécessite une certaine "connaissance" du problème. Reportez cet exemple dans des domaines que vous ne maîtrisez absolument pas, et vous passerez des heures en lecture de SDK pour arriver à votre solution. Avec VB .NET, on remarque tout de suite la présence d'un espace de noms System.IO, il y a de fortes chances pour qu'un de ses types réponde à notre question. Il y en a justement un qui s'appelle File et sans vouloir être devin, nous pouvons envisager qu'il s'intéresse à l'existence d'un fichier. BINGO : il possède bien une fonction partagée Exist qui retourne cette information. L'IntelliSense permet systématiquement d'avoir accès à l'ensemble des membres et méthodes des différents types.

Autres exemples pour vous faire comprendre la facilité d'accès aux informations :

Pour connaître le jour de la semaine d'une date, il faut savoir que VB6 vous propose une fonction intrinsèque. Avec .NET, c'est juste la propriété DayOfWeek du type Date.
Pour connaître la position d'un caractère dans un String ? VB6 propose toujours une fonction intrinsèque InStr alors que Visual Basic .NET utilise la méthode IndexOf du type String. Et la position d'un caractère en partant de la fin ? Etes-vous capable de me donner une réponse pour VB6 rapidement ? Pour Visual Basic .NET, en moins d'une minute vous pouvez constater que String possède bien une méthode effectuant cette opération, LastIndexOf.
etc.

Une fois cette habitude prise de rechercher les membres d'un type, je vous assure que la programmation est beaucoup plus naturelle et plus simple, même si ce n'est pas le premier sentiment que l'on a quand on regarde du code Visual Basic .NET.

Parmi les autres avantages de cet apprentissage, je citerais pêle-mêle les capacités de multi-threading, de callback, d'héritage, etc. mais aussi les gains en terme de performance. Visual Basic .NET est au même niveau que C#, J#, C++, etc. tout simplement parce que tous les générateurs de ces différents langages (appelés à tort dans de nombreux articles compilateurs) traduisent votre code en Microsoft Intermediate Language (MS IL). Ils s'exécutent donc à la même vitesse.

Second mythe : Visual Basic .NET est dédié au Web.
Certes le développement d'applications Web, de services Web devient facile et efficace avec Visual Basic .NET mais je développe à longueur de journée des programmes tournant sous Windows et le gain en temps de développement et en performance est considérable. Par exemple, .NET supporte en natif l'ancrage et le re-dimensionnement de vos contrôles sans que vous ayez besoin d'écrire la moindre ligne de code. Pour les contrôles sophistiqués comme les Treeview et ListView, ils font partie du Framework : vous n'avez plus besoin d'ajouter une référence vers un ocx et ses dll qui pèsent plusieurs Mo. Cela me fait d'ailleurs penser aux problèmes de distribution d'applications : avec VB6, vous avez besoin à 99% du temps de créer un programme d'installation avec tous les problèmes qui en découlent. Avec Visual Basic .NET, comme au bon vieux temps du MS DOS, vous pouvez distribuer vos programmes en copiant l'exe. Sous réserve, bien entendu, que le .NET Framework soit installé sur la machine cliente, ce qui devrait être automatique avec les prochaines versions de Windows. D'ici là, quand le Framework n'est pas encore présent, c'est à vous de l'installer avant de déployer votre application.
De plus, je ne sais pas si vous avez déjà essayé de créer des menus avec des images avec VB6, c'est presque mission impossible. Avec Visual Basic .NET, de par la conception même du Framework, quelques dizaines de lignes suffisent.

Troisième mythe : Il faut tout recommencer à zéro.
Même si je vous ai dit plus haut qu'il fallait éviter de migrer ou de réécrire vos applications vers Visual Basic .NET, rien ne vous empêche d'utiliser nombre de vos anciens développements pour peu que vous preniez certaines précautions. L'interopérabilité entre .NET et COM est complète et dans les deux sens. Il suffit donc d'encapsuler vos développements VB6 dans des dll COM (projet type ActiveX dll) pour que vous puissiez les réutiliser dans vos projets .NET. Inversement, si vous avez un projet VB6 en cours, rien ne vous empêche de créer des classes avec Visual Basic .NET qui pourront être utilisées : c'est d'ailleurs à mon avis la meilleure solution pour migrer en douceur vers le monde .NET.

L'avenir de .NET ?
Se former à .NET demande, il ne faut pas se voiler la face, un investissement en temps non négligeable, aussi la question de la pérennité de cette technologie est primordiale. Je vous rassure : Microsoft s'est engagé dans la voie .NET pour de nombreuses années et, à terme, tous ses produits reposeront sur cette plateforme de développement. Je ne prendrai pas l'exemple des prochains serveurs (Windows .NET Server 2003, SharePoint, etc.) tant il est évident que le Framework en est leur base de fonctionnement mais reprenons des produits "simples" comme Microsoft Office : vous pensez que Visual Basic pour Application restera avec la syntaxe VB6 ? De même la prochaine version de SQL Server (nom de code Yukon) vous permettra de créer des procédures stockées écrites en Visual Basic .NET et compilées.

Pour conclure, laissez-moi vous donner un conseil : testez Visual Basic .NET. Quand je dis tester Visual Basic .NET, il ne s'agit pas de créer un petit "Hello World", mais de créer une petite application simple s'inspirant par exemple d'un ancien développement VB6. Puis un autre un peu plus compliqué et vous verrez au fur et à mesure que Visual Basic .NET vous simplifie la vie, diminue le nombre de lignes de code pour créer des applications plus riches fonctionnellement et visuellement, plus robustes et plus rapides, tout cela avec un gain de temps de développement important.

Formez-vous à Visual Basic .NET et vous aurez plus de temps pour aller à la plage :-)

Richard CLARK

Pour aller plus loin : www.microsoft.com/france/vbasic
Retrouvez " Au coeur de Microsoft Visual Basic .NET " de Richard Clark sur son site : www.c2i.fr