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

В этой статье описываются новые функции и улучшения пакета SDK для .NET для .NET 10. Оно было обновлено для предварительной версии 6.

Усовершенствования средств .NET

Средства .NET для конкретной платформы

Теперь средства .NET можно публиковать с поддержкой нескольких идентификаторов среды выполнения (RID) в одном пакете. Авторы инструментов могут упаковать двоичные файлы для всех поддерживаемых платформ, а интерфейс командной строки .NET выберет правильный во время установки или выполнения. Это упрощает разработку и распространение кроссплатформенных инструментов.

Эти расширенные средства поддерживают различные варианты упаковки:

• Зависимость от фреймворка, независимость от платформы (классический режим, выполняется в любом месте при наличии установленного .NET 10)
• Зависящие от фреймворка, зависящие от платформы (небольшие, оптимизированные для каждой платформы)
• Автономный, зависящий от платформы (включает среду выполнения, не требуется установка .NET)
• Упрощенный, специфичный для платформы (меньше, обрезает неиспользуемый код)
• AOT-скомпилированный, специфичный для платформы (максимальная производительность и минимальный объем развертывания)

Эти новые средства работают так же, как обычные опубликованные приложения, поэтому любые варианты публикации, которые можно использовать с приложениями (например, автономные, обрезанные или AOT), также могут применяться к средствам.

Однократное выполнение инструмента

Теперь можно использовать dotnet tool exec команду для выполнения средства .NET без его глобальной или локальной установки. Это особенно полезно для CI/CD или временного использования.

