Стратегия преобразования приложения VB6 к.NET

Частичный подход, который вы описываете, создаст дополнительную работу, потому что вы будете пытаться заставить код VB6 и .Net сосуществовать, что чревато проблемами для чего угодно, кроме простейших приложений. Где-то по дороге вы, вероятно, наткнетесь на ловушку, которая может стать препятствием.

Я бы порекомендовал следующий подход (основанный на успешном переносе приложения VB6 на 600 000 строк в .Net):

Убедитесь, что ваша существующая база кода VB6 правильно контролируется версиями и помечена. Напишите регрессионные тесты для ваша база кода VB6, желательно автоматизированная. Возьмите известную базовую линию метки кода VB6 и перенесите ее как единое целое в .Net. Ваши клиенты продолжают использовать версию VB6. Запустите регрессионные тесты для перенесенного кода. Когда все тесты пройдены, примените к коду .Net любые изменения VB6, которые произошли с тех пор, как вы взяли исходный базовый уровень VB6. Доставьте в UAT, а затем действуйте.

Если бы это был я, я бы сразу сорвал пластырь. Я не вижу никакой пользы в наличии промежуточного состояния [.NET Forms и COM-interop] для вашего приложения, потому что это просто добавляет ненужной сложности.

Есть много советов по стратегиям конверсии.

• Ознакомьтесь с другими вопросами с меткой vb6-migration .
• Я настоятельно рекомендую страницу Microsoft о различных стратегиях конверсии.
• Рассмотрите коммерческие инструменты миграции, особенно если у вас мало времени для разработчиков.
  • Вспомогательный инструмент для обновления Mobilize.Net (конвертирует в C # и vb.net)
  • Партнер VBMigration (преобразуется в vb.net)

Стали бы вы выполнять большое комплексное преобразование данных по одной таблице за раз, при этом ваши системы использовали бы одну, другую или обе модели данных одновременно в течение длительного периода времени? Очевидно, что это чревато проблемами и сложностями. Лучшая практика для больших преобразований данных - это выполнять их таким образом, чтобы привести всю модель данных к желаемому конечному состоянию за минимально возможный срок. То же самое относится и к масштабным преобразованиям кода. Выполнять их по частям в течение длительного периода времени - значит навлекать на себя неприятности с точки зрения увеличения трудозатрат и технического риска.

IMO, лучший подход - сформулировать конечные стандарты разработки и архитектуры для кода .NET, а затем инвестировать в процесс, который поможет вам эффективно переписать систему таким образом, чтобы она соответствовала этим стандартам и точно сохраняла унаследованные бизнес-правила и функциональное поведение. Длительные переходы и сложные гибридные/промежуточные решения в лучшем случае являются лишь временной мерой, в худшем - приводят к проблемам бизнеса и провалу проекта. Лучший подход позволит вам перенести унаследованное программное обеспечение на новую платформу в виде внутренне согласованных, независимых и хорошо сформированных частей. Более того, перенос меньшим количеством больших частей будет более эффективным и менее разрушительным, чем множество маленьких частей.

Ключом к тому, чтобы сделать этот подход жизнеспособным, является использование инструментов нового поколения для перехода с VB6/COM/ASP на .NET, которые позволяют итеративно выверять, настраивать и проверять автоматизированный процесс перезаписи, который уравновешивает автоматическое преобразование и ручную работу. Инструменты от Great Migrations специально разработаны для реализации этой методологии. Мы называем ее "переписывание с помощью инструментов". Мы использовали этот подход в нескольких крупных проектах миграции, включая обновление портфеля приложений из 1.2M LOC VB6/COM до реорганизованного C#/.NET.

Отказ от ответственности: я работаю в компании Great Migrations.