Microsoft libera preview do dotnetup, gerenciador de versões do .NET sem direitos de admin

O que é o dotnetup

A Microsoft lançou em 15 de outubro de 2026 o preview público do dotnetup, um gerenciador de toolchain multiplataforma para SDKs e runtimes do .NET↳.NET113 conteúdosNovidades do .NET 9 – o tipo genérico OrderedDictionaryDev (Back & Front) · dez 2024Novidades .NET 10: novas formas de uso do .NET CLIDev (Back & Front) · dez 2025Novidades do .NET 5: implementando um proxy reverso com YARP + ASP.NET 5Dev (Back & Front) · nov 2020Ver tudo em Dev (Back & Front) →. O anúncio foi feito por Chet Husk, program manager do .NET SDK, no .NET Blog, e a ferramenta segue o modelo já conhecido do rustup (Rust) e do nvm (Node.js).

A diferença central em relação ao instalador tradicional é onde os arquivos ficam. Em vez de gravar em Program Files\dotnet no Windows ou /usr/share/dotnet no Linux↳Linux34 conteúdosKali Linux em um Servidor VPS: como, quando e por que usar?DevSecOps · dez 2024Construindo um Windows Service ou Linux Daemon com Worker Service & .NET Core – Parte 2Dev (Back & Front) · jul 2020Criando uma WebApi utilizando .NET, Linux e VSCodeDev (Back & Front) · ago 2019Ver tudo em DevSecOps → e macOS, exigindo privilégios administrativos, o dotnetup mantém tudo no diretório local de dados da própria conta do usuário, nos três sistemas operacionais.

A documentação oficial é direta sobre o estágio do projeto: comandos e comportamento podem mudar entre releases de preview, e máquinas de produção devem continuar usando os instaladores oficiais, gerenciadores de pacote ou o Visual Studio.

Canais em vez de números de versão

O design, como descrito no anúncio, rastreia intenção em vez de versão exata. Um desenvolvedor pede um canal como latest, lts, preview ou daily, um major como 10, um minor como 10.0, ou uma feature band como 10.0.1xx, e o dotnetup resolve isso para uma versão concreta.

Versões exatas, segundo a documentação, ficam fixadas durante atualizações automáticas, o que evita que um update de rotina troque silenciosamente a versão que um projeto espera. Várias requisições de versão podem compartilhar uma única instalação gerenciada, e o dotnetup lê o global.json mais próximo do projeto para manter builds de equipe determinísticos.

Instalação e os três modos de acesso

A instalação usa um script de bootstrap buscado em aka.ms via curl ou irm. Segundo a documentação, o script coloca o binário em ~/.dotnetup depois de checar o checksum SHA-512, e o comando dotnetup init instala o SDK estável mais recente e configura o shell.

Os documentos listam três modos de acesso:

• none: roda o .NET através de dotnetup dotnet, sem tocar no ambiente do sistema.
• shell: edita o perfil do shell do usuário.
• everywhere: modo padrão só no Windows, altera o PATH do sistema e precisa de elevação de privilégios.

A documentação também avisa que o modo everywhere tem precedência sobre cópias instaladas para a máquina inteira, incluindo a que o Visual Studio instala. Na prática, isso significa que projetos que precisam de um SDK que o dotnetup não instalou podem simplesmente falhar ao compilar. Para evitar esse cenário, o processo de configuração oferece migrar instalações existentes de máquina inteira para dentro do dotnetup.

Atualização mensal e limpeza automática

A manutenção mensal vira um único comando, dotnetup update, que re-resolve todos os canais rastreados e instala as versões mais novas que casam com cada um. Runtimes individuais também podem ser alvo direto, como em dotnetup runtime install aspnetcore@10.0. A documentação lista SDK, runtime do .NET, runtime do ASP.NET Core e Windows Desktop runtime como componentes suportados.

Depois de um update, o dotnetup remove qualquer componente que nenhum requisito rastreado ainda precise, e os comandos sdk uninstall ou runtime uninstall disparam a mesma limpeza. É um comportamento parecido com o que gerenciadores de pacote de linguagem já fazem, mas inédito para o ecossistema .NET nativo da Microsoft.

Builds preview e daily lado a lado

Versões preview e daily instalam lado a lado com builds estáveis através de dotnetup sdk install preview ou dotnetup runtime install daily, embora a documentação deixe claro que builds daily não são assinadas digitalmente. O comando dotnetup self update atualiza a própria ferramenta.

Em comparação com os scripts dotnet-install que a Microsoft já distribuía, a empresa reivindica rastreamento dos componentes instalados, validação de assinatura e checksum, instalações multi-versão mais rápidas e uma única superfície de linha de comando igual em qualquer plataforma.

O que a comunidade já está questionando

No r/dotnet, a recepção inicial mistura elogio e ceticismo. Um desenvolvedor que já usa a ferramenta há meses elogiou a simplificação do setup no Linux, mas o comentário mais votado da thread perguntou por que alguém escolheria o dotnetup em vez do mise, ferramenta que várias pessoas já usam para gerenciar versões de múltiplas linguagens, não só .NET.

Outras críticas apontadas na comunidade:

• O modelo de bootstrap via curl ou irm direto para o shell, sem pacote nativo.
• Pedido por pacotes winget, apt ou Homebrew em vez do script.
• O fato de o Visual Studio não enxergar instalações feitas pelo dotnetup.
• A ausência de gerenciamento para ferramentas de CLI como o dotnet-ef.

Em resposta no próprio blog, Husk afirmou que pacotes nativos estão planejados, mas dependem de validação com usuários do preview antes de entrarem no roteiro.

Roadmap e o que falta

O roteiro divulgado pela Microsoft inclui instalações em nível administrativo no Windows (hoje restritas ao modo everywhere), substituição das partes baseadas em script das tasks de GitHub Actions e Azure DevOps, e a criação de agent skills para que assistentes de IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → usem o dotnetup por padrão ao configurar ambientes.

Para quem desenvolve em .NET no Brasil, o ganho mais imediato mira máquinas corporativas travadas, onde pedir privilégio de administrador para trocar de SDK é fricção real e recorrente. A dúvida que fica em aberto, levantada pela própria comunidade na fonte, é se vale a pena adotar uma ferramenta exclusiva do .NET quando o mise já resolve o mesmo problema para várias linguagens ao mesmo tempo, dentro de um único fluxo de trabalho.

Fonte: InfoQ