После режима IE — подойдёт ли WebView2? Ограничение ActiveX и реалистичный план миграции

В предыдущей статье «Как продлить жизнь внутренней веб-системе, зависящей от режима IE, и как из него выйти» я писал, что режим IE — это лишь временная мера с ограниченным сроком, и параллельно нужно проектировать выход. Когда к нам приходят именно с этим «выходом», очень часто всплывает WebView2. «Хотим показать внутреннюю веб-систему внутри отдельного приложения», «часть экранов desktop-приложения хотим сделать на веб-технологиях», «слышали, что Electron тяжёлый — есть ли альтернатива?» — во всех этих случаях WebView2 оказывается одним из вариантов.

При этом у WebView2 есть особенности, которые нужно знать до внедрения. Как распространять среду выполнения, куда класть папку пользовательских данных, как нативный код и веб-страница будут обмениваться данными. И, что важнее всего, ограничение, от которого зависит весь план миграции: ActiveX, который работал в режиме IE, в WebView2 не работает. В этой статье разберём устройство WebView2, распространение, проектирование, безопасность и то, как всё это реалистично сочетается с выходом из режима IE.

1. Сначала выводы

• WebView2 — это элемент управления, который встраивает Microsoft Edge на базе Chromium в Windows-приложение. Его можно использовать из WinForms / WPF / WinUI / Win32 C++, и он хорошо подходит, чтобы добавить «немного Web UI» к уже существующему desktop-приложению. ¹
• Среду выполнения по умолчанию берут Evergreen (общая среда выполнения с автоматическим обновлением). В Windows 11 она входит в состав ОС, но официальная рекомендация — не исходить из того, что «она уже точно установлена», а заложить в установщик проверку наличия и начальную установку. ²
• Для офлайн-сред и заводов / производственных линий, которым нужно зафиксировать проверенную конфигурацию, есть Fixed Version (среда выполнения, поставляемая вместе с приложением), но дистрибутив раздувается больше чем на 250 МБ, и исправления безопасности вы обязаны раздавать сами. Не выбирайте этот вариант по привычке. ³
• Первая ловушка — папка пользовательских данных (UDF). По умолчанию она создаётся рядом с exe, поэтому у приложения, установленного в Program Files, запуск падает. Возьмите за правило явно указывать папку внутри %LOCALAPPDATA%. ⁴
• Взаимодействие нативного кода с веб-страницей по умолчанию строится на обмене сообщениями через PostWebMessageAsJson / WebMessageReceived, а AddHostObjectToScript (публикация COM-объекта) стоит ограничивать по-настоящему доверенным контентом. ¹
• ActiveX внутри WebView2 не работает. Страницы, завязанные на режим IE и ActiveX, нельзя «просто перенести на WebView2» — нужно спроектировать перенос функций, которые выполнял ActiveX, в хост-приложение. Это и есть суть плана выхода из режима IE. ⁵

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

2. Как устроен WebView2

WebView2 состоит из двух частей: SDK (API, которое встраивается в приложение) и среды выполнения (исполняющая среда на базе Edge, которая ставится на клиент). Схема та же, что у Visual C++ Runtime или .NET Runtime: приложение собирается со ссылкой на NuGet-пакет Microsoft.Web.WebView2, а во время выполнения пользуется средой выполнения, установленной на клиенте. ³

Поддерживаемых платформ много: WinForms и WPF на .NET Framework 4.6.2 и новее / .NET Core 3.1 и новее, WinUI, Win32 C++. Большое преимущество перед подходом, где приходится менять весь фреймворк целиком (как, например, Electron), — поэтапность: можно перевести на WebView2 только один экран уже существующего WinForms-приложения. О выборе самого UI-фреймворка см. также «Как выбрать между WinForms, WPF и WinUI — таблица решений».

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

Минимальное встраивание выглядит примерно так (идея общая для WPF и WinForms).

var env = await CoreWebView2Environment.CreateAsync(
    browserExecutableFolder: null,   // используем среду выполнения Evergreen
    userDataFolder: Path.Combine(
        Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData),
        "KomuraSoft", "MyApp", "WebView2"));
await webView.EnsureCoreWebView2Async(env);
webView.CoreWebView2.Navigate("https://internal.example.co.jp/app/");

Главное здесь — CoreWebView2Environment создаётся явно, а не оставляется на значения по умолчанию. Почему — в следующих двух главах.

Сама процедура внедрения прямолинейна. Для WinForms / WPF она такая:

