Перенос десктопного приложения на VB6 и WinForms в веб: варианты, архитектура и план

Десктопные программы на VB6 и WinForms до сих пор держат учёт, расчёты и документооборот во многих компаниях. Их ставят на каждый компьютер, обновляют вручную, а работать из дома или с ноутбука без VPN и удалённого рабочего стола не получается. Поэтому всё чаще звучит запрос «перенести программу в браузер» — и почти всегда оказывается, что это не перекомпиляция, а новое веб-приложение поверх старых процессов и данных.

Хорошая новость: бизнес-логику, структуру базы и знание процессов обычно удаётся сохранить. Интерфейс, работу с файлами, печать и доступ к данным придётся сделать заново, под модель «сервер и браузер». Если своих веб-разработчиков в команде нет, разумно заказать веб-приложение вместо десктопного клиента у внешней команды, а за собой оставить базу, правила расчётов и приёмку по реальным сценариям.

Ниже — варианты перехода от самого быстрого до самого основательного, таблица соответствий «что было в десктопе — что будет в вебе», порядок выноса логики в API и пошаговый план, при котором старая программа работает до последнего дня. Если вам нужен не браузер, а телефон, загляните в разбор переноса VB6- и WinForms-приложения на мобильные: там своя специфика с офлайном и синхронизацией.

Зачем переносить десктопное приложение в веб и когда этого делать не стоит?

Причины у всех похожие, и они редко про моду. Чаще всего в веб уводят программу, когда упираются в одно из ограничений десктопа:

• Удалённая работа. Сотрудникам, филиалам и партнёрам нужен доступ без установки программы, VPN и терминального сервера.
• Обновления. Новая версия раскатывается по десяткам компьютеров вручную или скриптами, часть пользователей неделями сидит на старой.
• Доступ к базе. Клиент ходит в SQL Server или Access напрямую, строка подключения с паролем лежит на каждой машине.
• Внешние пользователи. Клиентам или поставщикам нужен личный кабинет на тех же данных, а десктоп им не выдашь.
• Платформа. Программа держится на OCX-компонентах, 32-битном Office или Windows-версии, которую пора выводить из эксплуатации.

Но бывают случаи, когда веб — не лучший ответ. Если приложение работает с оборудованием на рабочем месте (весы, станки, кассовые устройства, сканеры по COM-порту), обрабатывает большие локальные файлы или нужно на изолированных машинах без сети, полностью браузерный клиент станет компромиссом. Тогда разумнее обновить десктоп на современный .NET и вынести в веб только то, чем пользуются удалённо: отчёты, согласования, кабинет.

Какие есть варианты перевода десктопа в браузер?

Путей четыре, и у каждого есть честная ниша. Сроки ниже даны для типичной учётной программы на 40–80 форм с одной-двумя интеграциями.

RemoteApp — это доставка, а не миграция: программа по-прежнему запускается на Windows-сервере, а в браузер передаётся картинка окна. Как это выглядит для пользователя, описано в документации Microsoft о веб-клиенте удалённого рабочего стола. Такой шаг хорош как временный мост, пока пишется настоящее веб-приложение.

Отдельно стоит сказать про автоматические конвертеры «VB6 в веб». Они переводят синтаксис, но не архитектуру: результат часто повторяет модальные окна и прямые запросы к базе, только в браузере. Если выбираете такой инструмент, требуйте пилот на самой сложной форме, а не на демо-примере.

Почему VB6 и WinForms нельзя просто перекомпилировать под веб?

Десктопная программа построена на допущениях, которые в браузере не работают. Она живёт на одной машине с пользователем, держит состояние в памяти формы, свободно читает диск, печатает на локальный принтер и открывает соединение с базой на весь сеанс. Веб-приложение — это сервер, к которому одновременно обращаются сотни браузеров, и каждое из этих допущений нужно заменить.

Самая трудоёмкая строка обычно первая и вторая: логика, перемешанная с обработчиками кнопок и состоянием формы. Чтобы оценить её объём до начала работ, пройдитесь по чек-листу аудита legacy-кода на VB.NET — он покажет, сколько правил живёт в формах и какие внешние зависимости придётся заменить. Отдельная тема — отчёты; варианты замены разобраны в статье о замене Crystal Reports.

Как вынести бизнес-логику в API и что из кода можно сохранить?

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

' Логика, база и интерфейс в одном обработчике
Private Sub cmdSave_Click()
    If Val(txtQty.Text) <= 0 Then
        MsgBox "Количество должно быть больше нуля"
        Exit Sub
    End If
    Dim total As Currency
    total = Val(txtQty.Text) * Val(txtPrice.Text)
    If chkVip.Value = 1 Then total = total * 0.95
    cn.Execute "INSERT INTO Invoices (Qty, Total) VALUES (" & _
               txtQty.Text & ", " & Str(total) & ")"
End Sub

Здесь три проблемы сразу: правило скидки спрятано в форме, сообщение пользователю блокирует выполнение, а запрос собран конкатенацией строк. При переносе правило выносится в класс библиотеки на современном .NET. VB.NET для этого по-прежнему годится, так что расчёты можно перенести почти один в один.

' Библиотека классов net10.0: правило без формы и без базы
Public Class InvoiceCalculator
    Public Function Calculate(qty As Decimal, price As Decimal,
                              isVip As Boolean) As Decimal
        If qty <= 0 Then
            Throw New ArgumentOutOfRangeException(NameOf(qty),
                "Количество должно быть больше нуля")
        End If
        Dim total = qty * price
        If isVip Then total *= 0.95D
        Return Math.Round(total, 2, MidpointRounding.AwayFromZero)
    End Function
End Class

