Le nom de l'espace de noms Microsoft.VisualBasic est-il "true .NET"?

Question

Mon équipe de dev est prêt pour commencer un nouveau projet. La boutique a été un "VB boutique" depuis les jours de VB3, mais l'opinion qui prévaut aujourd'hui est que nous sommes un ".NET boutique" et depuis C# a été créé spécifiquement pour .NET, alors que VB.NET a été une rénovation, nous avons décidé d'avancer, écrit en C#. La polémique tourne autour de la question de savoir si le Microsoft.VisualBasic espace de noms a une place légitime dans le développement de nouvelles ou si c'est seulement pour la rétro-compatibilité VB6 (et plus) du code. Un de plus, et de plus en plus question intéressante est de savoir si le code "sous" Microsoft.VisualBasic espace de noms est la même .NET code de si c'est vraiment de la vieille VB runtime soigneusement emballés dans une .NET wrapper, rendant en fait un COM interop de contrôle (de la même manière WinForms enveloppe le non-.NET Win32 API de fenêtrage mais non seulement .NET Api pour la consommation).

Pour rendre cette situation encore plus confuse, notre équipe de dev a un Microsoft Consulting Services, consultant de nous dire que Microsoft ne prend plus en charge de Visual Basic, y compris le temps d'exécution de VB sous-jacents à la Microsoft.VisualBasic espace de noms.

Ce que je suis à la recherche de liens -- de préférence à inattaquables sources Microsoft -- de la documentation définitivement répond à cette question d'une manière ou l'autre. J'ai déjà essayé plusieurs permutations de recherche sur Google, et pas obtenu de plus près à aller au fond de cette question.

EDIT: Apparemment je n'ai pas fait ma question claire. Je ne suis pas demander si VB.NET est vrai .NET code. Je suis en train de déterminer si ce qui est "sous" le Microsoft.VisualBasic espace de noms est .NET code ou si c'est la vieille VB6 runtime soigneusement emballés et exposé comme .NET code. Quelqu'un a déjà dit que les 9/10 de l'espace de noms simplement encapsule le code d'ailleurs .NET; qu'en d'autres 1/10?

Answer 1

Microsoft.VisualBasic.dll <> Microsoft.VisualBasic.Compatibility.dll !!!

(ou, si vous préférez, Microsoft.VisualBasic.dll != Microsoft.VisualBasic.Compatibility.dll; )

La Microsoft.VisualBasic.La compatibilité de l'espace de noms est utilisé exclusivement par le VB6 assistant de mise à niveau, peut être supprimée dans les versions futures, et ne devrait jamais être utilisé pour un nouveau développement.

La Microsoft.VisualBasic espace de noms est absolument, à 100% vrai .Net, entièrement pris en charge, et sera aussi longtemps que .Net est d'environ.

Quelques liens utiles:

• Discussion: Est Microsoft.VisualBasic obsolète?
  
• De l'Article: Obtenir pur .NET développement avec VB.NET
• Voir les commentaires sur ce MSDN VBFAQ post de blog
  

Edit: Ajouté le mot officiel de cet article MSDN:

Le Runtime de Visual Basic fournit l' implémentation sous-jacente pour le mondial Fonctions de Visual Basic et de la langue des fonctionnalités telles que Len, IsDate, et CStr. Et si le nouveau Visual Basic Runtime fournit des installations similaires comme ses prédécesseurs, il est tout à fait code managé (développé en Visual De base .NET) qui s'exécute sur la common language runtime. En outre, le Runtime de Visual Basic est une partie de l' .NET Framework, donc il n'est jamais quelque chose qui est distinct de votre l'application a pour transporter ou de le déployer.

et

Le Visual Basic 6.0 De Compatibilité la bibliothèque est distincte de celle de Visual Basic Runtime. L' Microsoft.VisualBasic.Compatibilité espace de noms est utilisé par les outils que l' mise à niveau de Visual Basic 6.0 code de Visual Basic .NET. C'est un pont à en charge de Visual Basic 6 dispose que ne sont pas pris en charge directement par l' .NET la mise en œuvre de Visual Basic. Contrairement à le Runtime de Visual Basic, la bibliothèque de compatibilité n'est pas implicitement référencé par tous les Visuels De base .NET applications. Lorsque vous mise à niveau d'un projet Visual Basic 6 pour Visual Basic .NET, l'assistant de mise à niveau ajoute une référence à la Microsoft.VisualBasic.La compatibilité.