1. Добавить в проект Microsoft.Web.WebView2 через NuGet (элемент управления WebView2 появится и в панели инструментов дизайнера).
2. Разместить элемент управления на форме / окне.
3. Как в коде выше, инициализировать через EnsureCoreWebView2Async, затем вызвать Navigate.

Здесь же стоит сразу зафиксировать одну особенность API: webView.CoreWebView2 равен null, пока инициализация не завершена. Классическая ошибка — подписаться на событие вроде CoreWebView2.WebMessageReceived += ... в конструкторе формы и получить NullReferenceException. Базовый приём — собрать всю работу, зависящую от инициализации, в блок «после await EnsureCoreWebView2Async». Присвоение свойству Source тоже неявно запускает инициализацию, но в приложениях, где нужно задать параметры среды (например, расположение UDF), безопаснее унифицировать код так, чтобы EnsureCoreWebView2Async(env) вызывался явно и раньше.

Кроме того, все события WebView2 приходят в потоке UI. Если тяжёлую операцию (доступ к оборудованию, файловый ввод-вывод) написать прямо внутри WebMessageReceived, вместе с ней замрёт и отзывчивость веб-страницы, поэтому обработку на стороне хоста нужно уводить через async/await. Эти принципы прямо описаны в статье «UI-поток и async/await в WPF/WinForms — памятка на одну страницу».

3. Распространение среды выполнения — Evergreen и Fixed Version

3.1 Evergreen (рекомендуется)

Evergreen — модель, при которой все приложения на WebView2 пользуются общей средой выполнения, установленной на клиенте, и она обновляется автоматически. Microsoft явно рекомендует именно её: исправления безопасности ставятся сами, расход диска невелик. ⁸

На практике важны три момента.

• Реализовать проверку наличия. В Windows 11 среда входит в состав ОС и широко доставлена и на Windows 10, но устройства без неё всё же встречаются. В .NET проверить можно через CoreWebView2Environment.GetAvailableBrowserVersionString(), но на машине без установленной среды выполнения сам этот вызов падает с исключением (WebView2RuntimeNotFoundException). Его нужно обернуть в try/catch, трактовать исключение как «не установлено» и из установки переходить к запуску начального установщика (небольшого онлайн-установщика, bootstrapper) или автономного установщика. ²
• Заложить сопровождение обновлений среды выполнения. Даже после обновления среды уже запущенное приложение продолжает работать на старой версии. Рекомендуемый приём — ловить событие NewBrowserVersionAvailable и выстраивать сценарий вида «после перезапуска обновление вступит в силу». ²
• Согласовать с внутренней политикой обновлений. Политика обновления браузера Edge и политика обновления среды выполнения WebView2 — разные вещи. Там, где групповая политика останавливает обновление среды, базовое предположение Evergreen («стоит последняя версия») больше не выполняется, поэтому при использовании более новых API стоит добавлять определение возможностей (feature detection). ⁸

3.2 Fixed Version (узкое применение)

Fixed Version — способ поставить конкретную версию среды выполнения вместе с приложением. Он позволяет заморозить проверенную конфигурацию, и для офлайн-производственного оборудования или сред со строгим контролем изменений это разумный выбор. Но цена высокая:

• поставляемые двоичные файлы весят больше 250 МБ, и на столько же раздувается дистрибутив; ²
• среда выполнения не обновляется сама, поэтому исправления уязвимостей браузерного движка вы обязаны раздавать своими релизами;
• если обновления забросить, в компании продолжает жить «рабочее приложение со старым Chromium внутри».

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

4. Первая ловушка — папка пользовательских данных

WebView2 хранит cookie, кэш, разрешения и прочее в папке пользовательских данных (UDF). Если расположение не задать, по умолчанию она пытается создаться в стандартном месте (в большинстве конфигураций — рядом с exe), поэтому у приложения, установленного в Program Files, запись туда завершается ошибкой, и инициализация падает. На машине разработчика (отладочный запуск, папка с правом записи) всё работает, стоит установить приложение — и оно перестаёт запускаться: типичная ошибка, которая всплывает только после поставки. ⁴

Решение простое: как в примере кода выше, всегда явно указывать отдельную папку приложения внутри %LOCALAPPDATA%. Заодно заложите в проект и следующее:

• разделять UDF по пользователю и по приложению (не использовать общую папку на несколько приложений);
• не класть её на сетевой диск (это замедляет работу и приводит к повреждению и потере данных); ⁴
• заранее определить, как удалять UDF при деинсталляции или через функцию «очистить данные входа» (если оператор не знает, что именно там лежат cookie и данные сайта, это легко упустить, например при разборе машины уволившегося сотрудника).

