posted on vendredi 3 décembre 2004 19:43 par patrice

[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)

m_AList = thearraylist

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.

Comments

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

vendredi 3 décembre 2004 20:52 by Jb Evain
Notons tout simplement que ça correspond au switch du compilateur vbc /imports, que ne possède pas csc. Donc ça ne lie pas forcément le code à l'IDE, puisque même NAnt pourras par exemple compiler le code avec les bons imports par défaut lors de l'appel de vbc. Cela dit ce n'est pas très "safe".

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

vendredi 3 décembre 2004 23:39 by Patrice
Vlad => pour éviter ton problème il faut toujours mettre Option Strict à true dans tes projets VB.net

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

samedi 4 décembre 2004 06:50 by Richard
C'est faux de dire que VB 2005 n'aura pas de refactoring comme d'affirmer que C# aura le Edit & Continue. C'est un peu plus subtil que cela.

Concernant le Option Strict On par défaut, c'était mis sur Off pour "aider" les devs VB6 (pour pas les traumatiser). Avec VS 2002, il ne concervait pas entre session ton paramétrage ce qui a été corrigé avec VS 2003 suite à de nombreuses protestations.

Dans le même esprit que les Imports, j'ajouterais plutot un truc pénible: tu as forcement un Namespace par défaut en VB. Tu ne peux donc pas créer une assembly avec un type nommé Project1.MaClass et MonNamespace.MaClass

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

samedi 4 décembre 2004 13:08 by Vlad
pour les != entre ide (en locurence ici c# et vb.net) trouve ca pénible en espérant que ca va pas s'accentuer surtout pour ceux qui utilisent deux langages (pas mon cas mais pense aux autres ) et cet esprit de rahh les iterators sont qu'en c# yeaaah ou le My qu'en vbbb yeahhh (m'enfin difficile de comparer iterators et My tout de meme )

Un autre truc pénible (moins pénible que le coup des namespaces) que j'ai trouvé dans l'ide de vb quand j'ai du mettre la patte sur un joli projet vb pdt une journée c'est que dans une application web asp.net lorsque qu'on passe en debug les webform sont en lecture seul.
Un peu relou ... : en c# l'habitude de modifier ma page html et faire F5 sur ie pour voir ce que ca donne mais ide vb ve pas qu'on modifie prop des controle.pas glop (solution alternative bien sur lancer un ie a coté sans etre en debug bien sur )
POur la partie code relou aussi car j'ai l'habitude en c# de modifier parfois code à chaud (meme si edit & continue n'est pas encore la;)) pour voir ce que ca donne via le quickwatch...ce qu'on pe pas faire en vb car fichier en lecture seule lors debug (mais bon la vb 2005 corrige bien sur ce pro) (ya une autre option que j'ai zappé ? )

ah oui aussi j'ai perdu une minute sur les propriétés d'un projet vb .net dans vs .net car l'agencement est différent que celui de la fenetre propriété d'un projet c#...trop dur pour moi satck buffer over flow...serait cool d'harmoniser tout ca (je crois que c'est le cas avec vs 2005)

mouala