La compatibilité des classes ne doit pas être utilisé pour un nouveau développement. L' Microsoft.VisualBasic.Compatibilité espace de noms ajoute une couche de complexité pour votre Visual Basic .NET application et introduit un minimum de la performance des coûts qui pourraient être éliminé par le recodage des parties de la application. En outre, l' La compatibilité de l'espace de noms contient souvent de nombreuses classes qui encapsulent les objets COM, et comme indiqué précédemment, selon COM objets n'est pas aussi optimale que un pure géré la mise en œuvre.

Answer 2

Utiliser .NET Réflecteur et de jeter un œil sur elle. Je le fais souvent. 9 sur 10 appels dans le Microsoft.VisualBasic espace de noms sont juste des wrappers autour .NET méthodes.

Votre conseiller est de faire ce que les consultants font de mieux: montrer qu'il existe pour faire de votre budget est plus grand. MS ne prend pas en charge VB6 plus, mais le fait que VS 2008 a VB .NET devrait indiquer qu'ils seront de soutien VB .NET pour au moins quelques années de plus.

Personnellement, je traite de Microsoft.VisualBasic comme une façade sur l'autre .NET classes. Je l'utilise quand c'est un projet personnel et je peux rendre ma tâche plus rapidement et plus facilement que d'utiliser BCL classes. Un bon exemple est celui de Microsoft.VisualBasic.Les chaînes de caractères.Droit par rapport à la Chaîne.Sous-chaîne. Cependant, pour de nombreuses fonctions (comme Val) dans le VB espace de noms, il y a de plus robuste et puissant dans les versions les moins spécifiques à la langue sections du cadre. Si je suis à l'écriture de code pour le travail, je n'utilise pas le VB bibliothèques. Ce qu'il fait en sorte que les développeurs C#, pas familiarisé avec visual basic va pas avoir un moment plus difficile la compréhension de mon code.

Answer 3

Comme certaines fonctionnalités dans le FCL, une partie de Microsoft.VisualBasic espace de noms de code est écrit en code managé, certains de il encapsule les appels à du code non managé.

Il n'y a certainement aucune dépendance sur le vb6 runtime et ce n'est certainement pas l'installation du vb6 runtime tranquillement sous le capot.

Vous devez charger .NET Réflecteur et de prendre un coup d'oeil au code dans le Microsoft.VisualBasic espace de noms.

Si vous voulez aller sur l'aide de la fonctionnalité de cet espace de noms à partir de C#, puis continuer à faire ainsi, il ne va pas loin. Du code peut obtenir marquée comme obsolète/obsolète, mais je m'attends à 15 ans de temps, vous aurez toujours être en mesure d'exécuter les mêmes applications à l'aide de Microsoft.VisualBasic fonctionnalité, sans aucun problème.

Mise à jour: ainsi Que l'utilisation .NET réflecteur vous pouvez maintenant voir/debug la source de Microsoft.VisualBasic namespace/Microsoft.VisualBasic.DLL code:

http://blogs.msdn.com/vbteam/archive/2008/01/19/source-code-of-visual-basic-runtime-has-been-released-to-public.aspx

Aller attraper le cadre de mass downloader et de parcourir le code à votre guise:

http://www.codeplex.com/NetMassDownloader

Answer 4

Je crois qu'ils compilent tous au même bytecode.

Voici ma référence: http://www.codinghorror.com/blog/archives/000128.html

Answer 5

La déclaration "Microsoft ne prend plus en charge de Visual Basic" peut vouloir dire plusieurs choses, puisqu'il y a plusieurs versions de Visual Basic, VB 1 à 6, VBA et VB.NET.

La déclaration "Microsoft ne prend plus en charge Visual Basic.NET" serait une grande nouvelle si c'était vrai, mais il n'est pas. (J'ai vérifié sur google). Soutien pour VB6 a pris fin, mais VB.Net est encore très vivante et en acquérant de nouvelles fonctionnalités.

VB.Net est compilé en bytecode MSIL qui dépend de quelques de la de la .Net bibliothèques, selon qui .net framework classes que vous utilisez. Certaines de ces bibliothèques ne sont pas écrites dans le plus pur .Net, ou simplement les wrappers autour de l'API Windows. Ceci est nécessaire, car ces fonctionnalités qui ne sont pas intégrés .net e.g filetage) doivent être exposés de manière contrôlée.

Exactement la même chose est vraie de C#. Le moteur d'exécution ne s'occupe pas vraiment la langue qui a généré le MSIL qu'il s'exécute.