До каких пор будут работать приложения VB6 ── состояние поддержки среды выполнения и практичный путь миграции на .NET

«До каких пор будет работать эта система на VB6?» — один из самых частых вопросов на консультациях по устаревшим системам.

Ответ на удивление однозначен: Microsoft официально опубликовала политику поддержки. Но её содержание асимметрично — «среда выполнения ещё какое-то время проработает, но опоры со стороны разработки уже нет». Без правильного понимания этой асимметрии легко скатиться к одной из двух крайностей: «раз ещё работает, значит всё в порядке» или «нужно всё переделывать прямо сейчас».

В этом блоге в статье «Продление жизни и миграция бизнес-приложений VB6 / Access ── таблица решений «оставить, обернуть или заменить»» мы систематизировали подход к тому, как поступить с активами VB6. Эта статья — продолжение: после того как решение «заменить (мигрировать)» принято — или чтобы его принять, — она углубляется в то, как на практике провести миграцию с VB6 на .NET.

1. Сначала — суть

• Поддержка IDE VB6 (среды разработки) завершилась 8 апреля 2008 года. Больше не существует поддерживаемого способа создавать или сопровождать приложения VB6, и Microsoft настоятельно рекомендует переходить на современные технологии.¹
• С другой стороны, среда выполнения VB6 поддерживается «пока поддерживается версия Windows, с которой она поставляется». В список охватываемых версий ОС входят Windows 11, Windows 10 и Windows Server 2025, а цель состоит в том, чтобы существующие приложения просто продолжали работать (It Just Works).² Иными словами, ответ на вопрос «до каких пор будет работать» звучит так: если говорить только об исполнении — пока поддерживается сама Windows.
• Однако эта поддержка ограничена устранением серьёзных регрессий и критических проблем безопасности в существующих приложениях. Кроме того, среда выполнения предназначена только для 32-битных систем, а в 64-битной Windows поддерживается лишь внутри среды WOW64.²
• Настоящий риск — не «перестанет работать», а утрата возможности что-либо исправить. Получить и сохранить IDE с каждым годом становится всё труднее, поддержка производителей используемых OCX-компонентов прекращается, а люди, ещё способные писать на VB6, уходят на пенсию или меняют работу. Все три процесса развиваются независимо от срока поддержки самой Windows.
• Существует три общих подхода к миграции: полная переписка, автоматическое преобразование и поэтапная миграция. Первое, что нужно решить, — не подход, а инвентаризация: прежде чем выбирать подход, нужно оценить количество экранов, внешних интеграций, объём OCX-компонентов и объявлений API.
• В качестве целевого языка миграции для всего нового кода рекомендуется C#. Microsoft официально заявила, что VB.NET (Visual Basic) находится на пути стабильного развития, без нового синтаксиса и без расширения на новые типы нагрузок.³

2. Точный ответ на вопрос «до каких пор будет работать» ── как читать политику поддержки

Политика поддержки VB6 от Microsoft описывает VB6 через три компонента.²

В таблице охватываемых версий ОС для Windows 11, Windows 10 и Windows Server с 2012 по 2025 годы явно указано «среда выполнения: поддерживается», «IDE: не поддерживается».²

Есть три ключевых момента для правильного прочтения этой политики.

Во-первых, поддержка среды выполнения полностью подчинена жизненному циклу Windows. Не существует отдельной даты под названием «дата окончания поддержки среды выполнения VB6» — окончание поддержки используемой версии Windows и есть срок как таковой.

Во-вторых, содержание поддержки ближе к гарантии того, что «всё продолжит работать», чем к чему-либо ещё. Обрабатываются только серьёзные регрессии (когда обновление ОС ломает существующее приложение) и критические проблемы безопасности; отдельные расследования или улучшения функциональности сюда не входят.²

В-третьих, приложения VB6 и впредь смогут существовать только как 32-битные процессы. Среда выполнения предназначена только для 32-битных систем, а на 64-битных ОС поддерживается лишь внутри среды эмуляции WOW64.² В момент, когда возникает необходимость взаимодействовать с исключительно 64-битной DLL или SDK, один процесс уже не может решить задачу самостоятельно. О том, как преодолеть это препятствие, мы рассказали в статье «Пример COM-моста для вызова 64-битной DLL из 32-битного приложения».

3. «Работает» и «поддерживаемо» — разные вопросы

Если смотреть только на политику поддержки, может показаться, что «спешить некуда». Но на практике среда разработки и сопровождения разрушается гораздо раньше, чем среда выполнения.

