Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Note
dotnetup está em pré-visualização pública. As suas funcionalidades e comportamento podem mudar antes da disponibilidade geral.
O Dotnetup pode configurar o ambiente para disponibilizar os SDKs .NET e os Runtimes que instala. Faz isto definindo as seguintes variáveis de ambiente:
-
PATH: Torna o comandodotnetdisponível na linha de comandos. Ferramentas de desenvolvimento como o Visual Studio ou o C# Dev Kit também usam oPATHpara localizar SDKs e runtimes .NET. -
DOTNET_ROOT: Indica aos executáveis de aplicação dependentes do framework onde encontrar uma instalação .NET e os seus runtimes partilhados.
O Dotnetup suporta diferentes modos de acesso que controlam onde estas variáveis de ambiente são definidas. Podes escolher um modo de acesso na configuração inicial do dotnetup ou mais tarde com o dotnetup env comando.
| Modo de Acesso | Comportamento |
|---|---|
none |
Não modifica estas variáveis de ambiente. Execute o .NET com dotnetup dotnet. |
shell |
Modifica o perfil do shell para definir estas variáveis de ambiente. Os processos iniciados a partir desse shell usam os SDKs .NET e os Runtimes instalados pelo dotnetup. |
everywhere |
Modifica o sistema PATH e define a variável de ambiente ao nível DOTNET_ROOT do utilizador. Disponível apenas no Windows. |
Por defeito, o dotnetup também se adiciona ao PATH, independentemente da definição do modo de acesso. Isto pode ser controlado com dotnetup env set --dotnetup-on-path <true|false>.
Considerações sobre o modo Everywhere
O modo everywhere é o padrão no Windows, para que os SDKs e runtimes instalados pelo dotnetup estejam disponíveis através das ferramentas de desenvolvimento e dos terminais que usam cmd como shell. No entanto, há alguns aspetos a ter em conta, principalmente sobre como interage com as instalações ao nível do sistema do SDK .NET e do Runtime.
As instalações de .NET em toda a máquina estão localizadas na pasta Program Files. Podem ser instalados com instaladores que podem ser descarregados a partir da página de downloads do .NET. O Visual Studio instala instalações para toda a máquina do SDK .NET e do Runtime, e os instaladores para aplicações dependentes do framework também podem instalar o Runtime .NET do qual dependem na localização para toda a máquina.
No modo everywhere, a raiz de instalação .NET gerida pelo utilizador local do dotnetup irá sobrepor a raiz de instalação .NET a nível da máquina. Isto significa que SDKs .NET e Runtimes instalados em Program Files não estarão disponíveis. Os projetos que dependem desses SDKs falharão na compilação se não for instalado um SDK correspondente. Se não estiver instalado um runtime correspondente, as aplicações dependentes do framework falharão ao iniciar com um erro que diz "Deve instalar ou atualizar .NET para executar esta aplicação."
Para evitar estas falhas, a configuração inicial do dotnetup oferece a opção de migrar o SDK .NET do sistema existente e as instalações do Runtime .NET. Também podes migrá-los explicitamente executando dotnetup sdk install --migrate-from-system para SDKs ou dotnetup runtime install --migrate-from-system para runtimes.
Ativar ou desligar o modo everywhere requer modificar o PATH do sistema, o que requer elevação (ou seja, aprovação de um prompt UAC, ou "Executar como Administrador"). Isto deve-se ao facto de os instaladores a nível de máquina para .NET adicionarem a raiz de instalação do .NET em Program Files ao PATH do sistema, e o PATH do sistema tem prioridade sobre o PATH ao nível do utilizador ao resolver comandos. Portanto, o dotnetup precisa de modificar o PATH do sistema para que a raiz de instalação do dotnetup .NET tenha prioridade.
Como o PATH do sistema se aplica a todos os utilizadores, estas alterações podem afetar outros utilizadores. O caminho que é adicionado ao PATH do sistema está por defeito na pasta AppData local do utilizador. Isto normalmente não será acessível a outros utilizadores, por isso não afetaria que versão de dotnet é resolvida. No entanto, processos elevados (ou seja, a correr como Administrador) seriam capazes de ler o caminho e poderiam acabar por resolver inesperadamente SDKs .NET ou Runtimes de outro utilizador.
Shells suportadas
Suporte para geração de perfis e scripts:
- Bash
- Z shell
- Peixe
- Pwsh (PowerShell Core)
- PowerShell
Se não passar --shell, dotnetup deteta a shell atual. Utilize um shell explícito quando a deteção não estiver disponível ou quando quiser atualizar um perfil diferente:
dotnetup env set shell --shell zsh
Estado armazenado e observado
dotnetup.config.json Armazena o modo de acesso selecionado e se dotnetup deve estar ativado em PATH.
dotnetup env show compara essa configuração com o perfil e ambiente atuais. Reporta deriva se o estado observado não corresponder.
Reaplique a configuração armazenada para corrigir a deriva:
dotnetup env set
Terminal atual
As alterações ao perfil e ao ambiente do Windows não reescrevem o ambiente do processo atual. Abra um novo terminal, carregue o perfil modificado ou avalie o script gerado.
Para shell Bash ou Z shell:
eval "$(dotnetup env script)"
Para o PowerShell:
dotnetup env script --shell pwsh | Invoke-Expression
env script segue a configuração armazenada quando não fornece opções de seleção. Utilize --dotnet, --dotnetup, ou ambos para selecionar o conteúdo gerado.
Remover a configuração do ambiente
Remova todas as ligações do ambiente gerido:
dotnetup env clear
Este comando é equivalente a:
dotnetup env set none --dotnetup-on-path false
Não desinstala SDKs nem runtimes.