Перенос VB6- и WinForms-приложения на мобильные устройства: варианты, этапы и подводные камни

Запрос «сделайте нам то же самое на телефоне» приходит к команде сопровождения legacy-системы почти всегда одинаково. Кладовщику нужно принимать товар со сканером, менеджеру — смотреть остатки и заказы у клиента, выездному инженеру — закрывать заявки на объекте. А вся логика живёт в десктопном приложении на VB6 или WinForms, которое подключается к базе по локальной сети и знает только Windows.

Перенести такое приложение на Android и iOS «как есть» нельзя, но и переписывать всю систему ради нескольких мобильных сценариев не нужно. Рабочий путь — выделить сценарии, которые действительно нужны на телефоне, построить для них API поверх существующих правил и сделать отдельный мобильный клиент. Если своей мобильной экспертизы нет, клиентскую часть разумно отдать команде, которая делает мобильные приложения для бизнеса, а за собой оставить API и бизнес-логику, которую никто не знает лучше вас.

Перед стартом полезно пройти чек-лист аудита legacy-кода: он покажет, где логика зашита в формы и какие зависимости от Windows придётся обходить. Если приложение ещё на VB6, прочитайте и разбор миграции VB6 на .NET — значительную часть шагов ниже проще делать уже на современной платформе.

Можно ли просто запустить десктопное приложение на телефоне?

Короткий ответ — нет. Исполняемый файл Windows, OCX-контролы, COM-компоненты и вызовы Win32 API на Android и iOS не работают, эмуляторов для бизнес-использования там нет. Есть только обходные варианты, которые дают доступ к приложению, но не делают его мобильным.

• Удалённый рабочий стол. Приложение остаётся на сервере терминалов, а с телефона открывается через RDP-клиент или опубликованное приложение RemoteApp. Работает за день, но формы на 1024×768 на экране шириной 6 дюймов почти непригодны: мелкие поля, нет сенсорного ввода, нет камеры и сканера.
• Планшет на Windows. Для части сценариев (склад, производство) иногда достаточно защищённого планшета с Windows, на котором работает то же приложение. Это не мобильная разработка, а смена железа, и для смартфонов она не подходит.
• Веб-версия поверх старой системы. Если у приложения уже есть сайт на Web Forms, его можно адаптировать под мобильный экран. Подробно этот путь описан в плане перехода с Web Forms на ASP.NET Core и Blazor.

Удалённый рабочий стол разумно использовать как временное решение на период разработки, пока полноценный мобильный клиент не готов. Постоянно работать так никто не будет.

Что переносить: сценарии, а не формы

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

1. Опишите роли. Кто будет пользоваться мобильной версией: кладовщик, торговый представитель, инженер, руководитель. У каждой роли свой набор задач.
2. Выпишите сценарии. «Принять поставку по накладной», «оформить заказ у клиента», «закрыть заявку с фото». Сценарий — это цель пользователя, а не экран.
3. Отметьте, что требует устройства. Камера, сканер штрихкодов, геолокация, подпись на экране, push-уведомления. От этого зависит выбор технологии.
4. Определите требования к связи. Работает ли сотрудник в подвале склада или на объекте без сети. Офлайн — самая дорогая часть мобильного проекта.
5. Найдите логику каждого сценария в коде. Какие процедуры, формы и хранимые процедуры участвуют, какие проверки выполняются. Это вход для проектирования API.

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

Почему без API-слоя мобильное приложение не построить?

Десктопное приложение на VB6 или WinForms обычно ходит в SQL Server напрямую: через ADO, ADO.NET или DataSet, со строкой подключения в конфиге. Для мобильного клиента это недопустимо по трём причинам.

• Безопасность. Учётные данные базы окажутся внутри приложения на телефоне, который теряют, забывают в такси и разбирают. Открывать порт SQL Server в интернет нельзя ни при каких условиях.
• Сеть. Мобильная связь рвётся и меняет адреса. Долгие транзакции и курсоры, которые нормально работали в локальной сети, в мобильном клиенте превращаются в зависшие блокировки.
• Правила. Если проверки остаются в клиенте, каждую из них придётся продублировать на новом языке, и через год десктоп и телефон начнут считать по-разному.

Поэтому между телефоном и базой ставят API на ASP.NET Core: авторизация через корпоративный каталог или токены, проверка прав на каждый вызов, журнал операций. Рекомендации по защите мобильного клиента и его обмена с сервером собраны в стандарте OWASP MASVS; его стоит отдать подрядчику как часть требований.

PWA, .NET MAUI, Flutter или натив: какой путь выбрать?

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

• PWA (веб-приложение с установкой на экран). Работает в браузере, ставится иконкой, умеет офлайн через Service Worker; принципы описаны на web.dev. Быстрее и дешевле всего, одна кодовая база с веб-версией. Ограничения — доступ к железу и фоновые задачи, особенно на iOS.
• .NET MAUI. Кроссплатформенный фреймворк Microsoft для Android, iOS, macOS и Windows на C# и XAML, см. описание .NET MAUI. Позволяет переиспользовать .NET-библиотеки и знания команды. Наследник Xamarin, поддержка которого закончилась 1 мая 2024 года по политике Microsoft.
• Blazor Hybrid в MAUI. Интерфейс на компонентах Razor внутри нативной оболочки через BlazorWebView, см. документацию Blazor Hybrid. Удобно, если те же компоненты нужны в веб-версии.
• Flutter или React Native. Отдельный стек (Dart или JavaScript), но зрелые библиотеки, быстрый интерфейс и большой рынок разработчиков. С .NET-кодом общается только через API.
• Нативная разработка. Kotlin для Android и Swift для iOS: максимум возможностей устройства и производительности, но две кодовые базы и две команды.

