.NET и VB6: является ли Interop жизнеспособной стратегией развития?

Question

Является ли Interop между VB6 и .NET жизнеспособной стратегией развития?

Я работаю над приложением VB6, которое взаимодействует с некоторыми сборками .NET, но сочетание «холодного старта» и других проблем сплоченности приводит к негладкому результату.

Answer 1

РЕДАКТИРОВАТЬ - немного сузил мой ответ.

Возможно ли это? Да, конечно.

Я бы порекомендовал это? Конечно, нет!

Стереотипная ситуация (с которой я сталкивался несколько раз) заключается в том, что у вас есть какой-то компонент, написанный на VB6 пять или десять лет назад. Автор покинул компанию, и хотя проблема, которую решает приложение, довольно проста и понятна, само приложение - нет; никто в компании на самом деле не знает, как его поддерживать, и / или он плохо написан, и его сложно поддерживать.

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

Обращение к сообщению MS по адресу: -

http://msdn.microsoft.com/en-gb/dd408373.aspx#migrate3

MS говорит, что переписывание с нуля обычно обходится дороже, чем расширение или автоматическая миграция (с использованием связанных инструментов). Я определенно использовал мастер обновления Visual Basic, чтобы получить отправную точку, хотя мы обычно портировали на C #, а не на VB.NET. Это отличное место для старта, особенно если вы предпочитаете VB.NET.

И наконец: -

Обычно мы рекомендуем [переписывать] только для небольшого числа ситуаций, включая:

• Исходное приложение имеет много проблемы, вытекающие из плохого архитектура, дизайн и / или кодирование практики. Симптомы могут включать в себя плохой масштабируемость или производительность, плохой пользователь интерфейс и трудности в поддержание кода.
• оригинал приложение больше не соответствует потребности бизнеса в значительной области. Требуется смена ядра, например пользовательский интерфейс должен быть доставлен браузером, а не как смарт клиент.
• Компания уже имеет значительные навыки в .NET приобретены на другие приложения и приложения хорошо понято и относительно маленький.
• Исходный код больше не доступны для значительных частей применение.

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

Если портирование вообще не вариант, нам нужна дополнительная информация. Что это за приложение? Что делает VB6? Что делает .NET?

Answer 2

У нас есть большой проект, в который мы начали добавлять функциональность .NET более 5 лет назад, и он работал отлично.Первоначально мы начинали с простого добавления невизуальных компонентов, медленно перемещая бизнес-логику в .NET по многим причинам:

1. В VB6 есть несколько наборов тестов, но на самом деле они не тестируемы (конечно, не через CI)
2. .NET обладает множеством функциональных возможностей, которые очень трудно реализовать в VB6.
3. План состоял в том, чтобы портировать на .NET, когда у нас будет время.

