dotnetup: versão instalada e política de atualização não são a mesma coisa

A Microsoft anunciou a prévia pública do dotnetup para gerenciar SDKs e runtimes .NET, inicialmente em instalações no diretório do usuário em Linux e macOS, sem exigir root.[13] A proposta inclui múltiplas versões lado a lado e uma interface uniforme para inventário e atualização.[13] O ponto mais relevante para engenharia é explicitar a intenção de atualização, em vez de tratar toda versão instalada como equivalente.

O que muda para quem desenvolve

Um canal pode acompanhar uma versão principal ou uma faixa de SDK, enquanto uma exigência exata permanece fixa.[13] A integração com global.json preserva o versionamento definido pelos projetos.[13] Após a atualização, componentes sem requisitos associados são removidos, mas versões ainda exigidas por outro canal ou por uma fixação permanecem.[13]

A ferramenta permite coexistência de runtimes específicos, SDKs de prévia e builds diários, e se atualiza separadamente.[13] O fornecedor também destaca validação de assinaturas e checksums e operação não interativa para workers efêmeros de CI.[13]

Minha análise é que o gerenciamento fica mais útil quando a equipe distingue reprodução e acompanhamento. Um projeto pode precisar reproduzir um bug com versão exata enquanto outro acompanha correções de uma linha. Essas intenções devem estar registradas, não depender da memória de quem configurou a estação.

Como aplicar

Faça um piloto em uma máquina descartável ou worker isolado, sem substituir de imediato a instalação compartilhada. Escolha dois projetos: um com SDK fixado e outro autorizado a acompanhar uma linha. Registre os requisitos esperados antes de instalar.

O experimento deve verificar quatro situações: instalação inicial, atualização do canal acompanhado, preservação da versão fixa e remoção apenas do que não é mais necessário. Depois de cada etapa, confira o SDK efetivamente selecionado para cada projeto e execute seus testes.

No ambiente de CI, meça também o tempo de preparação e a possibilidade de reproduzir uma execução anterior. Se o canal pode avançar, guarde a versão que realmente executou o build. A política de atualização não deve apagar a evidência de qual ferramenta gerou um artefato.

Separe esse trabalho da entrega de correções ao usuário final. Para aplicações autocontidas já distribuídas, a Microsoft ressalta que atualizar o runtime da máquina não basta: é necessário republicar e reimplantar a aplicação com o runtime corrigido.[13]

Cuidados e limites

Integrações mais profundas com GitHub Actions e Azure DevOps estão no roteiro, assim como suporte a instalações administrativas do Windows e melhorias específicas para assistentes automatizados.[13] Não convém apresentá-las como capacidades completas desta prévia.

Minha recomendação é avaliar o gerenciador como uma peça de previsibilidade operacional. Instalar sem root não elimina a necessidade de revisar origem, política de versão e permissões do processo. O ganho real aparece quando desenvolvimento, build e implantação conseguem responder qual versão foi usada e por que ela continua ou deixou de ser necessária.

Fonte

[13] Fonte: Microsoft .NET Blog. Publicação: 15/10/2026 às 13:50:00.