dotnetup: gerenciar versões do .NET não dispensa provar qual SDK fez o build

A Microsoft apresentou o preview público do dotnetup, gerenciador multiplataforma de SDKs e runtimes .NET inspirado em rustup e nvm, com instalações na área do usuário.[12] O anúncio original é de 15 de outubro; a cobertura da InfoQ selecionada nesta edição foi publicada em 21 de outubro.[12] A documentação avisa que comandos e comportamento ainda podem mudar e recomenda os mecanismos tradicionais em máquinas de produção.[12]

O que muda para quem desenvolve

O dotnetup acompanha requisitos de instalação, incluindo canais como latest, lts, preview e daily, além de restrições de versão.[12] O comando dotnetup update resolve novamente esses requisitos, enquanto versões exatas permanecem fixadas.[12] O global.json mais próximo orienta a seleção do SDK.[12]

A distinção útil é entre manter uma família de versões atualizada e reproduzir um build específico. Minha recomendação é registrar qual desses objetivos vale para cada ambiente, em vez de esperar que um único comando resolva os dois sem política explícita.

Há três modos de integração: none exige chamar dotnetup dotnet, shell altera o perfil do shell e everywhere, exclusivo do Windows e padrão nessa plataforma, altera o PATH do sistema e exige elevação.[12] Esse último pode prevalecer sobre o .NET instalado pelo Visual Studio e provocar falhas se o SDK necessário não estiver gerenciado pelo dotnetup.[12]

Como aplicar

Comece em um ambiente de desenvolvimento descartável com o modo que não altera o ambiente. Escolha um repositório com requisito de SDK documentado e confira o global.json antes de executar o build. Registre a instalação efetivamente selecionada, não apenas a versão que você pediu para instalar.

Como experimento, abra duas cópias de projeto com requisitos diferentes e execute os mesmos passos de restauração e compilação em cada uma. Depois, teste uma atualização de canal e compare o que mudou. A reprodução deve mostrar que a política de seleção foi respeitada.

Se a equipe considerar adoção, documente também a volta ao mecanismo anterior e a interação com ferramentas auxiliares. Não comece pelo modo global em uma máquina crítica para descobrir depois qual instalação estava sendo usada.

Cuidados e limites

O bootstrap verifica checksum SHA-512, mas os builds diários disponíveis não são assinados.[12] Essas duas informações não devem ser confundidas como uma garantia única sobre toda instalação feita pela ferramenta.

O gerenciamento abrange SDK e runtimes .NET, ASP.NET Core e Windows Desktop, e atualizações ou desinstalações podem limpar componentes que deixaram de atender a algum requisito.[12] Integrações adicionais e pacotes de distribuição ainda fazem parte do roteiro descrito.[12]

O benefício potencial é tornar o inventário e a seleção de versões mais claros. O critério de adoção deve ser essa previsibilidade no seu fluxo real, incluindo editor e automação. Um preview útil continua sendo um preview, mesmo quando o comando de instalação é curto.

Fonte

[12] Fonte: InfoQ