Создание плана переноса

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

Важный

Поддержка API Port прекращена в пользу двоичного анализа с помощью средства обновления .NET. Серверная служба порта API завершена, поэтому для использования средства необходимо использовать его в автономном режиме. Дополнительные сведения см. в статье .NET API Port README.

Перенос кода

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

Важный

Помощник по обновлению .NET официально устарел. Вместо этого используйте агент чата модернизации GitHub Copilot , который входит в состав Visual Studio 2026 и Visual Studio 2022 17.14.16 или более поздней версии. Этот агент анализирует проекты и зависимости, создает пошаговый план миграции с целевыми рекомендациями и автоматическими исправлениями кода и фиксирует каждое изменение, чтобы можно было проверить или откатить. Она автоматизирует распространенные задачи переноса — обновление файлов проекта, заменяя устаревшие API и устраняя проблемы сборки, чтобы ускорить модернизацию с меньшими усилиями вручную.

Работа в первую очередь с компилятором

Такой подход оптимальный для небольших проектов или проектов, в которых используется небольшое количество интерфейсов API .NET Framework. Этот подход прост:

  1. При необходимости запустите средство ApiPort для проекта. Если вы запускаете ApiPort, изучите отчет, чтобы узнать о проблемах, которые вам нужно будет решить.
  2. Скопируйте весь код в новый проект .NET.
  3. Обращаясь к отчету о переносимости (если он создан), устраните ошибки компилятора, пока проект не будет полностью компилироваться.

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

Оставайтесь на платформе .NET Framework до устранения проблем с переносимостью

Такой подход может быть оптимальным, если вам нужен код, который компилируется на протяжении всего процесса. Он выглядит следующим образом.

  1. Запустите средство ApiPort для проекта.
  2. Устраните проблемы, используя другие API-интерфейсы, являющиеся переносимыми.
  3. Запомните области, в которых невозможно использовать прямые альтернативы.
  4. Повторяйте предыдущие шаги для всех переносимых проектов, пока не удостоверитесь в том, что каждый из них готов к копированию в новый проект .NET.
  5. Скопируйте код в новый проект .NET.
  6. Устраните все проблемы, для решения которых нет прямых альтернатив.

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

Разработка детального плана атак

Это, возможно, оптимальный подход для более крупных и сложных проектов, при реализации которых для поддержки .NET может потребоваться реструктурировать код или полностью переписать некоторые его части. Он выглядит следующим образом.

  1. Запустите средство ApiPort для проекта.

  2. Определите, в каких случаях используется каждый непереносимый тип и как он влияет на переносимость в целом.

    • Изучите особенности этих типов. Их немного, но они часто используются? Или их много, но используются они нечасто? Ограничена ли область их использования или они распределены по всему коду?
    • Можно ли легко изолировать непереносимый код для более эффективной работы с ним?
    • Требуется ли рефакторинг кода?
    • Есть ли для непереносимых типов альтернативные интерфейсы API, выполняющие те же задачи? Например, если используется класс WebClient, вместо него используйте класс HttpClient.
    • Есть ли другие переносимые API-интерфейсы, которые можно использовать для выполнения задачи, даже если это не совсем равноценная замена? Например, если для анализа XML вы используете класс XmlSchema, но обнаружение схемы XML не требуется, вы можете использовать API System.Xml.Linq и выполнять анализ самостоятельно без API.

  3. Если у вас есть сборки, которые трудно перенести, возможно, пока стоит оставить их в .NET Framework? При этом нужно помнить о следующем:

    • В библиотеке могут присутствовать функции, которые несовместимы с .NET, так как они слишком тесно связаны с возможностями .NET Framework или Windows. Возможно, стоит на время отказаться от этих функций и выпустить временную версию библиотеки для .NET с ограниченной функциональностью, пока не будет достаточно ресурсов для переноса этих функций?
    • Поможет ли рефакторинг?

  4. Целесообразно ли написание собственной реализации недоступного интерфейса API .NET Framework?

    Вы можете рассмотреть возможность копирования, изменения и использования кода из библиотеки эталонного исходного кода .NET Framework. Эталонный исходный код распространяется по лицензии MIT, поэтому вы можете достаточно свободно использовать его в качестве источника при создании собственного кода. Только не забывайте соответствующим образом упоминать корпорацию Майкрософт в своем коде.

  5. При необходимости повторите этот процесс для различных проектов.

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

Ваш план может включать внесение существенных изменений в базу кода с ориентацией на .NET Framework 4.7.2. что делает этот подход более структурированным по сравнению с предыдущим. Способ реализации плана зависит от базы кода.

Смешанный подход

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

Перенос тестов

Чтобы гарантировать правильную работу кода после его переноса в .NET, лучше всего тестировать код в процессе переноса. Для этого потребуется использовать платформу тестирования, которая выполняет сборку и запуск тестов для .NET. В настоящее время имеются три варианта:

Процедура переноса во многом зависит от того, как структурирован ваш код .NET Framework. Перенос кода лучше всего начинать с основных объектов библиотеки, которые являются базовыми компонентами кода. Это могут быть модели данных или какие-либо иные базовые классы и методы, используемые всеми остальными компонентами прямо или косвенно.

  1. Перенесите тестовый проект для тестирования того уровня библиотеки, который вы переносите на данном этапе.
  2. Скопируйте основные объекты библиотеки в новый проект .NET и выберите версию .NET Standard, которая должна поддерживаться.
  3. Внесите изменения, необходимые для компиляции кода. Как правило, для этого требуется добавить зависимости пакетов NuGet в файл CSPROJ.
  4. Проведите тесты и внесите необходимые исправления.
  5. Выберите следующий уровень кода для переноса и повторите предыдущие шаги.

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

Следующие шаги

  • Last updated on