Archives par étiquette : Visual Basic

image

VB et les StackOverFlowException

Je ne mets malheureusement quasiment plus les mains dans le code, mais j’ai eu le plaisir aujourd’hui de découvrir une particularité de VB.net qui m’a fait bondir au plafond et qui m’a laissé plus perplexe.

En effet à la vision de ce code :

image

J’ai été outré de découvrir que l’appel à cette propriété ne lève pas une StackOverFlowException.

L’appel à la propriété renvoie la valeur 0 sans autre forme de procès, sans exception, sans tousser, ni avertissement pour m’indiquer “hey ! mon garçon t’es sûr de vouloir faire ça ?”

Après avoir comme à mon habitude crié au loup, et pensé qu’il s’agissait d’un bug du compilateur ou de la CLR, j’ai essayé de comprendre par quel miracle le comportement rencontré pouvait se justifier.

Un petit tour par dotPeek et voilà le résultat :

image

Nouveau sursaut, j’en discute avec le leader technique de l’équipe qui est aussi perplexe que moi, et j’essaie de trouver la raison (certainement historique) pour laquelle nous avons ce comportement en VB, et rien choux blanc.

Comme à chaque fois que j’ai des questions dirons-nous particulières à propos des langages, j’ai donc contacté mon ami Jb Evain, qui après avoir pressenti que le sujet allait être rigolo à trouver l’explication de ce fonctionnement :

C’est tout à fait normal et même logique !

Il ne faut pas oublier que nous avons la possibilité en VB de faire ce type de code :

image

Nous pouvons en effet définir la valeur de retour d’une fonction en utilisant le nom de celle-ci.

La grosse différence avec le mot clé Return étant que le Return interrompt l’exécution de la méthode en cours, alors que ce n’est pas le cas dans l’exemple ci-dessous :

image

En effet, le code suivant l’affectation de la valeur de retour est bien exécuté.

Et si l’on reprend notre exemple, je pense que vous avez déjà compris qu’en réalité le code donné en exemple :

image

est en réalité équivalent à celui-là

image

ce qui explique la non levée d’une StackOverflowException !

image

Tester si une variable est égale à Nothing

Pour faire suite au post d’hier sur la définition du Nothing en VB, je vous propose de découvrir comment le test d’égalité à Nothing peut très vite conduire à des bugs dans votre code.

C’est en faisant une petite séance de suppression des warnings de compilation sur le projet sur lequel je travaille que j’ai rencontré ce message à plusieurs reprises :

Warning    48    This expression will always evaluate to Nothing (due to null propagation from the equals operator). To check if the value is not null consider using ‘IsNot Nothing’. 

Il y a deux manières d’effectuer des tests d’égalité à Nothing en VB et il est important de bien les distinguer :

  • Pour les types valeurs, on doit utiliser la syntaxe If myValueVar = Nothing
  • Pour les types références, il faut utiliser la syntaxe If myRefVar Is Nothing

Il faut vraiment prêter attention à ces deux contextes d’utilisation car si vous utilisez le Is ou le = dans le cas inverse, votre test ne fonctionnera pas.

Ainsi le code suivant fonctionne parfaitement :

image

Mais le code suivant ne fonctionne pas du tout :

image

Le simple fait de passer la variable en nullable oblige à changer le test d’égalité car on ne passera JAMAIS dans le bloc du IF si on laisse ce code tel quel.

J’ai rencontré ce type de problème à plusieurs reprise sur du code existant, pour une raison donc simple. Les développeurs ont passé des propriétés de type valeur en nullables sans prêter attention à également impacter les différents tests d’égalité à Nothing !

Le code correct est donc le suivant (si on ne souhaite pas utiliser la propriété HasValue) :

image

Il s’agit là d’une source de bug délicate à détecter, et un avertissement qui mériterait bien d’être considéré comme une erreur par le compilateur ! (d’où l’utilité de toujours réduire au maximum le nombre de warnings dans vos projets).

image

Nothing est différent de null

Une des différences les plus importantes entre le VB et le C# est la gestion de la nullité des types.

En VB, on utilise le mot clé Nothing et contrairement à ce que beaucoup de développeurs VB pensent,

le mot clé Nothing n’a (presque) rien à voir avec le null tel que l’on peut le connaitre dans la plupart des langages.

En effet, en VB le Nothing équivaut à Default.

La différence est très importante notamment pour les types valeurs, puisqu’il est tout à fait possible d’assigner Nothing à un type valeur ! Le type prend alors sa valeur par défaut, comme 0 pour les types numériques, ou Date.DateMin pour les dates :

