Является ли пространство имен Microsoft.VisualBasic "истинным .NET" кодом?

Question

Моя команда разработчиков готовится начать новый проект. Магазин был «магазином VB» со времен VB3, но сейчас преобладает мнение, что мы - «магазин .NET», и поскольку C # был создан специально для .NET, тогда как VB.NET был модифицирован, мы решил двигаться вперед, писать только на C #. Спор вращается вокруг вопроса о том, имеет ли пространство имен Microsoft.VisualBasic законное место в новой разработке или только для обратной совместимости для кода VB6 (и более старого). Еще один и более интересный вопрос состоит в том, является ли код «под» пространством имен Microsoft.VisualBasic даже кодом .NET, если это действительно старая среда выполнения VB, тщательно упакованная в оболочку .NET, что делает его фактически элементом управления взаимодействием COM ( аналогично тому, как WinForms оборачивает оконный API не .NET Win32, но предоставляет для использования только .NET API).

Чтобы сделать это еще более запутанным, у нашей команды разработчиков есть консультант Microsoft Consulting Services, который сообщает нам, что Microsoft больше не поддерживает Visual Basic, , включая среду выполнения VB, лежащую в основе пространства имен Microsoft.VisualBasic .

Мне нужны ссылки - предпочтительно на безупречные источники Microsoft - на документацию, которая однозначно отвечает на этот вопрос. Я уже пробовал несколько поисковых перестановок в Google и не приблизился к сути этого вопроса.

РЕДАКТИРОВАТЬ: Очевидно, я не прояснил свой вопрос. Я не спрашиваю, является ли VB.NET истинным кодом .NET. Я пытаюсь определить, является ли то, что находится "под" пространством имен Microsoft.VisualBasic , кодом .NET или это старая среда выполнения VB6, тщательно упакованная и представленная как код .NET. Кто-то уже сказал, что 9/10 пространства имен просто переносят код из других мест в .NET; что насчет других 1/10?

Answer 1

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

(или, если хотите, Microsoft.VisualBasic.dll! = Microsoft.VisualBasic.Compatibility.dll; )

Пространство имен Microsoft.VisualBasic.Compatibility предназначено исключительно для использования мастером обновления VB6, может быть удалено в будущих версиях и никогда не должно использоваться для новой разработки.

Пространство имен Microsoft.VisualBasic абсолютно, на 100% истинно .Net, полностью поддерживается и будет существовать до тех пор, пока существует .Net.

Несколько соответствующих ссылок:

• Обсуждение: Microsoft.VisualBasic устарела?
  
• Статья: Достигните чистой разработки .NET с VB.NET
• См. Комментарии к этой записи в блоге MSDN VBFAQ
  

Редактировать: Добавлено официальное слово от этой статьи MSDN :

Среда выполнения Visual Basic предоставляет базовая реализация для глобального Visual Basic функции и язык такие функции, как Len, IsDate и CStr. И хотя новый Visual Basic Runtime предоставляет такие же возможности, как его предшественники, это полностью управляемый код (разработан в Visual Basic .NET), который выполняется на общеязыковая среда выполнения . Более того, среда выполнения Visual Basic является частью .NET Framework, так что это никогда что-то отдельное, что ваш приложение должно нести или развернуть.

и

Совместимость с Visual Basic 6.0 библиотека отличается от визуальной Основное время выполнения. Microsoft.VisualBasic.Compatibility пространство имен используется инструментами, которые обновить код Visual Basic 6.0 до Visual Basic .NET. Это мост к поддержка функций Visual Basic 6, которые не поддерживаются напрямую .NET реализация Visual Basic. В отличие от среда выполнения Visual Basic, библиотека совместимости не неявно ссылаются на все визуальные Основные приложения .NET . Когда ты обновить проект Visual Basic 6 до Visual Basic .NET, мастер обновления добавляет ссылку на Microsoft.VisualBasic.Compatibility.

Классы совместимости не должны использоваться для новой разработки . Microsoft.VisualBasic.Compatibility Пространство имен добавляет уровень сложности в ваше приложение Visual Basic .NET и вводит некоторые минимальные затраты на производительность, которые могут быть устранены путем перекодирования частей приложение. В дополнение Пространство имен совместимости часто содержит много классов, которые обертывают объекты COM, и, как указано ранее, в зависимости от COM-объекты не так оптимальны, как чисто управляемая реализация.

Answer 2

Используйте .NET Reflector и загляните в него. Я делаю это часто. 9 из 10 вызовов в пространстве имен Microsoft.VisualBasic являются просто обертками для методов .NET.

Ваш консультант делает то, что делают консультанты лучше всего: хвастается, что он существует, чтобы увеличить ваш бюджет. MS больше не поддерживает VB6, но тот факт, что VS 2008 имеет VB .NET, должен указывать на то, что они будут поддерживать VB .NET еще как минимум несколько лет.

Лично я отношусь к Microsoft.VisualBasic как к фасаду над другими классами .NET. Я использую его, когда это личный проект, и я могу выполнять свою работу быстрее и проще, чем с помощью классов BCL. Хорошим примером является Microsoft.VisualBasic.Strings.Right по сравнению с String.Substring. Однако для многих функций (например, Val) в пространстве имен VB существуют более надежные и мощные версии в менее специфичных для языка разделах платформы. Если я пишу код для работы, я не использую библиотеки VB. Это делает так, что разработчикам на C #, незнакомым с VB, не составит труда понять мой код.

Answer 3

Как и некоторые функциональные возможности в FCL, часть кода пространства имен Microsoft.VisualBasic написана в управляемом коде, а некоторая часть переносит вызовы в неуправляемый код.

