Новые возможности пакета SDK и инструментов для .NET 8

В этой статье описываются новые функции пакета SDK для .NET и средства для .NET 8.

SDK

В этом разделе содержатся следующие подтопики:

• Оценка проекта на основе ИНТЕРФЕЙСА командной строки
• Выходные данные сборки терминала
• Упрощенные пути вывода
• Команда dotnet workload clean
• Ресурсы dotnet publish и dotnet pack
• Подсистема шаблонов
• Ссылка на источник
• Пакет SDK для исходной сборки

Оценка проекта на основе ИНТЕРФЕЙСА командной строки

MSBuild включает в себя новую функцию, которая упрощает внедрение данных из MSBuild в скрипты или инструменты. Следующие новые флаги доступны для команд CLI, таких как dotnet publish , чтобы получить данные для использования в конвейерах CI и в других местах.

Флаг	Description
--getProperty:<PROPERTYNAME>	Извлекает свойство MSBuild с указанным именем.
--getItem:<ITEMTYPE>	Извлекает элементы MSBuild указанного типа.
--getTargetResults:<TARGETNAME>	Извлекает выходные данные из запуска указанного целевого объекта.

Значения записываются в стандартные выходные данные. Несколько или сложные значения являются выходными данными в формате JSON, как показано в следующих примерах.

>dotnet publish --getProperty:OutputPath
bin\Release\net8.0\

>dotnet publish -p PublishProfile=DefaultContainer --getProperty:GeneratedContainerDigest --getProperty:GeneratedContainerConfiguration
{
  "Properties": {
    "GeneratedContainerDigest": "sha256:ef880a503bbabcb84bbb6a1aa9b41b36dc1ba08352e7cd91c0993646675174c4",
    "GeneratedContainerConfiguration": "{\u0022config\u0022:{\u0022ExposedPorts\u0022:{\u00228080/tcp\u0022:{}},\u0022Labels\u0022...}}"
  }
}

