Как долго проработают приложения VB6 — поддержка среды выполнения и миграция на .NET

«Как долго ещё проработает эта система на VB6?» — один из самых частых вопросов на консультациях по действующим системам.

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

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

Термины, которые встречаются в статье

Читатель может не застать эпоху VB6, поэтому сначала зафиксируем словарь.

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#. По официальной линии VB.NET (Visual Basic) держит стабильный курс: нового синтаксиса и расширения на новые типы нагрузок не будет.⁵

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 22, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

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

Политика поддержки VB6 от Microsoft разбирает продукт на три части.⁴

В таблице охватываемых ОС для 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 при миграции, помимо официальных руководств, направляет к партнёрам по обновлению и миграции, включая поставщиков инструментов³, так что машинное преобразование — рабочий, существующий вариант. Независимо от схемы общая обязательная работа — инвентаризация из следующей главы.

4.1 Что конкретно имеется в виду под «конвертером»

«Инструмент автопреобразования» звучит как один класс продуктов, но Microsoft публикует страницу, где партнёрские продукты для VB6 названы прямо. Формулировка: бесплатные и платные инструменты и решения партнёров, которые помогают полнее перейти с Visual Basic 6.0 на Visual Basic .NET. Перечислены три.⁶

Это краткий пересказ формулировок со страницы Microsoft, а не наша рекомендация и не гарантия. Выбирайте только после прогона на своём коде. Смотреть стоит на следующее.

Последний пункт часто пропускают. Пока идёт миграция, на стороне VB6 всё равно чинят сбои. Если инструмент умеет преобразовать только один раз, каждую такую правку придётся вносить руками и в старое, и в новое.

Практику варианта «оставить как есть и задокументировать» (фиксация среды выполнения, резервные копии, как принимают риск) мы разбирали в предыдущей статье про 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-битный барьер уже обойден».

5.1 Что стоит за «можно извлечь автоматически» — ссылки из .vbp

В пункте 3 сказано: «из ссылок .vbp можно извлечь автоматически». Вот как именно.

Файл проекта (.vbp) — текстовый файл в ASCII. В официальной документации Microsoft есть пример содержимого; ссылки записываются одной строкой такого вида.⁷

Type=Exe
Form=B_Form.frm
Reference=*\G{00020430-0000-0000-C000-000000000046}#2.0#0#..\..\..\WINDOWS\SYSTEM\STDOLE2.TLB#OLE Automation
Form=A_Form.frm
Module=CModule; C_Module.bas
Class=DClass; D_Class.cls
Startup="BForm"
Name="Project1"

Значение Reference= разделено #: GUID (идентификатор библиотеки типов) → версия → локаль → путь к файлу → описание (имя библиотеки). В примере описание — OLE Automation. Элементы ActiveX (OCX), поставленные на форму, пишутся строками Object=. Соберите оба вида строк — получите список внешних компонентов, от которых зависит проект.

Если проектов десятки, выгрузить всё разом можно таким скриптом.

# Из всех .vbp в папке и подпапках вынуть строки ссылок на компоненты и сохранить в CSV
# Среда: Windows PowerShell 5.1
Get-ChildItem -Path . -Filter *.vbp -Recurse | ForEach-Object {
    $project = $_.FullName
    Get-Content -LiteralPath $project | Where-Object {
        $_ -like 'Reference=*' -or $_ -like 'Object=*'
    } | ForEach-Object {
        $kind, $value = $_ -split '=', 2
        [pscustomobject]@{
            Project = $project
            # Reference = подключённая библиотека типов; Object = элемент ActiveX на форме
            Kind    = $kind
            Entry   = $value
        }
    }
} | Sort-Object Kind, Entry | Export-Csv .\vb6-components.csv -NoTypeInformation -Encoding UTF8

Уберите дубликаты в получившемся CSV — за полдня будет список: «от каких COM-компонентов эта система в итоге зависит». Дальше по каждой строке заполняете: можно ли достать, есть ли поддержка поставщика, есть ли замена на стороне .NET. Эта таблица и есть основа выбора схемы и оценки из главы 4.

Тем же приёмом собирается список Declare: по .bas / .frm / .cls выбрать строки, в которых есть Declare. Вручную в инвентаризации нужно разбирать только бизнес-правила, которые живут в коде; остальное почти всё автоматизируется.