Конечно, нет никакой зависимости от среды выполнения vb6, и, конечно, она не устанавливает тихо среду выполнения vb6 под капотом.

Вы должны загрузить .NET Reflector и взглянуть на код в пространстве имен Microsoft.VisualBasic.

Если вы хотите продолжать использовать функциональность в этом пространстве имен из C #, продолжайте в том же духе, это никуда не исчезнет. Некоторый код может быть помечен как устаревший / устаревший, но я ожидаю, что через 15 лет вы все равно сможете без проблем запускать те же приложения, используя функциональность Microsoft.VisualBasic.

Обновлено: кроме использования отражателя .NET теперь вы можете видеть / отлаживать исходное пространство имен Microsoft.VisualBasic / код Microsoft.VisualBasic.DLL:

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

Перейдите к загрузчику фреймворка и просматривайте код на досуге:

http://www.codeplex.com/NetMassDownloader

Answer 4

Я полагаю, что все они компилируются в один и тот же байт-код.

Вот моя ссылка: http://www.codinghorror.com/blog/archives/000128.html

Answer 5

Заявление «Microsoft больше не поддерживает Visual Basic» может означать несколько вещей, поскольку существует несколько версий Visual Basic - от VB 1 до 6, VBA и VB.NET.

Утверждение «Microsoft больше не поддерживает Visual Basic.NET» было бы большой новостью, если бы оно было правдой, , но это не . (Я проверил на Google). Поддержка VB6 закончилась, но VB.Net все еще жив и приобретает новые функции.

VB.Net компилируется в байт-код MSIL, который зависит от некоторых библиотек .Net, в зависимости от того, какие классы .net Framework вы используете. Некоторые из этих библиотек написаны не на чистом .Net или являются просто оболочками для Windows API. Это необходимо, поскольку те функции, которые не встроены в .net (например, многопоточность), должны контролироваться им.

Точно то же самое относится и к C #. Среда выполнения на самом деле не заботится о том, какой язык сгенерировал MSIL, который он выполняет.

Answer 6

Цель Microsoft - сделать VB .NET и C # одним языком с разным синтаксисом. Это правда. Однако изменения всегда происходят, как и новая обработка VB9 XML-литералов. Что он спрашивает, так это переименовали ли они всю старую VB6 и предыдущую функциональность как управляемый код .NET. Мое предположение было бы нет.

Answer 7

Как сказал OwenP, большинство вызовов в пространстве имен Microsoft.VisualBasic являются просто обертками вокруг существующих функций .NET. Так зачем создавать обертки?

Когда был создан VB.NET, Microsoft хотела, чтобы разработчики могли импортировать существующие проекты VB6 в .NET. Это было бы возможно только в том случае, если функции и вызовы методов VB6 имели соответствующие функции в VB.NET. Поэтому они создали пространство имен Microsoft.VisualBasic, чтобы сопоставить эти функциональные возможности VB6 с функциональными возможностями .NET. (Чистое предположение, но оно имеет смысл)

По мере того, как .NET переходил на новые версии, они не могли удалить пространство имен Microsoft.VisualBasic - вероятно, по-прежнему используется большое количество кода. Так что это все еще там.

Кроме того, вы можете писать код VB.Net, даже не используя пространство имен Microsoft.VisualBasic. (И, как подразумевал Кев, вы можете использовать пространство имен Microsoft.VisualBasic из C #.) VB.Net - это просто язык, платформа .NET остается прежней.

Answer 8

Прямым ответом на ваш вопрос будет то, что VB.NET - это такой же «истинный код .NET», как и C #.

Конечно, есть синтаксические функции на обоих языках, которые напрямую не доступны в другом (например, VB.NET имеет некоторые функции XML, встроенные в синтаксис, которых нет в C #), но вы ничего не можете сделать в VB.NET вы не можете делать в C # или наоборот, по крайней мере, насколько мне известно.

Я бы сказал, что если у вас есть опыт работы с VB, то переход на VB.NET, конечно, будет проще, чем на C #.

Answer 9

Насколько я знаю, VB.NET - это, как вы выразились, «настоящий .net» код. Существует множество различных языков (C #, VB.NET, F #, Cobol.NET и т. Д.), Которые все «компилируются» в код IL. Этот IL-код - это то, что фактически выполняется виртуальной машиной .NET и интерпретируется как машинный код. Объекты, с которыми вы взаимодействуете между языками, остаются теми же базовыми объектами .NET.

Например, в C #:

DataTable dt = new DataTable ();

Компилируется с точно таким же IL-кодом, что и эквивалент в VB.NET:

Dim dt as DataTable = new DataTable ()

На самом деле, в инструментах декомпиляции, таких как .NET Reflector, которые смотрят непосредственно на код IL, вы можете заставить его отображать вывод в C # или VB.NET, в зависимости от того, что вам удобнее.

Это также означает, что я могу написать одну библиотеку классов в VB.NET "myVbCode.dll", и она напрямую совместима с библиотекой, написанной на C # "myCSharpCode.dll". На самом деле обе библиотеки будут содержать только скомпилированный код IL.

Могут быть некоторые отдаленные исключения из всего этого, но, по сути, именно так оно и работает.

Answer 10

Код VB.NET не компилируется напрямую в двоичный файл. Он скомпилирован в IL (промежуточный язык) так же, как C #.

Что это означает, что все, что вы собираете в VB.NET, будет многократно использоваться в проектах C # без проблем.

Мне не удалось найти никаких ссылок, непосредственно связанных с тем, что вы спрашиваете. Основная причина в том, что VB.NET является частью новой активно развивающейся среды. Нет никакого плана сделать этот язык устаревшим. Что бы ни говорил другой консультант.