Лучшая стратегия перехода от VB6 к .NET.

Question

Моя компания имеет тонны legacy приложения, написанные на VB6.

Мы находимся в переходах из движущихся приложений VB6 в .NET (3.5).

Что было бы лучшей стратегией для перемещения формы VB6 в .NET?

ПРИМЕЧАНИЕ: Ниже обновление должно перейти к «Управление проектами» и не имеет ничего общего с основным вопросом.

[UPDATE]: Спасибо за ваши отзывы до сих пор
В настоящее время существует более вопрос всплывал являются

1. , как вы отнесете разработчиков для разработки новых приложений?
2. Должно ли существовать специальное одноразовое подразделение по модернизации, которое преобразует унаследованные приложения в новые? Или должен каждый разработчик участвует в процесс преобразования?
3. Должны ли только старшие разработчики участвовать в конверсии? Junior разработчиков? или смешанные?

Похоже, чем больше я думаю о этой проблемы, больше вопросов просто показать вверх.

Answer 1

Очевидно, что это важное мероприятие, которое потребует много работы.
Так что я бы посоветовал рассматривать его как очень долгосрочный проект.

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

Как только это будет согласовано держателями кола, разработайте прототипную систему, чтобы проверить свои предположения, где вы можете попробовать C# vrs VB.net или MVC vrs Webforms. Я бы назначил для этого ваших лучших разработчиков.

Затем запустите одну из своих небольших устаревших систем и создайте основные компоненты, которые вы будете повторно использовать в других областях.
На этом этапе, начните с ваших более старших разработчиков, но каждый должен принять участие и ознакомиться с новой структурой.
Это гарантирует, что каждый будет обучен в одно и то же время, и никто не останется позади.
В зависимости от того, сколько приложений у вас есть, я бы поменял разработчиков, поэтому все системы могут пригодиться.

Также все новые работы должны выполняться на языке .net не в VB6.

Постепенное преобразование каждого из ваших устаревших приложений. (я бы преобразовал их только в том случае, если они меняются, или если есть явная польза для их обновления.)

Это должно дать вам прочную основу для использования в будущем, в то же время гарантируя, что пользователям не мешает ваша функциональность миграция.

Например:
Я работал в компании, где было около 40 приложений VB.
Со временем мы перенесли все это на C#, и теперь (через 5 лет) у нас есть примерно 150 приложений C# (все в .net 2.).

Все они имеют общую структуру, что упрощает их обслуживание и расширяется там, где это необходимо.

Answer 2

Я хотел бы начать с инструментами Microsoft:

http://msdn.microsoft.com/en-us/library/aa480541.aspx

Answer 3

Смотреть это:
https://stackoverflow.com/questions/507291/should-we-select-vb-net-or-c-when-upgrading-our-legacy-apps

Конечно, C# против VB.Net только одна его часть.

Например, если вы хотите использовать эту возможность для перемещения этих приложений в интрасеть, если вы еще этого не сделали. Или насколько глубоко вы хотите вникать в стек Microsoft. Является ли Winforms достаточно или вы хотите использовать WPF, например.

Answer 4

Вы можете найти следующую статью полезной: http://www.vsj.co.uk/articles/display.asp?id=756

Answer 5

Попробуйте заменить базовую функциональность с COM позволило .NET библиотеки. «Пустотелые» существующие приложения VB6, поменяв функциональность на .NET по битам.

Остерегайтесь полной перезаписи. Хотя они заманчивы «потому что это чистый срез» - обычно безумие впереди! В качестве подготовки прочитайте «Эффективно работая с устаревшим кодом» Майкла Перса. Хотя книга специально не переходит в «переход от одного языка к другому», это действительно показывает много подводных камней в реальном мире, с которыми вы столкнетесь.

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

Answer 6

Это адаптация моего answer к аналогичному вопросу.

Преобразование больших программ автоматически является лучшим выбором, чем переписывание. Это обычная ошибка, чтобы оптимистично переписать большое программное обеспечение, сделать хороший ранний прогресс, исправляя некоторые из известных недостатков старой архитектуры, а затем увязнуть в функциональности, которую вы только что принимали как должное года. На этом этапе ваше управление начинает нервничать, и все может стать очень неудобным.

... и вот блог на Microsofty что agrees with me:

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

Это отличный Microsoft page рекомендует две миграцию третьей стороны инструментов, как лучше, чем недостаточен встроенным в VB.NET обновления мастера - Artinsoft и CodeArchitects VBMigration. Artinsoft написала встроенный мастер обновления VB.NET, это их улучшенная версия. И CodeArchitects был основан Франческо Балена, который написал некоторые из classic books на VB6 и VB.NET.

На той же странице Microsoft также говорит:

Выполнение полного переписывания для .NET является гораздо более дорогостоящим и трудным сделать хорошо [чем преобразование] ... мы бы только рекомендовать этот подход для небольшого числа ситуаций.

---

EDIT: Sung говорит в комментариях: «Я не большой поклонник автоматической генерацией кода, потому что это труднее отлаживать изначально и может занять столько же времени, сколько потребуется, чтобы переписать все это» , Я должен не согласиться. В общем, я тоже не поклонник генерации кода, но в этом случае полученный код будет структурирован идентично вашему оригинальному VB6 и должен быть почти полностью функциональным. Я еще не пробовал эти инструменты, но с их customertestimonials это обещание выполнено.

И я повторяю совет Microsoft чуть выше, основываясь на своем опыте оказания помощи многих миграций - «полная перезапись гораздо более дорогостоящим и трудным, чем преобразование [курсив мой]» - плоское противоречие в предположении, что оно может занять одно и то же время. Если вы хотите улучшить структуру VB6, миграция, то постепенный рефакторинг, вероятно, будет намного более экономически выгодным, чем переписывание.