5.2 Как оценивать трудозатраты и сроки

Цифра «N дней на один экран» легко прыгает на порядок: сложность экрана, наличие OCX, плотность бизнес-логики, жёсткость тестов. Чужие цифры «с чужого проекта» не попадут. Вместо этого соберите свои.

1. Посчитать. По инвентаризации зафиксируйте число экранов, отчётов, внешних связей, типов OCX, операторов Declare, таблиц.
2. Разложить по сложности. Экраны — примерно на три ступени (простой список / просмотр; ввод с проверками; экран с сеткой или предварительным просмотром отчёта).
3. С каждой ступени взять по одному экрану и реально перенести (пилот). Замерить фактическое время, включая проектирование, реализацию, модульные тесты и сверку выхода со старой системой. Это и будет расценка для оценки.
4. Умножить и сложить. Расценку из пункта 3 умножить на число экранов из пункта 2 и сложить.
5. Добавить отдельные статьи. Общее (аутентификация, журналы, печать, распространение, подготовка среды) и время на расшифровку «правил, которые живут только в коде» не пропорциональны числу экранов. Оценка без этих статей всегда занижена.
6. Если не сходится — вернуться к схеме. Если пилот вышел заметно хуже ожидания, это не погрешность оценки, а сигнал, что схему выбрали не ту. Вернитесь к главе 4 и заново выберите между переписыванием с нуля, автопреобразованием и поэтапной миграцией.

Главное: опирайте оценку не на чужие цифры, а на свой пилотный замер. Пилот — не расход, а вложение в точность оценки.

6. Главные несовместимости VB6 и .NET

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

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

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

Если бизнес останавливать нельзя, нужна конфигурация, в которой старое и новое живут вместе. Типичных схем три. Различие в одном: где проходит граница между старым и новым.

flowchart TB
    accTitle: Три схемы поэтапной миграции с VB6 на .NET
    accDescr: Граница между старым и новым может проходить по базе данных, по COM-интерфейсу в одном процессе или по IPC между процессами
    subgraph P1["7.1 Сначала слой данных — граница это база данных"]
      A1["Приложение VB6 — меняется только строка подключения"] --> DB["База после миграции — SQL Server и аналоги"]
      A2["Новые экраны на .NET — добавляются по очереди"] --> DB
    end
    subgraph P2["7.2 Связка через взаимодействие с COM — граница это COM-интерфейс, один процесс"]
      B1["Приложение VB6 — 32-битный процесс"] --- B2["COM-интерфейс"]
      B2 --- B3["Компонент .NET — его нужно собрать как 32-битный"]
    end
    subgraph P3["7.3 Разнести по процессам — граница это IPC, разные процессы"]
      C1["Приложение VB6 — 32-битный процесс"] --- C2["Именованный канал / файл / связь через localhost"]
      C2 --- C3["Приложение .NET — может быть 64-битным"]
    end

Рис. 1: Три схемы поэтапной миграции — где проходит граница между старым и новым.

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

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

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

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

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

Минимальная реализация моста — несколько строк. Сначала направление компонент .NET вызывается из VB6. На публикуемые интерфейс и класс вешают атрибуты.⁸

// Сторона .NET (C# / .NET 8) — публикация как COM, чтобы вызвать из VB6
using System.Runtime.InteropServices;

[ComVisible(true)]
[Guid("fe103d6e-e71b-414c-80bf-982f18f6c1c7")]   // IID интерфейса. Всегда генерируйте новый сами
[InterfaceType(ComInterfaceType.InterfaceIsIDispatch)]
public interface ITaxCalculator
{
    decimal CalcTax(decimal amount);
}

[ComVisible(true)]
[Guid("9f35b6f5-2c05-4e7f-93aa-ee087f6e7ab6")]   // CLSID класса. Его тоже генерируйте заново
[ClassInterface(ClassInterfaceType.None)]
[ProgId("Komura.TaxCalculator")]
public class TaxCalculator : ITaxCalculator
{
    public decimal CalcTax(decimal amount) => Math.Floor(amount * 0.1m);
}

В csproj включают генерацию COM-хоста, собирают и регистрируют получившийся .comhost.dll из командной строки с правами администратора.⁸

<PropertyGroup>
  <EnableComHosting>true</EnableComHosting>
</PropertyGroup>