• Невозможно раздобыть IDE. IDE VB6 не поддерживается на современных ОС, и поддерживать официальный способ её получения и установки с каждым годом всё труднее. Ситуация, когда «во всей компании есть только одна машина, на которой ещё можно что-то исправить», встречается нередко.
• Поддержка производителей сторонних OCX-компонентов прекращена. Сама политика поддержки прямо указывает, что элементы управления сторонних производителей относятся к зоне ответственности поставщика.² Нередко OCX-компоненты для таблиц или отчётов уже невозможно получить, и подход, который мы систематизировали в статье «Как сегодня поступать с ActiveX / OCX», применим здесь напрямую.
• Исчезают люди, способные писать код. Это не проблема языковой спецификации, а кадровая проблема. Новых инженеров, изучающих VB6, практически нет, поэтому число людей, способных заниматься сопровождением, только сокращается.
• Смежные требования упираются в стену 32-бит. Новые SDK для оборудования, библиотеки аутентификации, облачные интеграции всё чаще исходят из предположения о 64-битности и .NET, и требований, которые невозможно встроить в процесс VB6, становится всё больше.

Иными словами, «до каких пор будет работать» — лишь половина проблемы. Вторая половина: «останутся ли, когда потребуется следующее исправление, люди и среда, способные его сделать». План миграции нужно составлять не после того, как что-то сломается, а пока ещё остаются люди и среда, способные всё исправить.

4. Таблица решений для подходов к миграции

Даже после принятия решения «заменить» способов реализации остаётся достаточно много. Приведём обзор основных подходов.

Выбор определяется не только количеством строк кода. Сама Microsoft, помимо официальных руководств, при миграции направляет пользователей к партнёрам по обновлению и миграции (включая поставщиков инструментов миграции)¹, так что механическое преобразование — вполне реальный, рабочий вариант. Тем не менее, независимо от выбранного подхода, инвентаризация из следующей главы остаётся общим обязательным условием.

Отметим, что практические аспекты выбора варианта «сохранить как есть + документировать» (фиксация среды выполнения, резервное копирование, способ принятия риска) рассмотрены в предыдущей статье о VB6 / Access.

5. Инвентаризация перед миграцией ── что изучить прежде, чем трогать код

Точность оценки и выбора подхода полностью зависит от точности инвентаризации. Как минимум составьте списки следующего.

1. Список экранов и отчётов ── количество форм, реально используемые экраны (миграция неиспользуемых экранов — потраченные впустую усилия), типы отчётов и место их вывода (прямая печать на принтере или через Excel)
2. Список внешних интеграций ── какая из технологий ADO/DAO/RDO используется для базы данных и к чему она подключается, файловый ввод-вывод, последовательная или сокетная связь, вызовы других систем
3. Список ссылок на OCX / ActiveX / COM ── их можно механически извлечь из ссылок файла проекта (.vbp). Возможность получения каждого компонента и наличие альтернативы напрямую влияют на выбор подхода
4. Список объявлений Win32 API (операторов Declare) ── классифицируйте каждое по назначению API (печать, чтение/запись INI-файлов, манипуляции с окнами и т. д.) и определите, можно ли заменить его стандартной функциональностью .NET
5. Бизнес-правила, существующие только в коде ── обработка округлений, даты закрытия периодов, исключения по конкретным контрагентам и тому подобное. Места, где «никто не знает, почему это написано именно так», — как раз то, где чаще всего заводятся баги после миграции
6. Наличие способа тестирования ── с чем сравнивать поведение после миграции, чтобы подтвердить его корректность. В большинстве случаев сверка с выходными данными старой системы (отчётами, CSV, содержимым базы данных) — самый практичный способ проверки

Эта инвентаризация не пропадёт впустую, даже если в итоге выбрана не полная переписка. Более того, обычно именно по результатам инвентаризации обнаруживается зацепка для поэтапной миграции — «мы думали, что нужна полная переписка, но на самом деле основную логику можно перенести на сторону базы данных» или «достаточно сначала перенести только эти десять экранов, чтобы преодолеть стену 64-бит».

6. Основные точки несовместимости VB6 и .NET

VB6 и VB.NET/C# — языки, более далёкие друг от друга, чем можно подумать по названиям. И при механическом преобразовании, и при ручной переписке следующие различия неизбежно потребуют проектных решений.

Важно здесь не позволить объёму несовместимостей подавить вас настолько, чтобы полная переписка казалась единственным вариантом. Напротив, сам факт, что активы в левой части этой таблицы (VB6) до сих пор корректно работают, — лучшая спецификация, какая только может быть при миграции. Запуск старой системы параллельно как «работающей спецификации» и сверка выходных данных по ходу дела на практике оказывается самым надёжным путём.

7. Практические паттерны поэтапной миграции