Считайте это версией для WebView2 принципа «не писать рядом с exe», описанного в статье «Где хранить локальные данные в корпоративном Windows-приложении — таблица решений».

5. Как связать нативный код и веб-страницу

То, что превращает WebView2 из «просто рамки браузера» во что-то большее, — двустороннее взаимодействие нативного кода с веб-контентом. Основных механизмов два. ¹

«Кто каким API отправляет и кто каким событием принимает» на словах легко перепутать, поэтому сначала — общая картина обмена. Нативный код отправляет через PostWebMessageAsJson и принимает через WebMessageReceived. Веб-страница отправляет через window.chrome.webview.postMessage и принимает событием message. Это симметричная схема.

sequenceDiagram
    participant N as Нативный код, хост-приложение
    participant W as Элемент управления WebView2
    participant P as JavaScript веб-страницы

    Note over N,P: Инициализация: подписываться после завершения EnsureCoreWebView2Async
    N->>W: Подписка на WebMessageReceived
    P->>W: Подписка на message через window.chrome.webview.addEventListener

    Note over P: Пользователь нажимает «Печать этикетки»
    P->>W: Запрос через window.chrome.webview.postMessage
    W->>N: Срабатывает WebMessageReceived
    N->>N: Проверка e.Source и сверка type с белым списком
    N->>N: Нативная обработка (управление оборудованием и т. п.) через async
    N->>W: Результат через PostWebMessageAsJson
    W->>P: Срабатывает событие message
    P->>P: Обновление индикатора состояния на экране

Слева на схеме — нативный код, справа — веб-страница. Проверку ставят в одном месте, сразу после приёма на стороне хоста: дальше можно писать обработчики в расчёте на то, что до них доходят только запросы с разрешённым type.

5.1 Web-сообщения (базовый вариант)

Нативный код отправляет JSON через PostWebMessageAsJson, веб-страница принимает его через window.chrome.webview.addEventListener("message", ...). В обратную сторону — window.chrome.webview.postMessage(...) и событие WebMessageReceived. Связь слабая, все открытые операции можно проверять в одном месте, поэтому именно этот способ стоит сделать взаимодействием по умолчанию.

// Нативный код → веб-страница
webView.CoreWebView2.PostWebMessageAsJson(
    JsonSerializer.Serialize(new { type = "deviceStatus", connected = true }));

// Веб-страница → нативный код
webView.CoreWebView2.WebMessageReceived += (s, e) =>
{
    // Сообщения не с ожидаемого origin (например, после перехода на внешний сайт) не обрабатываем
    if (!e.Source.StartsWith("https://internal.example.co.jp/", StringComparison.Ordinal))
        return;

    AppMessage? msg;
    try { msg = JsonSerializer.Deserialize<AppMessage>(e.WebMessageAsJson); }
    catch (JsonException) { msg = null; }
    if (msg?.Type is null)
        return;  // Некорректный формат отбрасываем здесь (при необходимости — в журнал)

    // Выполняем только операции, разрешённые для данного type
};

На веб-странице (JavaScript) сообщение принимают так. Отдельная библиотека не нужна — достаточно объекта window.chrome.webview, который внедряет WebView2.

// Принимаем сообщение от нативного кода
window.chrome.webview.addEventListener("message", (e) => {
    if (e.data.type === "deviceStatus") {
        updateStatusBadge(e.data.connected);
    }
});

// Отправляем запрос нативному коду
document.getElementById("print-label").addEventListener("click", () => {
    window.chrome.webview.postMessage({ type: "printLabel", copies: 2 });
});

На приёме, как в коде выше, нужно сначала проверить e.Source (URI страницы, которая отправила сообщение), а затем жёстко держаться правила: «сверить type сообщения с белым списком, всё непредусмотренное игнорировать и писать в журнал». Веб-страница может уйти на внешний сайт по одной ссылке или одному редиректу, поэтому не пропускайте проверку источника из предположения «сейчас точно открыта наша страница». Со своей стороны на веб-странице стоит заложить запасной путь на случай, если window.chrome.webview нет (страница открыта в обычном браузере): веб-часть UI тогда можно отлаживать отдельно, в обычном браузере, и разработка идёт быстрее.

5.2 Публикация хост-объекта (мощно, но только точечно)