regsvr32 TaxLib.comhost.dll

Вызывающая сторона на VB6 — как с любым COM-объектом.

' Сторона VB6 — поздняя привязка по ProgId
Dim calc As Object
Set calc = CreateObject("Komura.TaxCalculator")
MsgBox calc.CalcTax(12345)
Set calc = Nothing

Здесь два места, на которых спотыкаются всегда. Оба описаны в официальной документации.⁸

• По умолчанию компонент доступен только 64-битным клиентам. В отличие от эпохи .NET Framework, в .NET Core / .NET 5+ даже сборка как «Any CPU» даёт сопутствующий *.comhost.dll по умолчанию 64-битным. VB6 — 32-битный процесс, поэтому как есть он это не загрузит (то же ограничение WOW64¹). Соберите так, чтобы выходила 32-битная comhost.dll.
• Автономное (self-contained) распространение COM-компонента не поддерживается. Поддерживается только развёртывание, зависимое от платформы (framework-dependent). Способ распространения нужно решить до проектирования.

Обратное направление — код VB6 вызывается из .NET — это просто добавить ActiveX DLL как COM-ссылку.

// Сторона .NET — вызов ActiveX DLL, собранной в VB6, через COM-ссылку
// Подготовка: добавить в проект «COM-ссылку» и собрать как 32-бит (x86)
var legacy = new LegacyBiz.OrderCalc();      // класс, написанный на VB6
decimal total = legacy.CalcTotal(orderId);   // бизнес-логика остаётся на стороне VB6
Marshal.ReleaseComObject(legacy);            // COM-объект освобождают явно

И здесь вызывающую сторону .NET нужно собрать как 32-бит (x86). ActiveX DLL из VB6 — 32-битная DLL, а 64-битный процесс не может загрузить 32-битную DLL для выполнения.¹ Требование «хотим и новую 64-битную функцию, и вызов логики VB6» в одном процессе на этом месте уже не сходится. Тогда очередь раздела 7.3.

7.3 Разнести по процессам и связать их

Если старое и новое живут в одном процессе через взаимодействие с COM, упираетесь в разрядность (32/64 бита) и в то, что сбой одной стороны тянет другую. Когда нужна новая 64-битная функция или хочется изолировать сбои, процессы разделяют и связывают файлом, именованным каналом, связью через localhost и тому подобным. Варианты IPC собраны в «Таблице решений по 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#.

9.1 Следующий шаг — что сделать в первую неделю

Чек-лист такого размера, чтобы «рассмотреть миграцию» не зависло в воздухе. Кода не пишут ни строки.

• Найти полный исходный код. Сверить с актуальным исполняемым файлом в продакшене и убедиться, что это действительно текущая версия (как в главе 3: если здесь расхождение, всё дальнейшее уходит впустую)
• Проверить машины, на которых ещё запускается IDE VB6. Сколько их, какая ОС, можно ли заново собрать стенд, если сломается
• Выгрузить ссылки из .vbp. Прогнать скрипт из главы 5 и получить CSV
• К каждой строке списка добавить три колонки: «можно ли достать / есть ли поддержка поставщика / есть ли замена на .NET» — и заполнить. Пустые ячейки — это как раз трудные места миграции
• Посчитать экраны и отчёты. Затем на месте спросить, какими экранами реально пользуются. Уже одно только «не переносить неиспользуемые» сильно меняет оценку
• По всему дереву исходников извлечь операторы Declare. Разобрать по назначению и отделить то, что закрывается стандартными средствами .NET
• Решить, с чем сверять. Чем подтверждать корректность после миграции (отчёт, CSV, содержимое БД) — выбрать один эталон
• Выяснить, есть ли уже требования, которые упираются в 32 бита. Если есть, этот один пункт становится главным условием выбора схемы

На этом материале уже можно идти к выбору схемы в главе 4 и к пилоту в главе 5.

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

• Продление жизни и миграция бизнес-приложений VB6 / Access — таблица решений: оставить, обернуть или заменить
• Как сегодня поступать с ActiveX / OCX — таблица решений: оставить, обернуть или заменить
• Пример COM-моста: вызов 64-битной DLL из 32-битного приложения
• .NET 8 DLL из VBA с типами — публикация COM и 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 она поддерживается лишь внутри 32-битной среды совместимости 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, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.