image

 

Bien évidemment, pour les types références, la valeur affectée sera l’équivalent d’un null puisqu’aucune instance n’est créé lors de l’affectation de Nothing.

Pour rappel si l’on essaie de faire “la même chose” en C#, on se retrouve très justement avec une erreur de compilation :

image

Dans le prochain post, nous verrons l’impact de cette différence sur les tests d’égalité à Nothing.

quote

Une chaine doit être terminée avec des guillemets

String constants must end with a double quote

 

Jusque là rien de nouveau, excepté que j’ai rencontré cette erreur de compilation lors du test de la build que j’ai mis en place récemment sur notre nouveau serveur… de build.

Bien évidemment ce fut une surprise totale car je me suis basé pour cela sur un sln existant qui lui compile parfaitement.

Après un rapide saut vers les deux fichiers incriminés, je reste circonspect en lisant les lignes suivantes :

 Sub Main()         

 

 Dim chaine As String
 chaine = "Test"
 Select Case chaine

 

        Case "Valeur 1
           Console.WriteLine("It works")

 

        Case "Valeur 2
           Console.WriteLine("It works")

 

    End Select
 End Sub

 

Comme vous pouvez le constater les chaines ne sont pas délimitées avec une quote fermante. J’ai donc rapidement pensé à un problème d’encodage peut être du à la récente migration de TFS 2005 vers TFS 2010. Et bien non, le code montré ci-dessus compile parfaitement !

Le compilateur de Visual Basic valide sans aucun problème ce type de code, très certainement pour des raisons historiques. Surprenant non ?

Note 1 : Non je n’ai pas réussi à trouver la raison historique pour laquelle cela est possible.

Note 2 : Oui le compilateur présent sur le serveur de build réagit différemment que celui présent sur le poste de dév alors que je devrais à priori avoir la même version (Team Build SP1 sur le serveur, et VS 2010 SP1 sur les postes de dév). Je suppute que cette différence de comportement doit être lié au paramétrage de MS Build.

[Update] Merci à Sébastien qui a réussi à trouver la raison historique pour laquelle une chaine peut ne pas être terminée par une double quote en VB !

04-04-2011 14-16-37

Corriger le problème de génération de documentation en VB

Durant la mise en place d’un serveur de build, et après avoir rencontré moultes problèmes, je me suis confronté à un bug de VB plutôt ennuyeux.

Alors que je configurais la version release de chaque projet de la solution que je souhaitais compiler via un daily build, je me suis rendu compte qu’il n’était pas possible en VB de désactiver la génération de la documentation XML en Release sans que cela impacte la version Debug !

SNAGHTML28640326

La solution pour contourner ce problème est de tout simplement modifier vos vbproj via un éditeur de texte afin de spécifier le comportement souhaité. La case à cocher sera alors grisée par Visual Studio.

Si vous jugez que ce bug est ennuyeux, vous pouvez voter pour la soumission que j’ai faite sur Connect.

monsieur-propre-est-mort-L-1

Le Monsieur Propre des références

Que cela soit par fainéantise ou par manque de rigueur, il n’est pas rare de trouver des projets disposant d’un grand nombre de références dont certaines ne sont en réalité pas ou plus utilisé.

Pour arriver à faire le ménage dans ces références, il est possible d’utiliser des outils qui vont permettre de détecter quelles sont ces références qui ne sont effectivement pas utiles ni utilisées. NDepend est un excellent outil qui permet (entre autres) d’arriver à cela.

En Visual Basic, il existe une fonctionnalité “in the box” qui permet de détecter quelles sont les références qui semblent inutilisées. Libre ensuite au développeur de les supprimer depuis l’interface.

