Есть ли какая-то причина, по которой VB6 нельзя перенести на .Net?

Question

Я не говорю о переносе приложения VB6 на .Net (об этом много говорилось здесь).

Мне просто интересно, если вы можете сделать IronPython, IronRuby, Phalanger, H # и т. Д., Есть ли техническая причина, которая помешает созданию VB6.Net?

Я бы подумал, что там будет МНОГО денег .

ОБНОВЛЕНИЕ Извините за всех пуристов, я ЗНАЮ, что VB.Net «лучше», но когда у вас есть сотни тысяч строк кода, это просто недостаточно аргумент. Здесь - это пост Джоэла, который послужил источником вдохновения для этого вопроса.

Answer 1

1/2 Да и 1/2 Нет. Полная 100% -ная работа будет довольно трудным преобразованием, поскольку предположения VB6 построены на COM. Предположения COM не совпадают с .NET. Где вы действительно столкнетесь с проблемой, будет эмулировать VB6 IDE.

Гораздо проще написать компилятор, совместимый с текстом Vb6. Важно помнить, что вы можете писать сборки, которые могут адаптировать определенные функции VB6 к .NET. Например, объект принтера, графический объект vb6. Доступ к файлу и т. Д. И т. Д. Также существует проблема с форматом Wonky Form, и вам потребуется конвертер для файла FRX. У вас все еще будут проблемы с поведением, но теоретически вы можете минимизировать это в библиотеках поддержки VB6.

Ничто не мешало Microsoft сделать это. Это было высокомерие оригинальной команды .NET, которое привело к тому, что они должны были «исправить» VB6. Да, как язык VB.NET имеет много интересных функций по сравнению с VB6. Но тогда у VB6 было много интересных функций по сравнению с QuickBASIC. Но с VB6 я могу взять код QuickBASIC и выгрузить его в VB6 и иметь разумный шанс заставить его работать. Особенно для модулей, где нет ничего, кроме бизнес-логики. Это не то же самое, что переход от VB6 к VB.NET. Большинство проблем вызвано изменением целого числа с 16 бит на 32 бит.

Потеря даже минимальной обратной совместимости была и остается проблемой. По мере того, как Ruby, Python и другие языки переносились на .NET, произвольный характер вариантов, предложенных исходной командой VB.NET.

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

Некоторые с макушки головы

1) Введите оператор OPTION INT BASE. По умолчанию целые числа будут 32-битными, а long - 64-битными. Однако, если вы используете OPTION INT BASE 16. Тогда Integer будет компилироваться в Int16, а Longs будет компилироваться в Int32. Это потребует также некоторых модификаций Intellisense. Поэтому, когда он запрашивает мета, в подсказке указывается правильный тип базы. Поймите, что в метаданных все есть Int16s и Int32s.

2) Иметь надежные сборки принтера, экрана и графического помощника vb6. У Microsoft есть 3/4 реализации объекта Printer. Там находится объект Vb6 Graphis, который можно извлечь с помощью рефлектора .NET и использовать отдельно. Но есть много работы по подгонке и отделке, которые необходимо сделать.

3) У опции есть возможность использовать оригинальные ключевые слова VB6, использующие эти вспомогательные сборки. Компилятор преобразует их в вызовы вспомогательной сборки.

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

Конечно, сейчас в сообществе Microsoft Basic есть большой разрыв. Ожидайте много статических и жалоб, если эти опции будут добавлены. Возможно, если бы я был менеджером VB.NET, я бы преобразовал компилятор VB.NET в компилятор VB6.NET, чтобы минимизировать это. Это зависит от того, повлияет ли этот параметр на текущую версию VB.NET.

Подробнее о проблемах можно прочитать здесь .

Answer 2

Технически я думаю, что это будет сложно. И я не думаю, что на это будет спрос.

Люди инвестируют денег и времени в инструменты для переноса кода VB6 в .Net, но не в создание "VB6.Net". Клиенты должны получить свои активы кода VB6 для поддерживаемой платформы программирования . Лично мне нужно было бы убедить, что порт VB6 будет надежным и поддерживаемым.

Вместо этого поставщики миграции работают над такими вещами, как библиотеки времени выполнения. Например, VBMigration.COM объявил в этом месяце они добавляют оболочку для ADO.Net. Это набор нативных классов .NET, которые ведут себя точно так же, как их аналоги из ADODB, но используют ADO.Net за кулисами. Если вы можете заставить .Net эмулировать поведение во время выполнения VB6, как это, нет необходимости портировать сам язык VB6.

РЕДАКТИРОВАТЬ: я только что натолкнулся на другая идея : создать клон VB6, который поддерживает несколько платформ, например RealBasic : Windows, Mac, Linux ... Может быть некоторый спрос на это. Вам все равно нужно убедить людей, что вы продолжите поддерживать язык.

Answer 3

Я слушал подкаст DotNetRocks с Полом Виком пару лет назад. Это парень, который был в команде VB6. Иирк, ему был задан похожий вопрос. Он ответил, что это было просто слишком сложно, потому что за годы разработки кодовая база VB6 (а ранее vb5, 4, 3, 2, 1) приобрела огромное количество пустяков, которые было бы чрезвычайно трудно перенести на совершенно новую платформу. .

Answer 4

Зачем вам беспокоиться, когда есть VB.NET и инструменты для помощи в миграции с VB6 ? Этот факт сводит на нет ваши денежные аргументы. Конечно, это, вероятно, технически возможно , но это будет большая задача. Барьеры не технические, а финансовые и мотивационные.

Answer 5

Полагаю, что оно абсолютно может быть перенесено. Если вы думаете, что в этом есть деньги (и вы вполне можете быть правы), приступайте к работе. ; -)

Вне себя, я не вижу причины, которая мешает этому, и я довольно долго работал с VB6 и .NET. С другой стороны, я не вижу много пользы от этого. Интеграция VB6 в значимой степени с остальной частью фреймворка может быть довольно сложной; VB6 просто не хватает многих функций, которые делают это сложнее, чем необходимо. Портирование приложений VB6 в среду .NET (путем переноса VB6 в .NET), таким образом, не дает ощутимых преимуществ. Кроме того, новый код .NET может взаимодействовать с существующим кодом VB6 и наоборот.

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

Answer 6

Visual Basic 4, 5 и 6 были основаны на COM. COM определяет двоичный интерфейс между компонентами (ABI) и объектной моделью (включая управление памятью).

.NET также определяет эти вещи, но принципиально иным образом (например, GC, а не подсчет ссылок).

Так как VB6 основывается на способе работы COM, может иметь место несоответствие импеданса с «чистым .NET», как вы видите в C ++ / CLI, где вы должны обрабатывать .NET и собственные объекты и типы немного по-другому .

Помните, что вы можете использовать компоненты VB6 из .NET и наоборот через COM-взаимодействие, поэтому возможно постепенное изменение.