Практическое правило выбора:

• нужны просмотр и простые формы, сеть есть почти всегда — PWA;
• команда сильна в .NET и хочет переиспользовать библиотеки, требования к интерфейсу умеренные — .NET MAUI или Blazor Hybrid;
• сложный интерфейс, офлайн, сканер, камера, публикация в магазинах и разработку ведёт внешняя команда — Flutter или натив;
• корпоративные устройства одной платформы (например, только Android-терминалы сбора данных) — натив под эту платформу.

Технологию лучше подтверждать на пилотном сценарии: две-три недели прототипа на реальных данных снимают больше вопросов, чем сравнительные таблицы.

Что из старого кода можно сохранить?

Ответ зависит от того, на чём написано приложение и как в нём устроен код.

VB6. Напрямую на мобильные не переносится ничего, кроме знаний: алгоритмы, правила расчётов, структура базы и хранимые процедуры. Логику, зашитую в модули и формы, придётся перенести в API на .NET — вручную или через поэтапную миграцию, описанную в статье о переходе VB6 на .NET через COM.

VB.NET и WinForms. Здесь можно сохранить больше. Классы с расчётами и проверками, вынесенные в отдельную библиотеку и перенесённые на современный .NET, подключаются и к API, и к клиенту на .NET MAUI. Сам интерфейс MAUI пишется на C# и XAML, но библиотеку на VB.NET проект на C# использует как обычную ссылку.

' Библиотека правил без зависимостей от Windows Forms:
' её вызывают и API, и десктоп, и мобильный клиент
Public Class PriceCalculator
    Public Function Total(lines As IEnumerable(Of OrderLine),
                          discountPercent As Decimal) As Decimal
        Dim gross = lines.Sum(Function(l) l.Qty * l.Price)
        Return Math.Round(gross * (1D - discountPercent / 100D), 2)
    End Function
End Class

Что мешает переиспользованию: обращения к My.Computer, реестру, файловым путям вида C:\Program Files, вызовы Declare к Win32 API и COM-компоненты. Их нужно спрятать за интерфейсами или оставить на сервере. Перед выносом логики зафиксируйте её поведение тестами — приёмы описаны в статье о тестах для legacy VB.NET.

Как организовать офлайн и синхронизацию?

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

• Локальное хранилище. Справочники и задания пользователя кешируются на устройстве (обычно SQLite), чтобы экран открывался без сети.
• Очередь операций. Действия пользователя записываются в очередь и отправляются на сервер, когда появится связь. Каждая операция получает уникальный идентификатор, чтобы повторная отправка не создала дубль.
• Правила конфликтов. Что делать, если два человека изменили одну запись: побеждает сервер, побеждает последний, или конфликт показывается пользователю. Решение принимают вместе с бизнесом, а не разработчики в одиночку.
• Инкрементальная синхронизация. Клиент забирает только изменения с момента последнего обмена, а не всю таблицу. Для этого в базе нужны метки изменений или журнал.

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

Этапы переноса: план на практике

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

1. Инвентаризация (1–2 недели). Роли, сценарии, зависимости логики, требования к офлайну и устройствам. Результат — приоритизированный список сценариев.
2. Выбор технологии на пилоте (2–3 недели). Прототип одного сценария на реальных данных, проверка камеры, сканера и сети на целевых устройствах.
3. API для первого сценария. Вынос правил из форм в сервис, тесты на поведение, авторизация и журнал. Десктоп при этом продолжает работать как раньше.
4. Мобильный клиент и пилотная группа. Выпуск через корпоративное распространение или закрытое тестирование в магазинах, обратная связь от 5–10 реальных пользователей.
5. Расширение по сценариям. Следующие сценарии по одному за итерацию; постепенный перевод десктопа на тот же API.
6. Сопровождение. Обновления под новые версии Android и iOS, требования магазинов приложений к целевому уровню API, мониторинг ошибок.

Бюджет такого проекта считают по сценариям и объёму логики, которую нужно вынести в API, а не по числу форм в старом приложении. Подробно о методике — в статье об оценке стоимости миграции legacy-приложения.

Чек-лист приёмки мобильного сценария:

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

Типичные ошибки при переносе на мобильные

• Перенести формы один в один. Экран с сорока полями на телефоне непригоден. Мобильный сценарий проектируют заново, начиная с цели пользователя.
• Подключить приложение к базе напрямую. Учётные данные в клиенте и открытый порт SQL Server — прямой путь к утечке.
• Скопировать логику в клиент. Две реализации одних правил неизбежно расходятся. Правила живут в API или в общей библиотеке.
• Выбрать технологию по моде. Решение принимают по сценариям, устройствам и компетенциям команды, а не по популярности фреймворка.
• Забыть про сопровождение. Мобильные платформы обновляются каждый год, и приложение без поддержки через год-два перестаёт проходить требования магазинов.
• Строить офлайн там, где он не нужен. Офлайн с синхронизацией — самая дорогая часть проекта; его делают только для сценариев, где без него нельзя.

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

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