dotnet tool exec --source ./artifacts/package/ toolsay "Hello, World!"
Tool package [email protected] will be downloaded from source <source>.
Proceed? [y/n] (y): y
  _   _          _   _                __        __                 _       _   _
 | | | |   ___  | | | |   ___         \ \      / /   ___    _ __  | |   __| | | |
 | |_| |  / _ \ | | | |  / _ \         \ \ /\ / /   / _ \  | '__| | |  / _` | | |
 |  _  | |  __/ | | | | | (_) |  _      \ V  V /   | (_) | | |    | | | (_| | |_|
 |_| |_|  \___| |_| |_|  \___/  ( )      \_/\_/     \___/  |_|    |_|  \__,_| (_)
                                |/

При этом выполняется скачивание и запуск указанного пакета средства в одной команде. По умолчанию пользователям предлагается подтвердить загрузку, если средство еще не существует локально. Последняя версия выбранного пакета инструментов используется, если не указана явная версия (например, [email protected]).

Однократное выполнение инструмента легко интегрируется с манифестами локальных инструментов. Если вы запускаете инструмент из расположения, где рядом находится .config/dotnet-tools.json, версия инструмента в этой конфигурации будет использоваться вместо последней доступной версии.

Новый dnx скрипт выполнения инструмента

Скрипт dnx предоставляет упрощенный способ выполнения инструментов. Он перенаправит все аргументы в интерфейс командной dotnet строки для обработки, что делает использование инструментов максимально простым:

dnx toolsay "Hello, World!"

Фактическая реализация команды dnx находится в самом интерфейсе командной строки dotnet, что позволяет поведению команды развиваться со временем.

Дополнительные сведения об управлении инструментами .NET см. в разделе "Управление инструментами .NET".

Инспекция интерфейса командной строки с --cli-schema

Новый --cli-schema параметр доступен во всех командах CLI. При использовании он выводит представление JSON дерева команд CLI для вызываемой команды или подкоманда. Это полезно для авторов инструментов, интеграции оболочки и расширенного скрипта.

dotnet clean --cli-schema

Выходные данные предоставляют структурированное, доступное для чтения машинное описание аргументов, параметров и вложенных команд:

{
  "name": "clean",
  "version": "10.0.100-dev",
  "description": ".NET Clean Command",
  "arguments": {
    "PROJECT | SOLUTION": {
      "description": "The project or solution file to operate on. If a file is not specified, the command will search the current directory for one.",
      "arity": { "minimum": 0, "maximum": null }
    }
  },
  "options": {
    "--artifacts-path": {
      "description": "The artifacts path. All output from the project, including build, publish, and pack output, will go in subfolders under the specified path.",
      "helpName": "ARTIFACTS_DIR"
    }
  },
  "subcommands": {}
}

Улучшения приложений на основе файлов

.NET 10 предоставляет значительные обновления в интерфейсе приложений на основе файлов, включая поддержку публикации и собственные возможности AOT. Общие сведения о программах на основе файлов см. в статьях "Файлы" и "Создание и запуск программ C#".

Улучшенные приложения на основе файлов с поддержкой публикации и нативным AOT

Теперь приложения на основе файлов поддерживают публикацию в собственных исполняемых файлах с помощью dotnet publish app.cs команды, что упрощает создание простых приложений, которые можно распространить как собственные исполняемые файлы. Все приложения на основе файлов теперь по умолчанию нацелены на нативную AOT-компиляцию. Если вам нужно использовать пакеты или компоненты, несовместимые с собственным AOT, это можно отключить с помощью #:property PublishAot=false директивы в файле .cs.

Приложения на основе файлов также включают расширенные функции:

• Ссылка на проект: поддержка ссылок на проекты с помощью директивы #:project .
• Доступ к путям во время выполнения: пути к файлам и каталогам приложения доступны во время выполнения System.AppContext.GetData.
• Улучшенная поддержка хешбанга: прямое выполнение команд оболочки с улучшенной обработкой хешбанга, включая поддержку файлов без расширения.

Пример ссылки на проект

#:project ../ClassLib/ClassLib.csproj

var greeter = new ClassLib.Greeter();
var greeting = greeter.Greet(args.Length > 0 ? args[0] : "World");
Console.WriteLine(greeting);

Расширенная поддержка shebang: пример

Теперь можно создать исполняемые файлы C#, которые выполняются непосредственно из оболочки:

#!/usr/bin/env dotnet

Console.WriteLine("Hello shebang!");

Для файлов без расширения:

# 1. Create a single-file C# app with a shebang
cat << 'EOF' > hello.cs
#!/usr/bin/env dotnet
Console.WriteLine("Hello!");
EOF

# 2. Copy it (extensionless) into ~/utils/hello (~/utils is on my PATH)
mkdir -p ~/utils
cp hello.cs ~/utils/hello

# 3. Mark it executable
chmod +x ~/utils/hello

# 4. Run it directly from anywhere
cd ~
hello

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

Дополнительные сведения о собственном AOT см. в статье .NET native AOT.

Очистка ссылок на пакеты, предоставляемые платформой

Начиная с .NET 10 функция аудита NuGet теперь может обрезать ссылки на пакеты, предоставляемые платформой , которые не используются проектом. Эта функция включена по умолчанию для всех net целевых платформ (например, net8.0 и net10.0) и .NET Standard 2.0 и более больших целевых платформ. Это изменение помогает уменьшить количество пакетов, которые восстанавливаются и анализируются во время процесса сборки, что может привести к более быстрому времени сборки и сокращению использования дискового пространства. Это также может привести к уменьшению количества ложных срабатываний при аудите NuGet и использовании других механизмов проверки зависимостей.

Если эта функция включена, может появиться сокращение содержимого созданных .deps.json файлов приложений. Все ссылки на пакеты, предоставленные средой выполнения .NET, автоматически удаляются из созданного файла зависимостей.

Хотя эта функция включена по умолчанию для перечисленных TFM, её можно отключить, установив значение RestoreEnablePackagePruning для свойства false в файле проекта или в файле Directory.Build.props.

Более согласованный порядок команд

Начиная с .NET 10, dotnet средство CLI включает новые псевдонимы для распространенных команд, чтобы упростить их запоминать и вводить. Новые команды показаны в следующей таблице.

Новые формы с приоритетом существительного соответствуют общим стандартам CLI, что делает dotnet более согласованным с другими инструментами. Хотя глагольные формы продолжают работать, лучше использовать формы с существительными для улучшения читаемости и согласованности в скриптах и документации.

Команды CLI по умолчанию для интерактивного режима в интерактивных терминалах

Теперь --interactive флаг включен по умолчанию для команд CLI в интерактивных терминалах. Это изменение позволяет командам динамически извлекать учетные данные или выполнять другие интерактивные действия, не требуя явного задания флага. Для неинтерактивных сценариев можно отключить интерактивность, указав --interactive false.

Скрипты встроенного автодополнения оболочки по клавише Tab

Теперь dotnet интерфейс командной строки поддерживает создание собственных скриптов завершения вкладок для популярных оболочк с помощью dotnet completions generate [SHELL] команды. Поддерживаемые оболочки включают bash, fish, nushell, powershell и zsh. Эти сценарии повышают удобство использования, предоставляя более быстрые и более интегрированные функции завершения вкладок. Например, в PowerShell можно включить автозаполнение, добавив следующее в $PROFILE:

dotnet completions script pwsh | out-String | Invoke-Expression -ErrorAction SilentlyContinue

Консольные приложения могут создавать образы контейнеров в собственном коде

Консольные приложения теперь могут создавать образы контейнеров через dotnet publish /t:PublishContainer, без необходимости в свойстве <EnableSdkContainerSupport> в файле проекта. Это обеспечивает соответствие поведения консольных приложений поведениям приложений ASP.NET Core и Worker SDK.

Явное управление форматом изображений контейнеров

Новое <ContainerImageFormat> свойство позволяет явно задать формат образов контейнеров либо Docker, или OCI. Это свойство переопределяет поведение по умолчанию, которое зависит от формата базового образа и того, является ли контейнер многоархитектурным.

Поддержка платформы тестирования Майкрософт в dotnet test

Начиная с .NET 10, dotnet test изначально поддерживает Microsoft.Testing.Platform. Чтобы включить эту функцию, добавьте следующую конфигурацию в файл dotnet.config :

[dotnet.test.runner]
name = "Microsoft.Testing.Platform"

Дополнительные сведения см. в разделе "Тестирование с помощью dotnet test".