AddHostObjectToScript позволяет вызывать .NET/COM-объект напрямую из JavaScript. Внутри это устроено через COM, и занятно видеть, что технология COM, с которой мы давно работаем, жива и здесь. Но отдать нативный объект веб-контенту напрямую значит, что при компрометации страницы последствия будут столь же прямыми. Публиковать стоит только контент, которым вы управляете сами, а набор открытых методов сводить к необходимому минимуму. Базовое правило: не регистрировать хост-объекты в WebView, где может открыться недоверенная страница.

5.3 Загрузка локального контента

Если HTML/JS поставляются вместе с приложением, стандартный приём — не читать их напрямую через file://, а сопоставить папку виртуальному имени узла через SetVirtualHostNameToFolderMapping. У контента появляется origin вида https://appassets.example/, поэтому обычным образом работают Web API, завязанные на origin, такие как localStorage, и можно задать уровень разрешения кросс-доменного доступа. Для имени узла берут заведомо несуществующий зарезервированный домен (например, .example), а тип доступа начинают с минимально необходимого (сначала DenyCors). ⁹

6. Выход из режима IE и WebView2 — ActiveX не работает

Это самый важный раздел статьи. Режим IE держится потому, что внутри Edge работает настоящий IE11 (движок Trident), и элементы ActiveX и Browser Helper Object работают в нём как обычно. ⁵ WebView2, напротив, построен на Chromium и не умеет хостить ActiveX. Иными словами,

«перенести внутреннюю систему, которая работает в режиме IE, на оболочку из WebView2» получается только для экранов, не зависящих от ActiveX.

Именно из этого ограничения нужно строить план миграции. Реалистичный порядок такой:

1. Инвентаризация: разделить страницы, завязанные на режим IE, на «экраны, которые используют специфичные для IE технологии вроде ActiveX» и «экраны, которые просто сделаны по-старому» (подход к инвентаризации из статьи о режиме IE подходит как есть. В одну строку: через Enterprise Site Discovery механически перечислить URL, попавшие в режим IE, и по каждому URL классифицировать зависимости — «режим документа», «ActiveX / BHO», «аутентификация», «клиентский сертификат», «файлы и печать», «оборудование и COM»).
2. Экраны без специфики IE: доработать под современные браузеры и либо открывать прямо в Edge, либо, если нужна интеграция в приложение рабочего места, встроить в оболочку WebView2.
3. Экраны, зависящие от ActiveX: перепроектировать так, чтобы функции, которые раньше выполнял ActiveX (последовательный обмен, доступ к файлам, управление специализированным оборудованием и т. п.), переехали в хост-приложение WebView2 и вызывались через Web-сообщения. Образно это переворот схемы «ActiveX внутри браузера» в схему «Web UI внутри приложения плюс нативная обработка».
4. Решение, оставлять ли сам ActiveX, оборачивать его или заменять, можно принимать по тем же критериям, что и в статье «Оставить, обернуть или заменить ActiveX/OCX — таблица решений».

Именно перепроектирование из пункта 3 и есть реальная трудоёмкость внедрения WebView2. На этапе планирования нужно выровнять ожидания: это не «поставим WebView2 и выйдем из режима IE». С другой стороны, если довести до конца перенос функций ActiveX в хост-приложение, получаются сразу оба плюса: UI, который проще разрабатывать и сопровождать своими силами на веб-технологиях, и распространение, которое по-прежнему контролируется как у desktop-приложения.

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

Как только начинают рассматривать WebView2, со стороны бизнеса почти всегда всплывает один и тот же набор вопросов. Разберём их заранее.

7.1 Печать и отчёты

Требование «в IE по кнопке печати выходил отчёт» в WebView2 закрывается двумя путями.

• Печать экрана как есть: показать диалог печати через CoreWebView2.ShowPrintUI() либо печатать без участия пользователя через PrintAsync. Это эквивалент печати из браузера, поэтому правила печати в CSS (@media print) работают так же.
• Вывод в PDF: PrintToPdfAsync сохраняет открытую страницу в PDF-файл. Для процесса вида «сохранить отчёт в PDF и положить в общую папку» этот путь удобнее: имя файла и место сохранения можно контролировать в хост-приложении. ¹

Для отчётов, где нужно попиксельное выравнивание колонок (например, бланков с копировальным слоем), стоит рассмотреть и вывод отчёта на стороне хоста (подход из статьи «Как построить вывод Excel-отчётов»), а не добиваться результата печатью из браузера.

7.2 Скачивание и загрузка файлов