Компоненты .NET (написанные на C #) были настолько успешными, что мы начали писать визуальные компоненты на C # (используя инструментарий взаимодействия и C # Interop toolkit ),а также даже компоненты WPF.Здесь некоторые вещи становятся немного схематичными, иногда с тремя сообщениями сообщений, а компоненты из 3 технологических стеков приводят к причудливости (компоненты исчезают с экрана или неправильно обновляются) и жестоким взломам (sendMessage для определенных компонентов, LockWindowUpdate здесь и там)чтобы все заработало.Однако для приложения, которое, по мнению большинства наших клиентов, написано на WPF, завоевало множество отраслевых наград и ежедневно используется десятками тысяч клиентов, это дань уважения тому, насколько VB6 устойчив (и даже невероятно болезнен) и какХороший рассказ о взаимодействии Com / .NET, созданный Microsoft (черт возьми, Visual Studio 2010 - почти то же самое чудовище Франкена, это просто C ++ Com / C # / и WPF).

Answer 3

Является ли Interop между VB6 и .NET жизнеспособной стратегией развития?

Если вы подчеркиваете слово «стратегия», то я должен настоятельно рекомендовать: «Нет!» Стратегия описывает ваш обычный или ожидаемый план атаки, и смешивание .Net с vb6 не является залогом успеха в этой ситуации. Для этого есть несколько причин, в том числе поиск поддержки более старых инструментов vb6, тот факт, что среда выполнения vb6 больше не обслуживается моей Microsoft, растущая сложность в поиске обученных разработчиков vb6 с течением времени, необходимость поиска разработчиков, знающих обе платформы. .. Я мог бы продолжать и продолжать. Дело в том, что вы не хотите планировать делать это таким образом большую часть времени.

Но давайте немного изменим вашу формулировку:

Является ли Interop между VB6 и .NET жизнеспособным вариантом разработки?

Ах, так лучше. Когда вы попадаете в ситуацию, когда просматриваете какой-то существующий код vb6, или у вас есть опытный программист vb6, которому потребуется некоторое время, чтобы стать опытным в .Net, это может быть приемлемым вариантом в течение ограниченной продолжительности для решения сложившейся ситуации. Это особенно верно, если вы можете объединить его с .Net 4.0, который имеет некоторые функции, чтобы сделать это немного проще.

Только не делайте это частью вашей общей стратегии.

Answer 4

Взаимодействие между VB6 и .NET определенно жизнеспособно (хотя и нежелательно).

В нашей ситуации у нас есть устаревшее ГИС-приложение с несколькими модулями.Мы смогли переместить часть ГИС в .NET и используем взаимодействие для использования существующего кода.

Потребуется несколько лет, чтобы переписать старый код VB6 в C #, и поскольку мы не можем сказатьпользователи, которые так долго ждали (наши контракты работают только в течение года, а затем обновляются), Interop был лучшим решением.Таким образом, мы можем продолжать поддерживать существующий (работающий) код, одновременно переписывая модуль и вводя новые функции (написанные на C #).

С учетом сказанного, я должен признать, что этоне было тривиальной задачей.Нам пришлось взять наше старое приложение VB6 exe и заменить его на ActiveX exe, на который ссылается наш код .NET, и в то же время наш код VB6 имеет ссылки через Interop на некоторый другой код .NET.В некоторые дни я поражаюсь тому, что мы сделали, работают, но это работает, и хорошо!

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

Answer 5

Крейг не говорит о вызове COM из .NET, он говорит о

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

В этомВ этой ситуации ответ на вопрос о жизнеспособности неизбежно будет «НЕТ».

В краткосрочной перспективе вы сталкиваетесь с различными известными и неизвестными проблемами во время выполнения - то, что вы называете «проблемами сплоченности», вызванными тонкими различиями в управляемых и неуправляемыхокружение и ограничения взаимодействия.Вы также ссылались на проблемы с развертыванием.И даже на этапе разработки все мы знаем, что компоненты COM выглядят как черные ящики для отладчиков .NET.Во многих случаях возможно создать и вызвать CCW, но не всегда, и это потребует снижения производительности и технической сложности.

Реальная потеря жизнеспособности заключается в том, что в долгосрочной перспективе приложение VB6 начнет показывать свой собственный набор проблем.Мир технологий медленно, но верно оставляет VB6 позади.Количество готовых и способных разработчиков VB6 сокращается, и в конечном итоге приложения VB6 / COM могут столкнуться с несовместимостью и другими недостатками - с точки зрения их разработки, развертывания и эксплуатации.В конце концов приложения VB6 будут выходить из строя различными способами, и будет трудно найти информацию и ресурсы о том, как их исправить своевременно.Это звучит нежизнеспособно для меня.

Перенесите приложение VB6 в .NET (и минимизируйте также прямое использование COM из уровня вашего приложения);Ты не пожалеешь об этом.Я также обнаружил, что переписывание больших приложений VB6 / ASP.COM для .NET может быть сделано намного эффективнее, если вы используете методологию, которая балансирует ручную работу с автоматическими преобразованиями, вместо того, чтобы настаивать на том, что вы должны полностью игнорировать унаследованный код и делать все "с нуля"».

Answer 6

Я думаю, что приложение .NET, использующее COM-компонент VB6, в некоторых случаях жизнеспособно.

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

В этомПримером прагматичного решения было создание компонента VB6, который инкапсулировал все манипуляции с Office, предоставляя вызывающему упрощенный API без какой-либо объектной модели Office.

Answer 7

Является ли Interop между VB6 и .NET жизнеспособной стратегией развития?

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