Поделиться через

Обновление до новой версии .NET

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

Распространенные причины обновления до новой версии .NET:

  • В настоящее время используемая версия .NET больше не поддерживается
  • Новая версия поддерживает новую операционную систему.
  • Новая версия имеет важный API, производительность или функцию безопасности.

Обновление среды разработки

Чтобы обновить новую версию .NET, пакет SDK для .NET является основным компонентом для установки. Она включает обновленную версию .NET CLI, системы сборки и среды выполнения.

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

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

Visual Studio автоматически устанавливает новые версии пакета SDK для .NET. Для пользователей Visual Studio достаточно обновить до более новой версии Visual Studio.

Обновление исходного кода

Единственное необходимое изменение для обновления приложения — обновление TargetFramework свойства в файле проекта до более новой версии .NET.

Вот как это сделать:

  • Откройте файл проекта (или *.csproj*.vbproj*.fsproj файл).
  • Измените <TargetFramework> значение свойства, например, net6.0 на net8.0.
  • Тот же шаблон применяется к свойству <TargetFrameworks> , если он используется.

Подсказка

Возможность модернизации и обновления в приложении GitHub Copilot может автоматически вносить эти изменения.

Следующим шагом является создание проекта (или решения) с помощью нового пакета SDK. Если требуются дополнительные изменения, пакет SDK предоставит предупреждения и ошибки, которые помогут вам.

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

Дополнительные ресурсы

Закрепление версий

При обновлении таких средств разработки, как пакет SDK для .NET, Visual Studio или другие компоненты, может возникнуть новое поведение, предупреждения анализатора или критические изменения, влияющие на процесс сборки. Фиксация на определённой версии позволяет обновить среду разработки, сохраняя контроль над тем, когда обновляются определённые компоненты в проектах.

Закрепление версий обеспечивает несколько преимуществ:

  • Прогнозируемые сборки: обеспечивает согласованные результаты сборки на разных компьютерах и средах CI/CD.
  • Постепенное внедрение: позволяет постепенно внедрять новые функции, а не одновременно.
  • Избегайте непредвиденных изменений: запрещает новым правилам анализатора, поведению пакета SDK или версиям пакетов вызывать сбои сборки.
  • Координация команд. Позволяет командам обновляться вместе в запланированное время, а не отдельно при обновлении средств.
  • Отладка и устранение неполадок. Упрощает изоляцию проблем при управлении изменениями версий.

В следующих разделах описаны различные механизмы управления версиями различных компонентов в проектах .NET:

Управление версией пакета SDK с помощью global.json

Вы можете закрепить версию SDK для .NET для проекта или решения с помощью файла global.json. Этот файл указывает версию пакета SDK, используемую при выполнении команд .NET CLI, и не зависит от версии среды выполнения, используемой целевыми объектами проекта.

Создайте файл global.json в корневом каталоге решения:

dotnet new globaljson --sdk-version 9.0.100 --roll-forward latestFeature

Эта команда создает следующий файл global.json, который фиксирует SDK на версии 9.0.100 или любой более поздней патч или фичер-бэнд в майорной версии 9.0.

{
  "sdk": {
    "version": "9.0.100",
    "rollForward": "latestFeature"
  }
}

Политика rollForward определяет, как выбирается версия пакета SDK, когда точная версия недоступна. Эта конфигурация гарантирует, что при обновлении Visual Studio или установке нового пакета SDK проект продолжает использовать пакет SDK 9.0.x до явного обновления файла global.json .

Для получения дополнительной информации см. обзор global.json.

Поведение анализатора управления

Анализаторы кода могут вводить новые предупреждения или изменять поведение между версиями. Вы можете управлять версиями анализатора для поддержания согласованных сборок с помощью AnalysisLevel свойства. Это свойство позволяет заблокировать определенную версию правил анализатора, предотвращая появление новых правил при обновлении пакета SDK.

<PropertyGroup>
  <AnalysisLevel>9.0</AnalysisLevel>
</PropertyGroup>

Если задано значение 9.0, включены только правила анализатора, отправленные с .NET 9, даже если вы используете пакет SDK для .NET 10. Это предотвращает влияние новых правил анализатора .NET 10 на сборку до тех пор, пока вы не будете готовы к их устранению.