Pour accéder à cette fonctionnalité propre à l’outillage de VB (non disponible en C#), rendez-vous dans les propriétés de votre projet puis dans l’onglet références :

image

VB et l’asynchronisme

Comme je vous l’avais indiqué il y a quelques jours, j’ai eu l’occasion d’effectuer
une présentation de la future version de VB qui proposera des nouveautés en terme
de gestion de l’asynchronisme.

Avant de pouvoir visionner la session sur le site des TechDays, je vous propose dès
maintenant les slides utilisées durant cette présentation :

image

Visual Basic aux TechDays 2011

imageComme je
vous l’avais indiqué il y a quelques semaines
, je présenterais une session sur
VB lors de l’édition 2011 des TechDays en mettant un focus particulier sur les fonctionnalités
liées à la gestion de l’asynchronisme.

Si vous souhaitez comprendre en détail les mécanismes d’asynchronisme implémentés
par Windows (au niveau OS et même hardware) et le framework .net, et découvrir comment
VB vNext va considérablement simplifier le tout n’hésitez pas à venir !

Sauf changement de dernière minute, la session devrait avoir lieu demain
(Mardi 08 février) à 14:30 en salle 202/203.

Un bon pas pour la co-evolution

Je
râlais il y a quelques semaines sur le principe de co-evolution
en indiquant qu’il
était très bien qu’il soit mis en place d’un point de vue des langages VB et C# 
mais que ce principe devait être également valable d’un point de vue l’outillage associé.

Comme vous avez pu le noté dans les
news de la semaine
, l’équipe de Visual Basic vient de présenter sur son blog une
nouvelle fonctionnalité qui sera proposée avec le SP1 de Visual Studio 2010 : le “runtime
purity”.

Visual Basic a besoin depuis de très nombreuses années, même avant l’ère .net (souvenez-vous
des vbrunx00.dll) de différentes dépendances pour pouvoir fonctionner et cela est
toujours le cas à l’heure actuelle. Depuis .net, VB se trimbale avec une assembly
particulière Microsoft.VisualBasic.dll qui permet d’utiliser des fonctionnalités propres
au langage et qui n’ont pas vocation à être intégrés directement au sein du framework
.net :

  • Les mots-clés “old-school” issus des versions de VB avant .net
  • La plupart des fonctionnalités du namespace My
  • La gestion d’erreur avec le On Error Goto (ou Resume Next c’est
    plus simple…)
  • etc.

La bonne nouvelle est que le SP1 proposera d’utiliser un flag du compilateur qui permettra
d’indiquer à celui-ci que l’on ne souhaite pas utiliser les fonctionnalités proposés
par Microsoft.VisualBasic.dll.

Et comme l’indique l’équipe Visual Basic ce flag est stratégique puisqu’il devrait
ENFIN permettre de disposer des mêmes outils (et au même moment) que les développeurs
C# (XNA, Windows Phone, & co…).

Bien évidemment, cela signifie également que vous devez donc vous efforcer de perdre
vos vieilles habitudes en utilisant uniquement les fonctionnalités “100% .net compliant”
(uniquement issues du framework .net).

La co-évolution doit aussi être valable pour les outils

Ce
fut une des annonces de la PDC08 afin de palier aux différents décalages fonctionnels
des langages C# et VB, l’équipe Langages de Microsoft a indiqué que les deux langages
allaient à présent suivre la même évolution.

Cela signifie que toutes les nouvelles fonctionnalités qui seront implémentées dans
un des deux langages sera également ajouté dans l’autre. De plus, les fonctionnalités
existantes importantes qui manqueraient à l’un ou l’autre des langages sont en train
d’être comblés (ex : support des arguments optionnels et nommés en C# 4 ou encore
les itérateurs dans VB vNext).

Vous pouvez trouver l’explication de cette décision dans cette interview du regretté
Lucas Bolognese effectuée par Ted Neward :

Vous pouvez également lire la version
écrite via ce post de Scott Wiltamuth
.

Ce changement de direction ravit une grande majorité des développeurs C# et VB. Il
reste cependant un pas très important à franchir :

la co-evolution au niveau des outils !!!

Le dernier exemple qui démontre ce besoin date d’aujourd’hui
avec la
mise à disposition en version finale (RTW) des outils pour développer sous Windows
Phone 7 pour les développeurs VB
soit plus d’un mois (si je me limite à l’update
d’Octobre et donc sans compter la version initiale) après la mise à disposition du
kit de développement équivalent pour les développeurs C# !

De plus cette version n’est en réalité pas équivalente à la version C# puisque que
la version express de Visual Studio (gratuite) n’est pas supportée !

Alors, oui, fournir une compatibilité pour les développeurs VB est plus complexe que
pour les développeurs C# du fait des spéficités du langage et de sa library associée
Microsoft.VisualBasic.dll, mais bon… Cette complexité peut être anticipée et Microsoft
pourrait très bien dimensionner l’équipe responsable de cette implémentation en conséquence.

Il est bien beau de fournir des capacités semblables au niveau des langages encore
faut-t-il proposer aux deux communautés de développeurs de pouvoir développer les
mêmes types d’applications (au même moment) !