Скачивание по умолчанию работает как в браузере, но в корпоративном приложении стандартный приём — вмешаться через событие DownloadStarting. Можно зафиксировать место сохранения, разрешать или запрещать по расширению, убрать стандартный UI скачивания и заменить его уведомлением приложения. ¹ Загрузка (<input type="file">) открывает системный диалог выбора файла без какой-либо специальной реализации.

7.3 Аутентификация и SSO

Если внутренняя веб-система использует встроенную проверку подлинности Windows (NTLM/Kerberos), в WebView2 она в целом проходит так же, как в браузере. Для старых систем с Basic-аутентификацией учётные данные можно подавать через событие BasicAuthenticationRequested и обойтись без экрана входа — но вопрос, где хранить эти учётные данные, как раз из статьи о DPAPI. Если нужно, чтобы SSO Microsoft Entra ID (бывший Azure AD) проходил через данные входа в ОС, стоит рассмотреть включение параметра среды AllowSingleSignOnUsingOSPrimaryAccount.

Cookie хранятся в UDF, поэтому состояние входа сохраняется и после перезапуска приложения. Если нужна функция выхода, которая гарантированно сбрасывает сессию, добавьте явное удаление cookie через CookieManager.

7.4 Отладка во время разработки

Внутри WebView2 работает Chromium, поэтому во время разработки доступны обычные DevTools по F12 (CoreWebView2Settings.AreDevToolsEnabled включён по умолчанию). Открыть их можно тремя способами: F12, Ctrl+Shift+I и правый щелчок по странице → «Просмотреть код». Если, как в главе 8, сочетания клавиш и контекстное меню в production-сборке закрыты, DevTools всё равно можно открыть из приложения через OpenDevToolsWindow (для внутренних систем полезно держать «скрытый пункт меню → инструменты разработчика»: расследование на рабочей машине сразу становится проще). ¹⁰

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

1. Запустить приложение, на экране WebView2 открыть DevTools и перейти на вкладку «Консоль».
2. Ввести window.chrome.webview и вычислить. Если показался объект, вы внутри WebView2. Если undefined — страница открыта в обычном браузере, инициализация ещё не завершена, или нарушена какая-то другая предпосылка.
3. Проверить направление веб-страница → нативный код. В консоли выполнить window.chrome.webview.postMessage({ type: "printLabel", copies: 1 }), заранее поставив точку останова в обработчике WebMessageReceived на стороне хоста: выполнение там остановится. Убедитесь, что в e.WebMessageAsJson тот же JSON, а в e.Source — URI текущей страницы.
4. Проверить направление нативный код → веб-страница. В консоли зарегистрировать window.chrome.webview.addEventListener("message", e => console.log(e.data)), затем на стороне хоста вызвать PostWebMessageAsJson (пункт меню, смена состояния оборудования и т. п.) — в консоли появится JSON.

Если эти четыре шага подтверждают «отправляется, принимается, источник совпадает с ожидаемым», дальше остаётся только наращивать обработку по type. Плюс, как уже сказано, если веб-часть UI сделать так, чтобы она работала и отдельно, в обычном браузере, разработку и отладку UI можно вести как обычную веб-разработку, а на WebView2 проверять только нативную интеграцию. Веб-ресурсы оказываются внутри приложения, а опыт разработки остаётся веб-опытом.

8. На что обратить внимание в безопасности

Приложение на WebView2 — это «приложение со встроенным браузером», поэтому модель угроз стоит брать браузерную.

• Ограничить отображаемый контент: в NavigationStarting сверять адрес перехода с белым списком внутренних доменов, а всё непредусмотренное отдавать браузеру по умолчанию (так же обрабатывать и NewWindowRequested).
• Сузить функции, которые пересекают границу доверия: область публикации хост-объектов и операции, разрешённые через Web-сообщения, держать минимальными. Полезно также разделять WebView, который может открывать внешние сайты, и WebView с нативной интеграцией.
• Подгонять пользовательские функции под среду: CoreWebView2Settings позволяет оставить ровно столько «браузерности», сколько нужно. На киосках и рабочих терминалах их лучше урезать — инцидентов станет меньше.
• При Fixed Version взять на себя план обновлений: как уже сказано, доставка исправлений уязвимостей в этом случае ложится на само приложение. ⁸

Ниже — параметры CoreWebView2Settings, которые настраивают чаще всего. Что делать с ними в production-сборке, стоит внести в чек-лист перед релизом.

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

9. Как выбирать решение

