Microsoft выпустила общедоступную предварительную версию dotnetup, кросс-платформенного менеджера цепочки инструментов, который устанавливает, обновляет и удаляет .NET SDK и среды выполнения внутри учетной записи пользователя, а не из каталога, управляемого системой. Как сообщается в блоге .NET, этот инструмент был анонсирован 15 октября Четом Хаском, менеджером программы .NET SDK, и он следует модели ржавчины и nvm.
Согласно документации, команды и поведение могут меняться в разных предварительных выпусках, а производственные машины должны продолжать использовать установщики, менеджеры пакетов или Visual Studio.
Дизайн, как описано в объявлении, отслеживает намерения, а не версии. Разработчик запрашивает канал, например последний, lts, предварительный просмотр, ежедневный, основной, например 10, второстепенный, например 10.0, или функциональную группу, например 10.0.1xx, и dotnetup разрешает его как выпуск. Точные версии, как отмечается в сообщении, остаются закрепленными во время обновлений.
Несколько требований могут использовать одну управляемую установку, а инструмент считывает ближайший файл global.json, поэтому групповые сборки остаются детерминированными. Более того, согласно документации, файлы находятся в локальном каталоге данных пользователя в Windows, macOS и Linux, а dotnetup никогда не записывает файлы в Program Files\dotnet или /usr/share/dotnet.
При установке используется сценарий начальной загрузки, полученный из aka.ms с помощью Curl или IRM. Как описано в документации, он помещает двоичный файл в ~/.dotnetup после проверки его контрольной суммы SHA-512, а затем dotnetup init устанавливает последнюю стабильную версию SDK и настраивает оболочку. В документах перечислены три режима доступа: ни один из них не запускает .NET через dotnetup dotnet, не затрагивая среду, оболочка редактирует профиль оболочки и везде, по умолчанию только для Windows, меняет системный PATH и требует повышения прав.
Документы также предупреждают, что режим везде имеет приоритет над копиями на уровне компьютера, включая ту, которую устанавливает Visual Studio, поэтому проекты, для которых не установлен SDK dotnetup, не могут быть собраны. Чтобы избежать этого, программа установки, как сообщается, предлагает перенести существующие установки на уровне всего компьютера.
Как сообщалось, ежемесячное обслуживание представляет собой одно обновление dotnetup, которое повторно разрешает каждый отслеживаемый канал и устанавливает новейшие соответствующие версии. Можно выбрать отдельные среды выполнения, например, установку среды выполнения dotnetup aspnetcore@10.0, а в документации в качестве поддерживаемых компонентов перечислены SDK, среда выполнения .NET, среда выполнения ASP.NET Core и среда выполнения Windows Desktop. После обновления, как указано в сообщении, dotnetup удаляет любой компонент, который не требует оставшихся требований, а удаление SDK или удаление во время выполнения запускает ту же очистку.
Более того, предварительная и ежедневная сборки устанавливаются параллельно с помощью предварительной установки dotnetup sdk или ежедневной установки среды выполнения dotnetup, хотя в документации отмечается, что ежедневные сборки не подписываются кодом. Самообновление dotnetup обновляет сам инструмент. В сообщении утверждается, что в отношении сценариев dotnet-install отслеживаются установленные компоненты, проверка подписи и контрольной суммы, более быстрая установка нескольких версий и одна поверхность CLI на каждой платформе. Заявленный план включает установку на уровне администратора в Windows, замену основанных на сценариях частей задач GitHub Actions и Azure DevOps, а также навыки агента, чтобы помощники ИИ могли использовать этот инструмент по умолчанию.
Между тем, на r/dotnet один разработчик с несколькими месяцами использования похвалил более простую установку Linux, но в верхнем комментарии был задан вопрос, почему кто-то предпочитает dotnetup вместо mise, который некоторые уже используют.
Другие раскритиковали загрузочную загрузку curl-to-shell, попросили пакеты winget, apt или Homebrew, отметили, что Visual Studio не видит установки dotnetup, и хотели, чтобы dotnet-ef и другие инструменты CLI также управлялись. В ответ в блоге Хаск заявил, что пакеты планируются после проверки пользователем.
Для заинтересованных читателей полная документация, включая справочник по командам и сведения о телеметрии, доступна на Microsoft Learn, а отзывы отправляются в категорию dotnetup обсуждений dotnet/sdk GitHub.
