Является ли пространство имен Microsoft.VisualBasic "истинным.NET" кодом?
Моя команда разработчиков готовится начать новый проект. Магазин был "магазином 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?
13 ответов
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 отличается от среды выполнения Visual Basic. Пространство имен Microsoft.VisualBasic.Compatibility используется инструментами, которые обновляют код Visual Basic 6.0 до Visual Basic .NET. Это мост для поддержки функций Visual Basic 6, которые непосредственно не поддерживаются реализацией.NET в Visual Basic. В отличие от среды выполнения Visual Basic, на библиотеку совместимости неявно ссылаются все приложения Visual Basic.NET. При обновлении проекта Visual Basic 6 до Visual Basic.NET мастер обновления добавляет ссылку на Microsoft.VisualBasic.Compatibility.
Классы совместимости не должны использоваться для новых разработок. Пространство имен Microsoft.VisualBasic.Compatibility добавляет уровень сложности вашему приложению Visual Basic.NET и вносит некоторые минимальные затраты производительности, которые могут быть устранены путем перекодирования частей приложения. Кроме того, пространство имен Compatibility часто содержит много классов, которые обертывают COM-объекты, и, как указывалось ранее, зависимость от COM-объектов не так оптимальна, как чисто управляемая реализация.
Используйте.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, не будет сложнее понять мой код.
Подобно некоторым функциям в FCL, часть кода пространства имен Microsoft.VisualBasic написана в управляемом коде, а часть обертывает вызовы в неуправляемый код.
Конечно, нет никакой зависимости от среды выполнения vb6, и, конечно, она не устанавливает тихо среду выполнения vb6 под капотом.
Вы должны загрузить.NET Reflector и взглянуть на код в пространстве имен Microsoft.VisualBasic.
Если вы хотите продолжать использовать функциональность в этом пространстве имен из C#, продолжайте в том же духе, это никуда не исчезнет. Некоторый код может быть помечен как устаревший / устаревший, но я ожидаю, что через 15 лет вы все равно сможете без проблем запускать те же приложения, используя функциональность Microsoft.VisualBasic.
Обновлено: кроме использования отражателя.NET теперь вы можете видеть / отлаживать исходное пространство имен Microsoft.VisualBasic / код Microsoft.VisualBasic.DLL:
Возьмите загрузчик фреймворка и просматривайте код на досуге:
Я считаю, что все они компилируются в один и тот же байт-код.
Вот моя ссылка: http://www.codinghorror.com/blog/archives/000128.html
Утверждение "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, который он выполняет.
Цель Microsoft - сделать VB .NET и C# одним языком с разным синтаксисом. Это правда. Однако изменения всегда происходят, как и новая обработка VB9 XML-литералов. Что он спрашивает, так это переименовали ли они всю старую VB6 и предыдущую функциональность как управляемый код.NET. Мое предположение было бы нет.
Я не очень много сделал с VB.NET (больше с C#), но, насколько мне было известно, они оба компилируются в один и тот же байт-код и, следовательно, идентично интерпретируются средой выполнения.NET, и что они функционально эквивалентны, просто синтаксически разные.
VB.NET, казалось, сильно отличался от VB6, когда я последний раз использовал его.
Как сказал 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 остается прежней.
Прямой ответ на ваш вопрос заключается в том, что VB.NET является таким же "истинным.NET-кодом", как и C#.
Конечно, в обоих языках есть синтаксические функции, которые напрямую не доступны в другом (например, в VB.NET есть некоторые функции XML, встроенные в синтаксис, которых нет в C#), но в VB вы ничего не можете сделать.NET вы не можете сделать в C#, или наоборот, по крайней мере, насколько мне известно.
Я бы сказал, что если у вас есть опыт работы с VB, то переход на VB.NET, конечно, будет проще, чем на C#.
Код VB.NET не компилируется напрямую в двоичный файл. Он скомпилирован в IL (промежуточный язык) так же, как C#.
Это означает, что все, что вы собираете в VB.NET, будет использоваться в проектах C# без каких-либо проблем.
Я не смог найти никаких ссылок, непосредственно связанных с тем, что вы спрашиваете. Основная причина в том, что VB.NET является частью новой активно развивающейся среды. Нет никакого плана сделать этот язык устаревшим. Что бы ни говорил другой консультант.
Насколько я знаю, 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". На самом деле обе библиотеки DLL будут содержать только скомпилированный код IL.
Из всего этого могут быть некоторые исключительные исключения, но в основном именно так все и работает.
Я думаю, что хорошим началом будет документация MSDN, предоставленная Microsoft о VB.net.
http://msdn.microsoft.com/en-us/library/2x7h1hfk.aspx Эта ссылка будет последней версией Visual Studio 2008 о языке.
VB компилирует то же самое, что и C# в CLR, поэтому я не понимаю, откуда ваш консультант.
Существует куча кода.NET, который Microsoft на самом деле просто оборачивает функциональностью COM. Я не гуру лицензирования, но вы всегда можете взять Reflector, взглянуть на это пространство имен и убедиться в этом сами.