Если нужно «внутреннее приложение только под Windows с UI на веб-технологиях», по умолчанию стоит брать WebView2, а не Electron. Среда выполнения общая с ОС, поэтому дистрибутив легче, а стыковка с существующими .NET-наработками прямолинейна.

10. Заключение

WebView2 позволяет встроить Web UI на базе Chromium в Windows-приложение как отдельный компонент и хорошо сочетается с модернизацией внутренних систем. На практике при внедрении важны три вещи: проверка наличия среды выполнения Evergreen и сопровождение её обновлений, явное указание папки пользовательских данных и проектирование взаимодействия по умолчанию через Web-сообщения. А на уровне плана — смотреть в лицо ограничению «ActiveX не работает» и ставить в центр оценки трудозатрат перепроектирование, которое переносит функции ActiveX в хост-приложение.

Если, глядя на срок режима IE, вы уже думаете «пора заняться выходом», надёжнее всего начать с инвентаризации целевой системы и разборки функций, завязанных на ActiveX. Многое здесь трудно оценить без взгляда на реальную конфигурацию, так что если сомневаетесь — обращайтесь.

Связанные статьи

• Как продлить жизнь внутренней веб-системе, зависящей от режима IE, и как из него выйти
• Оставить, обернуть или заменить ActiveX/OCX — таблица решений
• Что такое COM, ActiveX и OCX
• Как выбрать между WinForms, WPF и WinUI — таблица решений

Смежные темы консультаций

KomuraSoft консультирует по проектированию выхода для внутренних систем, завязанных на режим IE и ActiveX, поэтапной модернизации с помощью WebView2 и интеграции Web UI в существующие Windows-приложения.

• Использование и миграция существующих активов
• Замена Windows-приложений
• Техническая консультация / ревью архитектуры
• Контакты

Источники

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

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

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

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

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

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

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

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

Работает ли ActiveX в WebView2?

Нет. В режиме IE внутри Edge работает настоящий IE11 (движок Trident), поэтому ActiveX работает как обычно. WebView2 построен на Chromium и не умеет хостить ActiveX. Поэтому экраны, зависящие от ActiveX, нельзя «просто перенести на WebView2 и на этом закончить»: функции, которые выполнял ActiveX — последовательный обмен, доступ к файлам, управление специализированным оборудованием — нужно перенести в хост-приложение и вызывать через Web-сообщения. Именно это перепроектирование и составляет основную трудоёмкость внедрения WebView2.

Какую среду выполнения WebView2 выбрать — Evergreen или Fixed Version?

По умолчанию — Evergreen (общая среда выполнения с автоматическим обновлением): исправления безопасности ставятся сами, расход диска невелик, и Microsoft прямо рекомендует именно этот вариант. В Windows 11 она уже входит в состав ОС, но на части устройств её всё равно нет, поэтому в установщик стоит заложить проверку наличия и начальную установку. Fixed Version (среда выполнения, поставляемая вместе с приложением) занимает больше 250 МБ и возлагает на вас ответственность за доставку исправлений уязвимостей браузерного движка через собственные релизы, поэтому её стоит выбирать только в узких случаях — например, для офлайн-производственного оборудования или сред со строгим контролем изменений.

Почему приложение на WebView2 не запускается после установки?

Первая типичная ловушка — папка пользовательских данных (UDF). WebView2 хранит в ней cookie, кэш и разрешения, и если расположение не задать явно, по умолчанию она пытается создаться рядом с exe. У приложения, установленного в Program Files, запись туда завершается ошибкой, и инициализация падает. Классика: на машине разработчика всё работает, после установки — нет. Решение — при создании CoreWebView2Environment всегда явно указывать отдельную папку приложения внутри %LOCALAPPDATA%. Класть её на сетевой диск тоже не стоит: это замедляет работу и приводит к повреждению данных.

Как нативный код и веб-страница взаимодействуют в WebView2?

Базовый способ — слабосвязанный обмен через Web-сообщения. Нативный код отправляет JSON через PostWebMessageAsJson, а страница принимает его событием message объекта window.chrome.webview. В обратную сторону — postMessage и событие WebMessageReceived. На приёме важно сначала проверить URI источника через e.Source, а затем сверить type сообщения с белым списком. Есть и способ напрямую выставить .NET/COM-объект через AddHostObjectToScript, но при компрометации страницы последствия гораздо тяжелее, поэтому его стоит ограничивать контентом, которым вы управляете сами, и сводить набор открытых методов к минимуму.

Об авторе

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

Го Комура

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

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