При миграции без остановки бизнеса ключевым становится то, как сосуществуют старая и новая система. Рассмотрим три типичных паттерна.

7.1 Сначала перенести слой данных

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

7.2 Строить новые функции и экраны на .NET, связывая их через COM-взаимодействие

Это схема, при которой существующие экраны VB6 остаются как есть, а новая функциональность строится на .NET и сосуществует с ними. Возможны два направления.

• Вызывать компоненты на стороне .NET из VB6: если открыть класс .NET как COM, VB6 сможет ссылаться на него как на обычный COM-компонент. О том, как открывать его типизированно даже на .NET 8 и более поздних версиях, мы рассказали в статье «Типизированный вызов DLL на .NET 8 из VBA ── dscom и TLB»; тот же подход применим, даже если вызывающая сторона — VB6, а не VBA.
• Вызывать активы на стороне VB6 из .NET: ActiveX DLL, созданная в VB6, может быть подключена из .NET через COM-взаимодействие. Это применяется, когда логику хочется сохранить целиком, модернизируя на .NET сначала только экраны. Однако ограничение 32-бит при этом сохраняется, поэтому такой вариант следует рассматривать как мост на период миграции, а не как постоянное решение.

7.3 Разделить процессы и связать их между собой

Размещение старого и нового в одном процессе через COM-взаимодействие упирается в ограничения, связанные с разрядностью (32-бит/64-бит) и распространением сбоев. Когда нужна новая 64-битная функциональность или желательно изолировать сбои старой и новой части друг от друга, их разделяют на отдельные процессы и связывают через файлы, именованные каналы, связь через localhost и тому подобное. Варианты межпроцессной интеграции мы обобщили в статье «Таблица решений по IPC в Windows», а конкретный пример моста 32-бит→64-бит — в «Примере COM-моста».

Принцип, общий для всех паттернов: «собрать границу между старым и новым в одном месте и зафиксировать формат данных, пересекающих эту границу». Если границы бесконтрольно множатся от экрана к экрану или от функции к функции, стоимость периода сосуществования съедает всю пользу от миграции.

8. Целевой язык миграции ── C# или VB.NET

Часто кажется, что «раз переходим с VB6, естественным выбором будет VB.NET», но с учётом текущей языковой стратегии Microsoft всё не так просто.

Официальная языковая стратегия позиционирует Visual Basic (VB.NET) как «понятный и привычный язык, сохраняющий стабильный дизайн», и прямо заявляет, что новые функции, как правило, ограничиваются потреблением (consumption-only), новый синтаксис добавляться не будет, а расширения на новые типы нагрузок не произойдёт. При этом инвестиции в ключевые сценарии, такие как Windows Forms и библиотеки, а также улучшение опыта разработки в Visual Studio, как утверждается, продолжатся.³

С точки зрения миграции это можно прочитать следующим образом.

• Даже если выбрать VB.NET, существующие сценарии (бизнес-приложения на WinForms) в обозримом будущем будут продолжать работать без проблем. Для команд с большим числом людей, имеющих опыт работы с VB6, где близость синтаксиса снижает затраты на обучение, это разумный выбор.
• Тем не менее, в качестве основы для всего, что пишется заново отныне, рекомендуется C#. Его язык и экосистема продолжают развиваться, а предложение примеров, библиотек и кадров сконцентрировано вокруг C#. Это выбор, сделанный для того, чтобы через десять лет не повторить проблему «некому поддерживать VB6» в виде проблемы «некому поддерживать VB.NET».
• В качестве компромисса можно также принимать результат работы инструмента преобразования на VB.NET, а новую разработку вести на C#. В .NET сборки обоих языков могут ссылаться друг на друга, поэтому смешение языков само по себе препятствием не является.

По выбору фреймворка интерфейса (WinForms / WPF / WinUI) см. «Таблицу решений для WinForms, WPF и WinUI», а о том, что нужно проверить при миграции напрямую на текущий .NET, минуя .NET Framework, — «Чек-лист перед миграцией с .NET Framework на .NET». Специально принимать .NET Framework 4.8 в качестве новой цели при миграции с VB6 нет никакого смысла, если только этого не требуют ограничения используемых библиотек.

9. Итоги