>dotnet publish -p PublishProfile=DefaultContainer --getItem:ContainerImageTags
{
  "Items": {
    "ContainerImageTags": [
      {
        "Identity": "latest",
        ...
    ]
  }
}

Выходные данные сборки терминала

dotnet build имеет новый вариант для создания более обновленных выходных данных сборки. Это средство ведения журнала терминалов выводит ошибки с проектом, из который они пришли, лучше различает различные целевые платформы для многоцеловых проектов и предоставляет сведения о том, что делает сборка в режиме реального времени. Чтобы выбрать новые выходные данные, используйте --tl этот параметр. Дополнительные сведения об этом параметре см. в разделе "Параметры сборки dotnet".

Упрощенные пути вывода

.NET 8 представляет возможность упростить выходной путь и структуру папок для выходных данных сборки. Ранее приложения .NET создали глубокий и сложный набор путей вывода для различных артефактов сборки. Новая упрощенная структура выходного пути собирает все выходные данные сборки в общее расположение, что упрощает прогнозирование инструментов.

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

Команда dotnet workload clean

.NET 8 представляет новую команду для очистки пакетов рабочих нагрузок, которые могут быть оставлены через несколько обновлений пакета SDK для .NET или Visual Studio. Если при управлении рабочими нагрузками возникают проблемы, рассмотрите возможность workload clean безопасного восстановления в известном состоянии, прежде чем повторить попытку. Команда имеет два режима:

• dotnet workload clean

  Выполняет сборку мусора рабочей нагрузки для рабочих нагрузок на основе файлов или MSI, которая очищает потерянные пакеты. Потерянные пакеты находятся из удаленных версий пакета SDK для .NET или пакетов, в которых записи установки для пакета больше не существуют.

  Если Visual Studio установлен, команда также содержит все рабочие нагрузки, которые следует очистить вручную с помощью Visual Studio.

• dotnet workload clean --all

  Этот режим более агрессивный и очищает каждый пакет на компьютере, который имеет текущий тип установки рабочей нагрузки ПАКЕТА SDK (и это не из Visual Studio). Она также удаляет все записи установки рабочей нагрузки для работающей группы компонентов пакета SDK для .NET и ниже.

dotnet publish и dotnet pack ресурсы

dotnet publishdotnet pack Так как команды и команды предназначены для создания производственных активов, они теперь создают Release ресурсы по умолчанию.

В следующих выходных данных показано поведение между dotnet build и , как можно отменить изменения публикации Debug ресурсов, задав для свойства значение PublishReleasefalse.dotnet publish

/app# dotnet new console
/app# dotnet build
  app -> /app/bin/Debug/net8.0/app.dll
/app# dotnet publish
  app -> /app/bin/Release/net8.0/app.dll
  app -> /app/bin/Release/net8.0/publish/
/app# dotnet publish -p:PublishRelease=false
  app -> /app/bin/Debug/net8.0/app.dll
  app -> /app/bin/Debug/net8.0/publish/

Дополнительные сведения см. в разделе "Dotnet pack" использует конфигурацию выпуска и "dotnet publish" использует конфигурацию выпуска.

dotnet restore аудит безопасности

Начиная с .NET 8, вы можете выбрать проверка безопасности для известных уязвимостей при восстановлении пакетов зависимостей. Этот аудит создает отчет об уязвимостях безопасности с именем затронутого пакета, серьезностью уязвимости и ссылкой на рекомендации для получения дополнительных сведений. При запуске dotnet add или dotnet restoreпредупреждения NU1901-NU1904 будут отображаться для всех обнаруженных уязвимостей. Дополнительные сведения см. в разделе "Аудит уязвимостей безопасности".

Подсистема шаблонов

Модуль шаблонов обеспечивает более безопасный интерфейс в .NET 8, интегрируя некоторые функции, связанные с безопасностью NuGet. В них сочетаются все лучшие возможности веб-заданий, а также добавлены некоторые улучшения, среди которых:

• Запретить загрузку пакетов из http:// веб-каналов по умолчанию. Например, следующая команда не сможет установить пакет шаблона, так как исходный URL-адрес не использует HTTPS.

  dotnet new install console --add-source "http://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-public/nuget/v3/index.json"

  Это ограничение можно переопределить с помощью флага --force .

• Для dotnet new, dotnet new installа также dotnet new updateпроверка известных уязвимостей в пакете шаблона. Если обнаружены уязвимости и вы хотите продолжить, необходимо использовать --force флаг.

• Для dotnet newэтого укажите сведения о владельце пакета шаблона. Владение проверяется порталом NuGet и может считаться надежной характеристикой.

• Для dotnet search и dotnet uninstallукажите, установлен ли шаблон из пакета, который является доверенным, то есть он использует зарезервированный префикс.

Source Link

Ссылка на источник теперь включена в пакет SDK для .NET. Цель заключается в том, что путем переключения исходного канала в пакет SDK вместо того, чтобы требовать отдельный <PackageReference> пакет, больше пакетов будет включать эти сведения по умолчанию. Эта информация улучшит интерфейс интегрированной среды разработки для разработчиков.

Примечание.

В качестве побочных эффектов этого изменения сведения о фиксации включаются в InformationalVersion значение встроенных библиотек и приложений, даже тех, которые предназначены для .NET 7 или более ранней версии. Дополнительные сведения см. в статье "Ссылка на источник", включенную в пакет SDK для .NET.

Пакет SDK для исходной сборки

Пакет SDK для дистрибутива Linux (исходная сборка) теперь имеет возможность создавать автономные приложения с помощью пакетов среды выполнения исходной сборки. Пакет среды выполнения для конкретного дистрибутива упаковается в пакет SDK для исходной сборки. Во время автономного развертывания этот пакет среды выполнения будет ссылаться на этот пакет среды выполнения, тем самым обеспечивая возможность использования функции для пользователей.

Поддержка собственного AOT

Впервые в .NET 7 появилась возможность публикации как Native AOT . Публикация приложения с помощью Native AOT создает полностью автономную версию приложения, которая не требует среды выполнения, все включено в один файл. .NET 8 обеспечивает следующие улучшения в публикации Собственных AOT:

• Добавляет поддержку архитектур x64 и Arm64 в macOS.

• Уменьшает размер собственных приложений AOT в Linux до 50 %. В следующей таблице показан размер приложения Hello World, опубликованного в Native AOT, который включает всю среду выполнения .NET в .NET 7 и .NET 8:

  Операционная система	.NET 7	.NET 8
  Linux x64 (с -p:StripSymbols=true)	3.76 МБ	1.84 МБ
  Windows x64	2.85 МБ	1.77 МБ

• Позволяет указать предпочтения оптимизации: размер или скорость. По умолчанию компилятор выбирает создание быстрого кода при учете размера приложения. Однако можно использовать <OptimizationPreference> свойство MSBuild для оптимизации конкретно для одной или другой. Дополнительные сведения см. в статье "Оптимизация развертываний AOT".

Шаблон консольного приложения

Шаблон консольного приложения по умолчанию теперь включает поддержку AOT вне поля. Чтобы создать проект, настроенный для компиляции AOT, просто запустите dotnet new console --aot. Конфигурация проекта, добавленная с помощью --aot трех эффектов:

• Создает собственный автономный исполняемый файл с помощью Native AOT при публикации проекта, например с dotnet publish помощью Visual Studio или Visual Studio.
• Включает анализаторы совместимости для обрезки, AOT и одного файла. Эти анализаторы предупреждают вас о потенциально проблемных частях проекта (если есть).
• Включает эмуляцию времени отладки AOT, чтобы при отладке проекта без компиляции AOT вы получите аналогичный интерфейс AOT. Например, если вы используете System.Reflection.Emit в пакете NuGet, который не был помечен для AOT (и поэтому был пропущен анализатором совместимости), эмуляция означает, что при попытке опубликовать проект с помощью AOT не будет сюрпризов.

Целевые платформы iOS с помощью Собственного AOT

.NET 8 запускает работу, чтобы включить поддержку машинного AOT для платформ iOS. Теперь вы можете создавать и запускать приложения .NET iOS и .NET MAUI с помощью Native AOT на следующих платформах:

• ios
• iossimulator
• maccatalyst
• tvos
• tvossimulator

Предварительное тестирование показывает, что размер приложения на диске уменьшается примерно на 35% для приложений iOS .NET, использующих собственный AOT вместо Mono. Размер приложения на диске для приложений iOS для .NET MAUI уменьшается до 50 %. Кроме того, время запуска также быстрее. Приложения .NET iOS имеют около 28% быстрее времени запуска, в то время как приложения iOS .NET MAUI имеют около 50 % более высокую производительность запуска по сравнению с Mono. Поддержка .NET 8 является экспериментальной и только первым шагом для функции в целом. Дополнительные сведения см. в записи блога .NET MAUI по улучшению производительности .NET 8.

Поддержка собственного AOT доступна как функция согласия, предназначенная для развертывания приложений; Mono по-прежнему является средой выполнения по умолчанию для разработки и развертывания приложений. Чтобы создать и запустить приложение .NET MAUI с помощью Native AOT на устройстве iOS, используйте для dotnet workload install maui установки рабочей нагрузки .NET MAUI и dotnet new maui -n HelloMaui создания приложения. Затем задайте для свойства PublishAottrue MSBuild значение в файле проекта.

<PropertyGroup>
  <PublishAot>true</PublishAot>
</PropertyGroup>

При установке необходимого свойства и запуске dotnet publish , как показано в следующем примере, приложение будет развернуто с помощью Машинного AOT.

dotnet publish -f net8.0-ios -c Release -r ios-arm64  /t:Run

Ограничения

Не все функции iOS совместимы с машинным AOT. Аналогичным образом, не все библиотеки, часто используемые в iOS, совместимы с NativeAOT. Помимо существующих ограничений развертывания Native AOT, в следующем списке показаны некоторые из других ограничений при использовании таких платформ, как iOS:

• Использование собственного AOT включено только во время развертывания приложения (dotnet publish).
• Отладка управляемого кода поддерживается только в Mono.
• Совместимость с платформой .NET MAUI ограничена.

Компиляция AOT для приложений Android

Чтобы уменьшить размер приложения, приложения .NET и .NET MAUI, предназначенные для Android, используют профилированный режим компиляции (AOT) при создании в режиме выпуска. Профилированная компиляция AOT влияет на меньше методов, чем обычная компиляция AOT. В .NET 8 представлено <AndroidStripILAfterAOT> свойство, которое позволяет принять участие в дальнейшей компиляции AOT для приложений Android, чтобы уменьшить размер приложения еще больше.

<PropertyGroup>
  <AndroidStripILAfterAOT>true</AndroidStripILAfterAOT>
</PropertyGroup>

По умолчанию параметр AndroidStripILAfterAOT переопределяет true параметр по умолчанию AndroidEnableProfiledAot , позволяя (почти) обрезать все методы, скомпилированные AOT. Кроме того, можно использовать профилированное удаление AOT и IL, явно задав оба свойства следующим trueобразом:

<PropertyGroup>
  <AndroidStripILAfterAOT>true</AndroidStripILAfterAOT>
  <AndroidEnableProfiledAot>true</AndroidEnableProfiledAot>
</PropertyGroup>

Кросс-встроенные приложения Для Windows

При создании приложений, предназначенных для Windows на платформах, отличных от Windows, результирующий исполняемый файл теперь обновляется с помощью всех указанных ресурсов Win32, например значка приложения, манифеста, сведений о версии.

Ранее приложения должны создаваться в Windows, чтобы иметь такие ресурсы. Исправление этого разрыва в межстрочной поддержке было популярным запросом, так как это был значительный момент боли, влияющий как на сложность инфраструктуры, так и использование ресурсов.

.NET в Linux

Минимальные базовые показатели поддержки для Linux

Минимальные базовые показатели поддержки для Linux были обновлены для .NET 8. Платформа .NET предназначена для Ubuntu 16.04 для всех архитектур. Это особенно важно для определения минимальной glibc версии для .NET 8. .NET 8 не будет запускаться в дистрибутивах, которые включают более старый glibc, например Ubuntu 14.04 или Red Hat Enterprise Linux 7.

Дополнительные сведения см. в разделе "Поддержка семейства Red Hat Enterprise Linux".

Создание собственной платформы .NET в Linux

В предыдущих версиях .NET можно создать .NET из источника, но для создания исходного тарбола из репозитория dotnet/installer , соответствующего выпуску. В .NET 8 это больше не требуется, и вы можете создать .NET в Linux непосредственно из репозитория dotnet/dotnet . В этом репозитории используется dotnet/source-build для создания сред выполнения , средств и пакетов SDK для .NET. Это та же сборка, что Red Hat и Каноническое использование для сборки .NET.

Создание в контейнере является самым простым подходом для большинства пользователей, так как dotnet-buildtools/prereqs образы контейнеров содержат все необходимые зависимости. Дополнительные сведения см. в инструкциях по сборке.

Проверка подписи NuGet

Начиная с .NET 8 NuGet проверяет подписанные пакеты в Linux по умолчанию. NuGet продолжает проверять подписанные пакеты в Windows, а также.

Большинство пользователей не должны заметить проверку. Однако если у вас есть существующий корневой пакет сертификатов, расположенный по адресу /etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem, может возникнуть сбой доверия, сопровождающийся предупреждением NU3042.

Вы можете отказаться от проверки, задав для переменной DOTNET_NUGET_SIGNATURE_VERIFICATION среды значение false.

Анализ кода

.NET 8 включает несколько новых анализаторов кода и средств исправления, чтобы убедиться, что вы используете API библиотеки .NET правильно и эффективно. В следующей таблице перечислены новые анализаторы.

Идентификатор правила	Категория	Description
CA1856	Производительность	Запускается, если ConstantExpectedAttribute атрибут не применяется правильно к параметру.
CA1857	Производительность	Срабатывает, если параметр заметен, ConstantExpectedAttribute но указанный аргумент не является константой.
CA1858	Производительность	Чтобы определить, начинается ли строка с заданным префиксом, лучше вызывать, чем String.IndexOf вызыватьString.StartsWith, а затем сравнивать результат с нулем.
CA1859	Производительность	Это правило рекомендует обновить тип определенных локальных переменных, полей, свойств, параметров метода и возвращаемых типов методов из интерфейса или абстрактных типов до конкретных типов, когда это возможно. Использование конкретных типов приводит к повышению качества созданного кода.
CA1860	Производительность	Чтобы определить, имеет ли тип коллекции какие-либо элементы, лучше использовать Lengthили CountIsEmpty вызыватьEnumerable.Any.
CA1861	Производительность	Массивы констант, передаваемые в качестве аргументов, не повторно используется при вызове, что означает, что новый массив создается каждый раз. Чтобы повысить производительность, рассмотрите возможность извлечения массива в статическое поле чтения.
CA1865-CA1867	Производительность	Перегрузка char является более эффективной перегрузкой для строки с одним символом.
CA2021	Надежность	Enumerable.Cast<TResult>(IEnumerable) и Enumerable.OfType<TResult>(IEnumerable) требуют правильной работы совместимых типов. Расширение и определяемые пользователем преобразования не поддерживаются универсальными типами.
CA1510-CA1513	Удобство поддержки	Вспомогательные средства проще и эффективнее, чем if блок, создающий новый экземпляр исключения. Эти четыре анализатора были созданы для следующих исключений: ArgumentNullException, ArgumentExceptionArgumentOutOfRangeException и ObjectDisposedException.

Диагностика

C# Горячая перезагрузка поддерживает изменение универсальных шаблонов

Начиная с .NET 8, C# Горячая перезагрузка поддерживает изменение универсальных типов и универсальных методов. При отладке консольных, настольных, мобильных или веб-приложений WebAssembly с помощью Visual Studio можно применять изменения к универсальным классам и универсальным методам в коде C# или на страницах Razor. Дополнительные сведения см. в полном списке изменений, поддерживаемых Roslyn.

См. также

• Новые возможности .NET 8