Patrice 's Blog

[VB.net is not C#] Option Strict

Dans mon post précédent, Matthieu Nicolescu me suggérait un nouveau post pour cette rubrique VB.net is not C# car il semblait plutôt enervé (et il a entièrement raison) des libertés que permet le VB.net.

En effet, par défaut, le code suivant compile mais ne fonctionne pas :

Sub Main()

End Sub

Public Sub DoSomething(ByVal param As Boolean)

If param Then

End If

End Sub

Je suis entièrement d'accord il est plutôt choquant que ce code compile sans problème et lève une exception lors de l'éxécution. Cela est du au langage VB lui même qui est très, et même trop permissif. En effet, il est toujours possible de ne pas déclarer ses variables en VB.net. (il suffit de mettre un Option Explicit Off), et on peut toujours laisser faire le compilateur VB pour le cast des variables et ainsi ne se soucier de rien. Si l'on souhaite éviter que le code présenté ci-dessus compile et imposer au développeur le cast explicite il faut mettre la directive Option Strict à On pour tous vos projets VB.net. Vous éviterez ainsi des erreurs plus ou moins subtiles à détecter...

[Rappel] Les rencontres Visual Basic

Je vous rappelle que les rencontres Visual Basic ont lieu dans toute la France et qu'elles continuent. Je serais pour ma part à Toulouse le 9 décembre.

[VB.net is not C#] Les imports (<=>using)

Les développeurs C# seront sans doute surpris mais le code suivant compile sans aucun problème sous VS.net...

Public Class clsAList

Private m_AList As New ArrayList

Public Sub New(ByVal thearraylist As ArrayList)

End Sub

End Class

Vous aurez sans doute remarqué qu'il manque normallement un Imports System.Collections nécessaire à l'utilisation de la classe ArrayList.

Cette classe est compilée sans aucun problème par VS.net alors que si vous saisissez cette classe telle quelle dans un autre IDE (#develop par exemple) ou même dans notepad et utilisez le compilateur vb.net, vous devriez avoir des ennuis...

Comment est-ce possible ? Grâce aux Imports "automatiques" fonctionnalité proposée par VS.net (et même #Develop).

Cette fonction peut paraitre séduisante au premier abord mais je vous déconseille néammoins de l'utiliser. En effet, vous l'avez peut-être déjà compris, cela nuit gravement à la portabilité de votre code source... Imaginons que vous creez une solution sous #Develop que vous ajouter la classe ci-dessus, votre application ne compilera plus, etc.. etc... Vous avez compris le problème...

En conclusion mettez explicitement tous les Imports nécessaires dans vos classes pour éviter ce genre d'ennuis...

Les développeurs C# n'auront pas ce genre d'ennuis puisque cette fonction n'est pas implémentée.

Emulateur dans emulateur... (suite et fin)

Après quelques recherches sur les raisons de l'incompatibilité de Virtual PC et l'émulateur utilisé par Visual Studio.net 2003, je me suis rendu compte que l'émulateur utilisé par VS.net ne semble être rien d'autre qu'une sorte de Virtual PC. En effet, cet émulateur n'est pas développé par Microsoft mais par... Connectix la société créatrice de Virtual PC qui s'est fait rachetée par Microsoft... En conclusion ce bug est dit "by design" puisqu'il est n'est pas possible de faire tourner une machine virtuelle VPC à l'intérieur d'une autre machine virtuelle VPC.

Bonne nouvelle, l'émulateur livré avec VS 2005 a été entièrement refait et fonctionne sous Virtual PC. Encore une raison d'attendre avec impatience Octobre ou Novembre 2005...

3637