# Модернизация legacy .NET: WCF, AppDomains и AI-мост Что реально ломается при переходе с .NET Framework на современный .NET: BinaryFormatter, AppDomains, WCF, YARP, Strangler Fig и паттерн AI Bridge. > For the index of this section of the site, see [llms.txt](https://anetlab.com/llms.txt) 15 октября 2026 г.11 мин чтения # Модернизация legacy .NET: WCF, AppDomains и AI-мост Что реально ломается при переходе с .NET Framework на современный .NET: BinaryFormatter, AppDomains, WCF, YARP, Strangler Fig и паттерн AI Bridge. [Виктор Бузин](https://anetlab.com/about.md) · Founder & Principal Engineer, AnetLab 16+ лет в enterprise-разработке: .NET, AI/LLM-системы, RAG, MCP. Автор материала и практик в студии. ## Введение: Миф о модернизации Каждый опытный архитектор .NET видел это кино: компания решает, что пора «переезжать в облако» и «внедрять AI». Слайды в PowerPoint прекрасны: на них будущее со 100% покрытием тестами, идеально разделенные микросервисы в Azure Kubernetes Service (AKS) и агенты на базе LLM, безупречно обрабатывающие запросы клиентов. Реальность наступает через полгода. Команда застревает из-за зависимости от 15-летней проприетарной DLL, которая работает только на Windows Server 2012 R2. «Простая» миграция превращается в рекурсивный кошмар исправления сломанных контрактов WCF и поиска замены для `System.Drawing`. Бюджет потрачен на 80%, но ни один продуктовый пакет данных так и не попал в облако. **Тезис:** Большинство неудач при модернизации legacy .NET систем вызваны не выбором неверной целевой архитектуры, а недооценкой операционных затрат на переход и переоценкой того, сколько проблем решит новая архитектура без изменений в команде и процессах. Модернизация legacy-системы на .NET — это не просто обновление NuGet-пакетов с .NET Framework до .NET 8. Это борьба с «гравитацией» системы, которая строилась в расчете на локальное хранение данных, постоянные процессы Windows и монолитную модель данных. Если вы не учтете потерю уникальных знаний команды (tribal knowledge), сдвиг в операционном мониторинге и инерцию сложившихся подходов, ваша модернизация станет лишь дорогостоящим упражнением по перекладыванию технического долга. * * * ## 2\. «Гравитация Windows» и скрытое трение в legacy .NET Legacy .NET особенно сложен, так как он часто был «платформой для энтерпрайза». Он не просто выполнял код, он интегрировался со всем, что могла предложить ОС Windows. Когда вы пытаетесь снять эти слои, чтобы достичь кроссплатформенного состояния, вы обнаруживаете, что клей часто прочнее самих компонентов. ### Проблема проприетарных и устаревших сред исполнения Дело не только в файлах `.cs`. Многие системы зависят от: * **BinaryFormatter и риски безопасности:** Десятилетиями `BinaryFormatter` был стандартным способом передачи состояния в распределенных системах .NET. Современный .NET официально признал его небезопасным (deprecated). Замена его в большой кодовой базе — это не работа «найти и заменить», это требует пересмотра того, как данные сериализуются и передаются, часто через границы систем, о существовании которых вы даже не подозревали. * **AppDomains:** Старый код .NET использовал `AppDomain` для изоляции. .NET Core и его преемники не поддерживают вторичные AppDomains. Если ваша система полагается на динамическую загрузку сборок для плагинов или изоляции, вам придется перепроектировать весь этот слой в контейнеризированную или сервисную модель. * **Global.asax и HttpModules:** Старый конвейер (pipeline) ASP.NET был тяжеловесным, но мощным инструментом. Современный middleware в ASP.NET Core намного легче и быстрее, но он принципиально другой. Перевод сложного флоу аутентификации, внедренного в `IHttpModule`, в современный middleware часто вскрывает бизнес-логику, которая никогда не была задокументирована. ### Инфраструктурные якоря * **WCF (Windows Communication Foundation):** WCF был невероятным достижением инженерной мысли, позволявшим использовать сложные протоколы безопасности, транзакции через SOAP и связь по именованным каналам (named pipes). Для некоторых архитекторов переход на REST или gRPC ощущается как потеря конечности. Хотя CoreWCF помогает, стоимость переписывания контрактов сообщений и повторного тестирования каждого потребителя обычно является самым большим поглотителем времени при миграции. * **Windows Services и GAC:** Global Assembly Cache (GAC) создавался для борьбы с «DLL Hell», но при модернизации он превращается в «кладбище знаний». Сборки, зарегистрированные в GAC, отсутствуют в вашей системе контроля версий. Поиск исходного кода для зависимости 2011 года, которая существует только в GAC сервера, — это своего рода обряд посвящения для консультантов по модернизации. ### Работа с «неконтейнеризируемым» Некоторые системы сложно упаковать даже в Windows-контейнеры. * **Привязка к оборудованию:** Если ваше приложение проверяет наличие физического USB-ключа или конкретный MAC-адрес сетевой карты, миграция потребует использования сервисов «виртуальных ключей» или переработки модуля лицензирования. * **Зависимости UI:** Если ваш legacy-бэкенд на самом деле запускает скрытые окна рабочего стола для формирования отчетов через COM-interop с Excel, работа в безголовом (headless) Windows-контейнере, скорее всего, завершится ошибкой или потребует крайне специфической настройки сессии. * * * ## 3\. Инженерный долг: за пределами кода Мы часто говорим о техническом долге как о «плохом коде». В legacy .NET технический долг — это часто «структурное устаревание». ### Модель развертывания «На моей машине работает» Legacy-системы часто полагаются на ручную настройку IIS. Процесс развертывания включает в себя подключение через RDP к серверу и изменение строки подключения в `web.config`. Превращение этого в автоматизированный конвейер инфраструктуры как кода (IaC) мучительно, потому что приложение никогда не проектировалось как независимое от окружения. В облаке «Сервера» не существует; всё «Состояние» должно быть внешним. ### База данных как «Мозг» Во многих legacy-системах бизнес-логика находится не в C#, а в хранимых процедурах. У вас могут быть T-SQL скрипты на 5000 строк, которые управляют логикой состояний, отчетностью и валидацией. Модернизация «приложения» при сохранении базы данных в исходном виде часто не дает прироста производительности, так как узким местом всегда была конкуренция за блокировки в SQL Server. * * * ## 4\. Четыре подхода к модернизации и честный разбор компромиссов Я разделяю модернизацию на четыре «пути сопротивления». У каждого свое место, и часто в рамках одного проекта используются все четыре для разных подсистем. ### 1\. Rehost (Безопасный Lift-and-Shift) **Стратегия:** Перенос виртуальных машин «как есть» в Azure VM или Azure VMware Solution. * **Честный компромисс:** Вы получаете нулевую техническую гибкость. Ваш «облачный проект» — это просто чужой дата-центр. Вам всё еще нужно патчить Windows, у вас остаются проблемы с масштабированием, а затраты на лицензии могут даже *вырасти*. * **Когда использовать:** Когда есть жесткий дедлайн по закрытию дата-центра. Это покупает вам время, а не качество. ### 2\. Replatform (Легкая контейнеризация) **Стратегия:** Перенос приложения в Azure App Service или Windows-контейнеры без переписывания. * **Честный компромисс:** Windows-контейнеры — это неудобный промежуточный вариант. Они огромны (многогигабайтные образы), медленно запускаются и дороже Linux-аналогов. Однако они позволяют стандартизировать CI/CD конвейер. * **Когда использовать:** Когда вам нужна идентичность окружений (Dev=Prod), но нет бюджета на исправление самого кода. ### 3\. Refactor (Подход «Душителя» / Strangler Fig) **Стратегия:** Сохранение монолита при хирургическом выносе критических путей в сервисы на .NET 8 под Linux. * **Честный компромисс:** Это самая высокая операционная сложность. Теперь вы управляете гибридной системой. Вам нужно распределенное профилирование (tracing) между старым и новым кодом, управление токенами аутентификации между разными фреймворками и синхронизация данных. * **Когда использовать:** Для критически важных систем, где время аптайма в приоритете. Это подход «корабля Тесея» — постепенная замена каждой доски, пока весь корабль не станет новым. ### 4\. Rearchitect (Cloud-Native трансформация) **Стратегия:** Полное разложение на микросервисы или serverless. * **Честный компромисс:** Именно здесь тратится больше всего денег впустую. Многие команды создают «распределенный монолит», где сервисы тесно связаны, но теперь между ними появилась сетевая задержка. * **Когда использовать:** Только если конкретная часть системы переросла возможности монолита или когда логика домена стала настолько запутанной, что ни одна команда больше не может её понять. * * * ## 5\. Дорожная карта: миграция в облако без остановки производства Как перенести систему, обрабатывающую миллионы в час, без «большого взрыва» при переключении? Вы не переключаетесь, вы «просачиваетесь». ### Паттерн Gateway (YARP — ваш лучший друг) **YARP (Yet Another Reverse Proxy)** — это проект Microsoft, предоставляющий настраиваемый прокси на базе .NET. 1. **Точка входа:** Разверните YARP в Azure. 2. **Сдвиг DNS:** Направьте весь трафик на YARP. 3. **Legacy Fallback:** Изначально YARP перенаправляет 100% трафика обратно в on-premise монолит через VPN или ExpressRoute. 4. **Инкрементальный релиз:** Когда новый сервис готов в облаке, вы обновляете конфиг YARP, чтобы направить конкретные пути (например, `/api/payments`) на новый облачный сервис. Это позволяет проводить Blue-Green тестирование на уровне URL. Если новый сервис платежей дает сбой, вы откатываете правило YARP за секунды, а не за часы. ### Дилемма данных: общие или раздельные Самая большая ошибка — разделение базы слишком рано. Если вы перенесете код в облако, но оставите базу on-prem, сетевые задержки убьют производительность. **Стратегия:** Перенесите в первую очередь базу в **Azure SQL Managed Instance**. Она поддерживает кросс-базовые запросы и задания SQL Agent, являясь идеальным мостом. Как только данные в облаке, перенос кода становится вопросом вычислений, а не законов физики данных. Дорожная карта миграции без остановки производства — это в первую очередь про порядок отсечения: сначала выносится то, что деплоится независимо, и только потом меняется то, что связано с остальным. Планируйте не «перенести систему в Azure», а «выключить в ней Legacy-компонент за спринт» — у такого плана есть измеримая точка завершения. * * * ## 6\. Переход от WCF к современным сервисам: глубокое погружение WCF — это «финальный босс» модернизации .NET. Поскольку он был крайне гибким в настройке, не существует двух одинаковых реализаций WCF. ### Сопоставление протоколов * **Named Pipes:** Замените на gRPC вызовы внутри кластера Kubernetes или контейнерной группы. * **Net.TCP:** Замените на gRPC. Он обеспечивает ту же высокую производительность бинарной сериализации, но является кроссплатформенным индустриальным стандартом. * **BasicHttp / WS-Http:** Замените на REST API на базе ASP.NET Core. ### Работа с контекстами безопасности Старые сервисы WCF часто использовали Windows-аутентификацию (NTLM/Kerberos). В облаке этого не существует. Вам придется перейти на **OAuth2 / OpenID Connect** (через Azure Entra ID). Трудность не в новом коде, а в создании «идентификационного моста». Вам может понадобиться временный сервис обмена токенами, который превращает старую сессионную куку в JWT, понятный новым сервисам на .NET 8. * * * ## 7\. AI-Bridge: внедрение интеллекта в legacy-ядро Ошибка многих компаний — ожидание полного завершения миграции в облако перед внедрением AI. На самом деле AI может стать *катализатором* модернизации. ### Паттерн AI Gateway Вместо того чтобы заставлять старый монолит на .NET 4.8 общаться с OpenAI (что мучительно из-за старых версий TLS и отсутствия SDK), вы строите **AI Gateway** на .NET 8. * Legacy-приложение отправляет сообщение в очередь (Azure Service Bus). * .NET 8 AI Gateway обрабатывает сообщение, вызывает LLM и обновляет БД. * Legacy-приложение опрашивает БД на предмет результата. ### Semantic Kernel как «контекстный мост» Представьте, что пользователь спрашивает AI: «Сделай резюме последних 10 взаимодействий с клиентом ACME Corp». AI-агент не общается с legacy-приложением напрямую. Он использует плагины **Semantic Kernel**. 1. **Плагин А:** Вызывает современный API на .NET 8 для получения основной информации о клиенте. 2. **Плагин Б:** Вызывает старую хранимую процедуру SQL для получения логов транзакций. 3. **Плагин В:** Использует LLM для синтеза данных. Вы только что «модернизировали» пользовательский опыт, не изменив ни строчки кода в старом ASP.NET WebForms. * * * ## 8\. Ловушка полной переписки: почему «чистый лист» — опасная иллюзия Каждый разработчик, видя файл контроллера на 4000 строк, хочет его удалить и начать сначала. «Так будет быстрее», говорят они. Они ошибаются. ### Потеря институциональных знаний Legacy-код — это не просто код; это музей каждой ошибки, которую когда-либо совершила компания, и её исправления. Когда вы переписываете всё с нуля, вы теряете эти уроки. ### Подход «корабля Тесея» Вместо переписывания сфокусируйтесь на **непрерывном рефакторинге**: * Замените старую библиотеку логирования на Serilog/OpenTelemetry. * Вынесите один бизнес-сервис в отдельную библиотеку. К концу года вы перенесете 60% кода на .NET 8, ни разу не останавливая разработку новых функций. * * * ## 9\. Тестирование legacy: создание страховки Причина провала большинства проектов модернизации — страх. Разработчики боятся трогать код, потому что на него нет тестов. ### Тестирование «Золотого эталона» (Snapshot Testing) Если вы не можете написать юнит-тесты для метода десятилетней давности, используйте **Snapshot Testing**. 1. Зафиксируйте точные входные и выходные данные функции для тысячи реальных сценариев. 2. Сохраните их как «Золотой эталон». 3. Запустите вашу модернизированную версию функции. 4. Если результаты не совпадают на 100%, у вас регрессия. Это создает «статистическую страховку», позволяя проводить рефакторинг уверенно, даже когда бизнес-логика непроницаема. * * * ## 10\. Операционная готовность: реальная цена нового стека Переход от одного сервера IIS к контейнерной среде требует огромного сдвига в методах работы. ### Наблюдаемость (Observability) В облаке вам необходимы: * **Распределенный трейсинг:** Использование OpenTelemetry для отслеживания запроса через все сервисы. * **Метрики:** Не только CPU/RAM, но и «Здоровье бизнеса». Проходят ли заказы? Соответствует ли стоимость токенов AI ценности транзакции? ### Безопасность: внедрение Zero Trust «Периметр» мертв. Вы должны внедрить архитектуру **Zero Trust**: 1. **Managed Identities:** Используйте управляемые идентификаторы Azure вместо паролей в строках подключения. 2. **Key Vaults:** Управление секретами должно быть централизованным. * * * ## 11\. Управление и топология команд в период перехода Техническая миграция провалится, если структура команд не изменится вслед за ней (закон Конвея). ### Platform Team vs Feature Team Не просите продуктовых разработчиков учить Kubernetes. Создайте **Platform Team**, чья работа — строить «Золотой путь» (шаблоны, CI/CD, дашборды), чтобы остальные могли просто писать код на C#. ### Гильдия миграции Соберите вместе «старейшин», знающих legacy, и «энтузиастов» новых технологий. Если они не будут общаться, старейшины будут блокировать миграцию из страха, а энтузиасты сломают систему по незнанию. * * * ## 12\. Цена бездействия: взгляд уровня C-level «Legacy» часто воспринимается как техническая проблема. На самом деле это бизнес-риск. * **Проблемы с наймом:** Всё труднее найти талантливых разработчиков, готовых работать на .NET Framework 4.5. * **Уязвимости:** С возрастом среды исполнения перестают получать патчи безопасности. Один взлом может стоить дороже всего бюджета на модернизацию. * **Разрыв в гибкости:** Пока ваши конкуренты деплоят по 10 раз в день функции с AI, вы деплоите раз в месяц и боретесь с регрессионными багами. * * * ## 13\. Артефакт: дерево принятия решений по модернизации Используйте этот гайд для определения пути каждой подсистемы. | Вопрос | Если ДА | Если НЕТ | | --- | --- | --- | | **1\. Есть риск поломки «железа»?** | **Rehost** в Azure VM немедленно. | К вопросу 2. | | **2\. Есть COM+ библиотеки или проприетарные EXE?** | **Replatform** через Windows Containers. | К вопросу 3. | | **3\. Покрыт ли код тестами (>40%)?** | **Refactor** напрямую на .NET 8. | К вопросу 4. | | **4\. Бизнес готов к замедлению фич на 30%?** | **Refactor** через «Душителя». | **Replatform** и ждите. | | **5\. AI-интеграция — приоритет №1?** | Стройте **AI Bridge** рядом с монолитом. | Стандартная миграция. | * * * ## 14\. FAQ **Вопрос: .NET Framework 4.8 «умер»?** Ответ: Нет, он поддерживается, пока поддерживается Windows. Но это тупик для инноваций. **Вопрос: Как переносить базы SQL Server?** Ответ: Azure SQL Managed Instance — лучший путь к совместимости. **Вопрос: Поможет ли .NET Upgrade Assistant от Microsoft?** Ответ: Да, для «первого прохода». Он сэкономит время, но не решит архитектурные проблемы. **Вопрос: Можно ли оставить SQL Server локально?** Ответ: Можно, но готовьтесь к потере производительности из-за сетевых задержек. * * * ## Связанные статьи * [.NET и Azure для AI-систем: референсная архитектура](https://anetlab.com/blog/dotnet-azure-ai-architecture.md) * [RAG на .NET: архитектура, которая переживает продакшн](https://anetlab.com/blog/rag-na-dotnet.md) * [Архитектура enterprise AI: четыре решения, которые всё определяют](https://anetlab.com/blog/enterprise-ai-architecture.md) **Готовы разорвать цикл «бесконечной переписки» и начать доставлять результат?** [Запишитесь на стратегический аудит модернизации](https://anetlab.com/contact.md) Читайте также 20 октября 2026 г.AI/LLM ### [Оценка качества RAG на .NET: Recall@5, MRR и гейт релиза](https://anetlab.com/blog/rag-evaluation-dotnet.md) Как измерять качество RAG на .NET: Golden Set из 50–100 вопросов, расчёт Recall@5 и MRR, измерение faithfulness и eval-как-гейт-релиза в CI. [Читать разбор](https://anetlab.com/blog/rag-evaluation-dotnet.md) [.NET](https://anetlab.com/blog?tag=.NET)[RAG](https://anetlab.com/blog?tag=RAG.md)[Оценка качества](https://anetlab.com/blog?tag=%D0%9E%D1%86%D0%B5%D0%BD%D0%BA%D0%B0%20%D0%BA%D0%B0%D1%87%D0%B5%D1%81%D1%82%D0%B2%D0%B0.md) 13 октября 2026 г..NET ### [.NET и Azure для AI-систем: референсная архитектура](https://anetlab.com/blog/dotnet-azure-ai-architecture.md) Как собрать production-ready AI-систему на .NET и Azure: async-пайплайн, RAG, Polly, observability и контроль стоимости — с рабочим кодом. [Читать разбор](https://anetlab.com/blog/dotnet-azure-ai-architecture.md) [AI/LLM](https://anetlab.com/blog?tag=AI%2FLLM.md)[Архитектура](https://anetlab.com/blog?tag=%D0%90%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0.md)[RAG](https://anetlab.com/blog?tag=RAG.md)