Дальше эту библиотеку подключает веб-API на ASP.NET Core, а сохранение в базу идёт через параметризованные запросы или ORM. Веб-интерфейс вызывает API, получает результат или понятную ошибку валидации и показывает её рядом с полем, а не в модальном окне.

Что обычно удаётся сохранить, а что нет:

• Сохраняется. Схема базы и данные, расчёты, правила проверки, форматы документов, справочники. Именно здесь накоплены годы знания о бизнесе.
• Переносится с переработкой. Отчёты, импорт и экспорт, интеграции с другими системами — их логика остаётся, меняется способ запуска и доставки результата.
• Пишется заново. Формы, навигация, работа с файлами и принтерами, авторизация, всё, что завязано на OCX и COM.

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

Blazor или React, Vue, Angular: что выбрать для интерфейса?

Для команды с .NET-прошлым выбор обычно сводится к двум веткам.

• Blazor. Интерфейс на C# и Razor, общий стек с API и библиотеками, готовые наборы компонентов для таблиц и форм. Хорош для внутренних систем с большим числом форм ввода и плотными таблицами. Модели хостинга и ограничения описаны в документации ASP.NET Core Blazor. Учтите, что компоненты Blazor на VB.NET не пишутся: VB остаётся в библиотеках логики.
• React, Vue или Angular. Отдельный фронтенд на TypeScript, самый широкий выбор компонентов и разработчиков на рынке. Лучше подходит, когда нужен публичный кабинет, сложная интерактивность или мобильная версия того же интерфейса.

Если у вас уже есть веб-часть на ASP.NET Web Forms, её миграция — отдельная задача со своим планом; она подробно разобрана в статье о переходе с Web Forms на ASP.NET Core и Blazor. Решение по фронтенду лучше подтверждать прототипом самой нагруженной формы — обычно это грид документов с фильтрами и редактированием в строке.

Что меняется в безопасности и правах доступа?

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

• Права проверяются на сервере. Скрытая кнопка в интерфейсе не защищает: каждый вызов API сверяет роль и доступ к конкретной записи.
• Никаких учётных данных базы у клиента. Браузер общается только с API по HTTPS, база закрыта от внешней сети.
• Журнал действий. Кто, когда и что изменил — особенно для денег, цен и персональных данных.
• Защита от типовых атак. SQL-инъекции, межсайтовый скриптинг и подделка запросов, которых в десктопе просто не было.

Требования к подрядчику удобно задать ссылкой на стандарт OWASP ASVS и выбрать уровень проверки заранее, а не после первого аудита.

Этапы переноса: пошаговый план

Работу нельзя остановить на время переписывания, поэтому переход ведут по частям, и старая программа живёт до конца. Этот подход называют «удушающим деревом» (strangler fig): новые функции постепенно забирают нагрузку у старой системы. Схема описана в каталоге архитектурных шаблонов Microsoft.

1. Инвентаризация (2–3 недели). Список форм, отчётов и сценариев с частотой использования, внешние зависимости (OCX, COM, Office, принтеры, файлы), интеграции, роли пользователей. Результат — приоритизированный перечень сценариев.
2. Временный доступ (по необходимости). Если удалённый доступ нужен сразу, публикуем текущую программу через RemoteApp. Это снимает давление по срокам.
3. API и общая база. Вынос правил из форм в библиотеки, тесты на поведение, API с авторизацией. Старая программа продолжает работать с той же базой.
4. Первый модуль в вебе (2–3 месяца). Обычно — то, что нужнее всего удалённо: отчёты, согласования, справочники или кабинет внешних пользователей.
5. Перенос модулей по одному. Каждый следующий модуль уходит из десктопа, как только веб-версия прошла приёмку на реальных данных.
6. Вывод десктопа. Когда в старой программе не осталось активных сценариев, её отключают, а RemoteApp снимают.

Чек-лист приёмки модуля в вебе:

• расчёты совпадают со старой программой на эталонных документах;
• права проверяются на сервере, а не только скрытием кнопок;
• основные операции выполняются не медленнее, чем в десктопе, включая грид на тысячи строк;
• печатные формы и выгрузки совпадают с привычными пользователям;
• при одновременной работе двух пользователей с одной записью данные не теряются.

Сколько стоит и сколько длится перенос в веб?

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

• доля логики, зашитой в формах, а не в отдельных модулях;
• число отчётов и печатных форм;
• внешние зависимости: OCX, автоматизация Office, оборудование;
• интеграции с учётными и банковскими системами;
• требования к безопасности и наличие внешних пользователей.

Считать стоит по сценариям и объёму логики, а не по количеству форм: две формы могут отличаться по трудоёмкости в десять раз. Методика расчёта разобрана в статье об оценке стоимости миграции legacy-приложения.

Типичные ошибки при переносе десктопа в веб

• Копировать формы один в один. Окно на 60 полей с вкладками неудобно в браузере. Сценарий проектируют заново, начиная с того, что пользователь делает чаще всего.
• Оставить прямой доступ к базе. Веб-интерфейс, собирающий SQL из полей ввода, — прямой путь к инъекциям и утечкам.
• Переписать всё разом. Проект «большого взрыва» на год без промежуточных релизов чаще всего срывается: требования меняются, а старая программа продолжает развиваться.
• Забыть про печать и выгрузки. Пользователи принимают систему по привычным документам; печатные формы стоит переносить вместе с модулем, а не в конце.
• Не проверить производительность гридов. Таблица на десятки тысяч строк, которая мгновенно листалась в десктопе, в браузере требует серверной пагинации и фильтрации.
• Выключить старую программу раньше времени. Пока модуль не прошёл приёмку на реальных данных, десктоп — страховка.

Как это делают сегодня

Вопросы и ответы