• Ответ на вопрос «до каких пор будет работать VB6» такой: среда выполнения поддерживается, пока поддерживается сама Windows (включая Windows 11). Но поддержка IDE завершилась ещё в 2008 году, поэтому официальной опоры для пересборки или исправления кода уже нет — это асимметричное положение дел.²¹
• Настоящий срок определяется не операционной системой, а тем, остаются ли среда и люди, способные всё исправить. Составляйте план миграции не после того, как что-то сломается, а пока старую систему ещё можно использовать как «работающую спецификацию».
• Есть три подхода: полная переписка, автоматическое преобразование и поэтапная миграция. Прежде чем выбрать один из них, проведите инвентаризацию экранов, внешних интеграций, OCX-компонентов, объявлений API и бизнес-правил, существующих только в коде.
• Для миграций, которые не могут остановить бизнес, используйте приоритет слоя данных, COM-взаимодействие или разделение процессов, чтобы обеспечить сосуществование старого и нового, и соберите границу в одном месте.
• Для всего, что пишется заново, рекомендуется C#. Курс на стабильность VB.NET — официальная политика³, а C# имеет преимущество как основа для долгосрочного сопровождения.

Похожие статьи

• Продление жизни и миграция бизнес-приложений VB6 / Access - таблица решений «оставить, обернуть или заменить»
• Как сегодня поступать с ActiveX / OCX - таблица решений «оставить, обернуть или заменить»
• Пример COM-моста для вызова 64-битной DLL из 32-битного приложения
• Типизированный вызов DLL на .NET 8 из VBA - dscom и TLB
• Чек-лист перед миграцией с .NET Framework на .NET
• Таблица решений для WinForms, WPF и WinUI
• Что такое VBA - ограничения, перспективы и реалистичные паттерны миграции

Смежные области консультирования

KomuraSoft LLC (合同会社小村ソフト) занимается инвентаризацией существующих активов, включая VB6, и разработкой стратегии миграции, проектированием и реализацией архитектур сосуществования старой и новой систем через COM-мосты и разделение процессов, а также поэтапной заменой систем на .NET.

• Поддержка использования существующих активов и миграции
• Доработка и сопровождение существующего программного обеспечения Windows
• Разработка приложений для Windows
• Техническая консультация и ревью проекта
• Связаться с нами

Справочные ссылки

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Будут ли приложения VB6 работать в Windows 11?

Да, они находятся в рамках поддержки. Согласно политике поддержки Microsoft, среда выполнения VB6 (msvbvm60.dll и сопутствующие файлы) остаётся поддерживаемой, пока поддерживается версия Windows, с которой она поставляется, а в список охватываемых версий ОС входят Windows 11, Windows 10 и Windows Server 2025. Однако эта поддержка ограничена устранением серьёзных регрессий и критических проблем безопасности в существующих приложениях. Кроме того, среда выполнения VB6 предназначена только для 32-битных систем, а в 64-битной Windows она поддерживается лишь внутри среды совместимости WOW64.

Можно ли завершить миграцию с VB6 на .NET, используя только инструмент автоматического преобразования?

Правильнее исходить из того, что нельзя. Инструменты преобразования могут снизить трудозатраты на переписывание определений экранов и простой логики, но такие вещи, как обработка ошибок через On Error, код, зависящий от типа Variant или свойств по умолчанию, элементы управления ActiveX и объявления Win32 API, требуют ручных проектных решений и доработки. Вместо того чтобы сразу внедрять в продакшен необработанный результат работы инструмента, нужно оценивать весь проект целиком, включая 'человеческую доработку после преобразования', и заранее определить способ проверки результата преобразования — например, параллельную работу или сравнение выходных данных.

Что выбрать целевым языком миграции — VB.NET или C#?

Для всего, что пишется заново, рекомендуется C#. Языковая стратегия Microsoft позиционирует Visual Basic (VB.NET) как язык, сохраняющий стабильный дизайн, и прямо заявляет, что новый синтаксис добавляться не будет и расширения на новые типы нагрузок не произойдёт. Инвестиции в существующие сценарии, такие как Windows Forms, продолжатся, поэтому VB.NET не станет непригодным для использования, но как основа для кода, который придётся поддерживать следующие десять лет, C# — язык и экосистема которого продолжают развиваться — имеет преимущество с точки зрения доступности кадров. Команды с большим числом разработчиков, имеющих опыт работы с VB6, вполне могут разумно выбрать VB.NET благодаря близости синтаксиса.

Что нужно сделать в первую очередь перед полной переписью?

Перед тем как писать хотя бы одну строку кода, необходимо провести инвентаризацию. А именно: список экранов и отчётов, список внешних интеграций (базы данных, файлы, последовательная связь, другие системы), список используемых элементов управления OCX/ActiveX и COM-компонентов, список объявлений Win32 API (операторов Declare), а также перечень бизнес-правил, существующих только в коде. Результаты этой инвентаризации очень часто показывают, что поэтапная миграция — выделение лишь части системы или перенос сначала слоя данных — реалистичнее, чем полная переписка.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.