Дополнительные сведения см. в разделе AnalysisLevel.

Управление версиями пакетов NuGet

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

Файлы блокировки пакета

Файлы блокировки пакетов гарантируют, что операции восстановления пакетов используют одинаковые версии пакетов в разных средах. Файл блокировки (packages.lock.json) записывает точные версии всех пакетов и их зависимостей.

Включите файлы блокировки в файле проекта:

<PropertyGroup>
  <RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>
</PropertyGroup>

Чтобы сборки завершались с ошибкой, если файл блокировки устарел:

<PropertyGroup>
  <RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>
  <RestoreLockedMode>true</RestoreLockedMode>
</PropertyGroup>

После включения файлов блокировки запустите dotnet restore, чтобы создать файл packages.lock.json. Зафиксируйте этот файл в системе управления версиями.

Централизованное управление пакетами

Централизованное управление пакетами (CPM) позволяет управлять версиями пакетов в одном расположении для всех проектов в решении. Этот подход упрощает управление версиями и обеспечивает согласованность между проектами.

Создайте файл Directory.Packages.props в корневом каталоге решения:

<Project>
  <PropertyGroup>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
  </PropertyGroup>

  <ItemGroup>
    <PackageVersion Include="Azure.Identity" Version="1.17.0" />
    <PackageVersion Include="Microsoft.Extensions.AI" Version="9.10.1" />
  </ItemGroup>
</Project>

В файлах проекта ссылки на пакеты без указания версии:

<ItemGroup>
  <PackageReference Include="Azure.Identity" />
  <PackageReference Include="Microsoft.Extensions.AI" />
</ItemGroup>

Сопоставление источника пакета

Сопоставление источников пакетов позволяет контролировать, какие каналы NuGet используются для конкретных пакетов, что повышает безопасность и надежность.

Настройте сопоставление источников в файле nuget.config :

<configuration>
  <packageSources>
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
    <add key="contoso" value="https://contoso.com/packages/" />
  </packageSources>

  <packageSourceMapping>
    <packageSource key="nuget.org">
      <package pattern="*" />
    </packageSource>
    <packageSource key="contoso">
      <package pattern="Contoso.*" />
    </packageSource>
  </packageSourceMapping>
</configuration>

Эта конфигурация гарантирует, что все пакеты, начинающиеся с Contoso., загружаются только из contoso, а другие пакеты поступают из nuget.org.

Дополнительные сведения см. в разделе "Восстановление пакета NuGet".

Управление версией MSBuild

Visual Studio поддерживает параллельное установку нескольких версий. Например, можно установить Visual Studio 2026 и Visual Studio 2022 на одном компьютере. Каждая версия Visual Studio включает соответствующий пакет SDK для .NET. При обновлении Visual Studio также обновляется включенная версия пакета SDK. Однако вы можете продолжать использовать более старые версии пакета SDK, установив их отдельно от страницы загрузки .NET.

Версии MSBuild соответствуют версиям Visual Studio. Например, Visual Studio 2022 версии 17.8 включает MSBuild 17.8. Пакет SDK для .NET также включает MSBuild. При использовании dotnet build вы используете версию MSBuild, включенную в SDK, указанном в global.json или самом последнем установленном SDK.

Чтобы использовать определенную версию MSBuild, выполните указанные действия.

  • Используйте dotnet build с закреплённой версией SDK в global.json.
  • Запустите соответствующую командную строку разработчика Visual Studio, которая настраивает среду для msBuild этой версии Visual Studio.
  • Прямой вызов MSBuild из определенной установки Visual Studio (например, "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\MSBuild.exe").

Дополнительные сведения см. в статье sdk для .NET, MSBuild и Visual Studio.

Обновление непрерывной интеграции (CI)

Конвейеры CI выполняют аналогичный процесс обновления, как файлы проекта и Dockerfiles. Как правило, можно обновить конвейеры CI, изменив только значения версий.

Обновление среды размещения

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

Для контейнеров необходимо изменить инструкцииFROM чтобы включить новые номера версий.

В следующем примере Dockerfile демонстрируется извлечение образа ASP.NET Core 9.0.

FROM mcr.microsoft.com/dotnet/aspnet:9.0

В облачной службе, такой как служба приложение Azure, требуется изменение конфигурации.

См. также

  • Last updated on