Заметка
Доступ к этой странице требует авторизации. Вы можете попробовать войти в систему или изменить каталог.
Доступ к этой странице требует авторизации. Вы можете попробовать сменить директорию.
Подсказка
Это фрагмент из электронной книги «Архитектура микрослужб .NET для контейнеризованных приложений .NET», доступной в документации .NET или в виде бесплатного скачиваемого PDF-файла, который можно прочитать в автономном режиме.
Хотя .NET 8 предлагает значительные преимущества для новых приложений и шаблонов приложений, .NET Framework будет по-прежнему хорошим выбором для многих существующих сценариев.
Перенос существующих приложений непосредственно в контейнер Windows Server
Возможно, вы хотите использовать контейнеры Docker только для упрощения развертывания, даже если вы не создаете микрослужбы. Например, возможно, вы хотите улучшить рабочий процесс DevOps с помощью Docker— контейнеры могут предоставить более изолированные тестовые среды, а также устранить проблемы с развертыванием, вызванные отсутствием зависимостей при переходе в рабочую среду. В таких случаях, даже если вы развертываете монолитное приложение, рекомендуется использовать Docker и контейнеры Windows для текущих приложений .NET Framework.
В большинстве случаев для этого сценария вам не потребуется перенести существующие приложения в .NET 8; Можно использовать контейнеры Docker, включающие традиционную платформу .NET Framework. Однако рекомендуется использовать .NET 8 при расширении существующего приложения, например написание новой службы в ASP.NET Core.
Использование сторонних библиотек .NET или пакетов NuGet, недоступных для .NET 8
Сторонние библиотеки быстро охватывают .NET Standard, что позволяет совместно использовать код для всех вкусов .NET, включая .NET 8. Благодаря .NET Standard 2.0 и более поздних версий совместимость поверхностей API в разных платформах стала значительно больше. Более того, .NET Core 2.x и более новые приложения также могут напрямую ссылаться на существующие библиотеки .NET Framework (см. .NET Framework 4.6.1, поддерживающие .NET Standard 2.0).
Кроме того, пакет совместимости Windows расширяет область API, доступную для .NET Standard 2.0 в Windows. Этот пакет позволяет перекомпилировать существующий код на .NET Standard 2.x с небольшими изменениями или без изменений, чтобы запуститься в Windows.
Однако даже при таком исключительном прогрессии, так как .NET Standard 2.0 и .NET Core 2.1 или более поздней версии, могут возникнуть случаи, когда некоторые пакеты NuGet должны запускать Windows и не поддерживать .NET Core или более поздней версии. Если эти пакеты критически важны для приложения, вам потребуется использовать .NET Framework в контейнерах Windows.
Использование технологий .NET, недоступных для .NET 8
Некоторые технологии .NET Framework недоступны в .NET 8. Некоторые из них могут стать доступными в последующих выпусках, но другие не соответствуют новым шаблонам приложений, предназначенным для .NET Core, и могут никогда не быть доступны.
В следующем списке показаны большинство технологий, которые недоступны в .NET 8:
ASP.NET веб-формы. Эта технология доступна только в .NET Framework. В настоящее время нет планов перенести ASP.NET веб-формы в .NET или более поздней версии.
Службы, связанные с рабочим процессом. Windows Workflow Foundation (WF), службы рабочих процессов (WCF + WF в одной службе) и службы данных WCF (прежнее название — службы данных ADO.NET) доступны только в .NET Framework. В настоящее время нет планов перенести их в .NET 8.
Помимо технологий, перечисленных в официальной стратегии .NET, другие функции могут быть перенесены на новую унифицированную платформу .NET. Вы можете принять участие в обсуждениях на сайте GitHub, чтобы ваш голос мог быть услышан. И если вы думаете, что что-то отсутствует, отправьте новую проблему в репозиторий dotnet/runtime GitHub.
Использование платформы или API, которая не поддерживает .NET 8
Некоторые платформы Майкрософт и сторонних разработчиков не поддерживают .NET 8. Например, некоторые службы Azure предоставляют пакет SDK, который еще не доступен для использования в .NET 8. Большинство пакетов SDK Azure в конечном итоге должны быть перенесены в .NET 8/.NET Standard, но некоторые из них могут не по нескольким причинам. Доступные пакеты SDK Azure можно просмотреть на странице последних выпусков пакета SDK Azure .
В то же время, если любая платформа или служба в Azure по-прежнему не поддерживает .NET 8 с клиентским API, вы можете использовать эквивалентный REST API из службы Azure или клиентского пакета SDK для .NET Framework.
Перенос существующего приложения ASP.NET в .NET 8
.NET Core — это революционный шаг вперед от .NET Framework. Он предлагает множество преимуществ .NET Framework на борту от производительности до производительности, а также от кроссплатформенной поддержки до удовлетворенности разработчиков.
Дополнительные ресурсы
Основы .NET
https://learn.microsoft.com/dotnet/fundamentalsПеренос проектов в .NET 5
https://learn.microsoft.com/events/dotnetconf-2020/porting-projects-to-net-5Руководство по .NET в Docker
https://learn.microsoft.com/dotnet/core/docker/introduction