Conversion de C # Connaissances à VB.NET Tous les problèmes potentiels?

AS C # et VB.NET utilise le même cadre et compiler un code IL très similaire, vous avez beaucoup gratuitement. Écrire la syntaxe de base à la place n'est pas si difficile.

La syntaxe C # est plus destinée à montrer ce qui se passe, tandis que la syntaxe VB se cache souvent quelques détails. Un programmeur C # est donc familiarisé avec certains concepts qui ne sont peut-être pas du tout évident pour un programmeur VB. D'une certaine manière que l'apprentissage C # est un meilleur moyen d'apprendre comment VB fonctionne que pour apprendre la VB elle-même ...

Je réponds souvent aux questions VB.NET dans différentes forums sur la plupart des forums sur la plupart de mes connaissances C #, et je n'ai toujours rien écrit de plus que de courts programmes de test dans VB.net moi-même.

Il y a bien sûr quelques bizarreries à rechercher dans VB. Comme l'opérateur / l'opérateur, qui convertit toujours les deux opérandes au double ou l'opérande = qui utilise un code de comparaison spécifique VB plutôt que la comparaison spécifiée pour l'opérateur d'égalité dans les classes .NET.

Une option si vous n'avez pas envie d'écrire le code VB.NET consiste à écrire votre projet en C #, compilez-le et utilisez le réflecteur pour voir ce que l'équivalent VB.NET ressemble. Tout cela se compile à MSIL quand même!

une zone que vb.net a tendance à essayer de couvrir fonctionne avec des événements; D'autres ont brièvement touché certaines des différences, mais voici un peu plus sur eux:

vb.net fournit un withEvents code> mot-clé pour les champs qui soulèvent des événements. Si le champ est déclaré withevents code>, vous pouvez ajouter un champ gérer le champ.Event code> à la fin d'une méthode dont la signature est compatible avec l'événement; Cette méthode sera automatiquement déléguée de l'événement sans avoir besoin de addhandler code> et retirerHandler code> ( + = code> et - = code >). P>

Public event SomeEvent as EventHandler(of SomeEventArg)
Public Sub SomeMethod()
    // Note that SomeEvent's MulticastDelegate is accessed by appending
    // another "Event" to the end, this sample is redundant but accurate.
    // If the event was named ListChanged then it would be ListChangedEvent
    dim invocationList = SomeEventEvent.GetInvocationList()
End Sub

Il y avait quelques articles utiles dans le magazine Visual Studio de retour en janv. 2008.

• Ce que les développeurs C # doivent savoir sur VB
• et pour la complétude, Quels développeurs VB devraient savoir sur C #

  Vous pourriez aussi être intéressé par la question " Qu'est-ce qui est autorisé dans VB qui est interdit en C # (ou inversement) "

Outre ce que Jared a déjà mentionné, vous n'avez pas eu de problèmes pour ce faire cela. La seule autre source d'irritation est étrange par défaut. PAR EXEMPLE. Saviez-vous que les projets VB.NET, par défaut, cachez-vous le nœud de références dans l'explorateur de solutions? (Vous devez sélectionner ShowallFiles pour le voir).

Un point qui n'a pas été mentionné ici est que les initialisateurs de champs en C # exécutés avant le constructeur de base, tandis que ceux de VB exécutent entre le constructeur de base et la première "relève" réelle "du constructeur de classe dérivée (après la base de la base -Constructeur appel, le cas échéant). Cela permet aux initialiseurs de champs dans une classe dérivée d'utiliser des membres de la classe de base (qui auraient pu être initialisés à l'aide de paramètres transmis au constructeur), mais signifie également que si le constructeur de classe de base d'un objet passe n'importe où avant Il revient, l'objet partiellement construit peut être utilisé avant que tous les initialisateurs de champ soient exécutés. En C #, tous les initialisateurs de terrain seront exécutés avant que le constructeur de base ne démarre d'exécution, mais aucun des initialiseurs de champ ne pourra utiliser l'objet partiellement construit.

PS - Si l'une des personnes Microsoft derrière C # lisez ceci, il y aurait une difficulté particulière d'ajouter un mot-clé sensible au contexte pour les déclarations de champs afin de préciser si elles doivent être traitées avant ou après le constructeur de base, ou éventuellement les avoir Effectué par une méthode spéciale qui pourrait être appelée à partir du constructeur, qui pourrait être enveloppée dans un blocage de l'essai-enfin (de sorte que tout iDisposables ainsi alloué pourrait être nettoyé) et pourrait également être en mesure d'utiliser des paramètres transmis au constructeur? < / p>

Apprécier l'âge de cette question, celui-ci est probablement assez connu maintenant, mais j'ajouterai le plus grand gotcha que j'ai vu en termes d'écriture vb.net comme un utilisateur C #:

rien code> ne signifie pas null code>, cela signifie par défaut (t) code> strong> p>

ceci signifie que ...

Dim a As Integer? = Nothing
If a = Nothing Then Console.WriteLine("a = Nothing")
If a <> Nothing Then Console.WriteLine("a <> Nothing")
If a Is Nothing Then Console.WriteLine("a Is Nothing")
If a IsNot Nothing Then Console.WriteLine("a IsNot Nothing")

'Output:
'a Is Nothing