dotnetup-miljökonfiguration

Note

dotnetup finns som offentlig förhandsversion. Dess funktioner och beteende kan ändras före allmän tillgänglighet.

Dotnetup kan konfigurera miljön för att göra de .NET SDK:er och runtimer som installeras tillgängliga. Det gör du genom att ange följande miljövariabler:

• PATH: Gör dotnet kommandot tillgängligt på kommandoraden. Dev-verktyg som Visual Studio eller C# Dev Kit använder PATH också för att hitta .NET SDK:er och runtimes.
• DOTNET_ROOT: Anger för körbara filer för ramverksberoende program var en .NET-installation och dess delade runtimes finns.

Dotnetup stöder olika åtkomstlägen som styr var dessa miljövariabler ställs in. Du kan välja ett åtkomstläge i den första dotnetup-installationen eller senare med dotnetup env kommandot .

Åtkomstläge	Behavior
none	Ändrar inte dessa miljövariabler. Kör .NET med dotnetup dotnet.
shell	Ändrar skalprofilen för att ange dessa miljövariabler. Processer som startas från det kommandoskalet använder de .NET SDK:er och runtimes som installerats av dotnetup.
everywhere	Ändrar systemets PATH och anger miljövariabeln på DOTNET_ROOT användarnivå. Endast tillgängligt på Windows.

Som standard lägger dotnetup också till sig själv i PATH, oavsett inställningen för åtkomstläge. Detta kan styras med dotnetup env set --dotnetup-on-path <true|false>.

Överväganden för läget Everywhere

Läget Everywhere är standard i Windows så att SDK:er och körningsmiljöer som installeras av dotnetup blir tillgängliga från utvecklingsverktyg och från terminaler som använder cmd som skal. Det finns dock vissa saker att tänka på, främst kring hur det interagerar med datoromfattande installationer av .NET SDK och Runtime.

Systemomfattande installationer av .NET finns under mappen Programfiler. De kan installeras med installationsprogram som kan laddas ned från nedladdningssidan för .NET. Visual Studio installerar .NET SDK och Runtime för hela datorn, och installationsprogram för ramverksberoende program kan också installera den .NET Runtime som de är beroende av på en plats som gäller för hela datorn.

I överallt-läge åsidosätter den användarlokala dotnetup-hanterade .NET-installationsroten den datoromfattande .NET-installationsroten. Det innebär att .NET SDK:er och runtimer som är installerade i Programfiler inte är tillgängliga. Projekt som är beroende av dessa SDK:er går inte att kompilera om en matchande SDK inte har installerats. Om en matchande .NET-körningsmiljö inte är installerad kommer ramverksberoende appar inte att starta, och ett fel visas med texten "Du måste installera eller uppdatera .NET för att köra det här programmet".

För att undvika dessa fel erbjuder den första dotnetup-installationen alternativet för att migrera befintliga system .NET SDK- och Runtime-installationer. Du kan också migrera dem explicit genom att köra dotnetup sdk install --migrate-from-system för SDK:er eller dotnetup runtime install --migrate-from-system för runtimer.

Om du aktiverar eller inaktiverar läget överallt måste systemvariabeln PATH ändras, vilket kräver utökade privilegier (dvs. ett UAC-begärandegodkännande eller "Kör som administratör"). Det beror på att installationsprogrammen för hela datorn för .NET lägger till .NET-installationsroten i Program Files i systemsökvägen, och systemsökvägen har företräde framför sökvägen på användarnivå när kommandon tolkas. Dotnetup måste därför ändra systemets PATH för att dotnetup-.NET-installationsroten ska ha företräde.

Eftersom systemsökvägen gäller för alla användare kan dessa ändringar påverka andra användare. Sökvägen som läggs till i system-PATH är som standard under användarens lokala AppData-mapp. Detta är normalt inte tillgängligt för andra användare, så det påverkar inte vilken version av dotnet som väljs. Förhöjda processer (d.v.s. körs som administratör) skulle dock kunna läsa sökvägen och kan till slut oväntat lösa .NET SDK:er eller runtimes från en annan användare.

Sheller som stöds

Stöd för profil- och skriptgenerering:

• Bash
• Z shell
• Fisk
• Pwsh (PowerShell Core)
• PowerShell

Om du inte anger --shell, identifierar dotnetup det aktuella skalet. Använd ett explicit shell när identifieringen inte är tillgänglig eller när du vill uppdatera en annan profil:

dotnetup env set shell --shell zsh

Lagrat och observerat tillstånd

dotnetup.config.json lagrar det valda åtkomstläget och om dotnetup ska vara på PATH. dotnetup env show jämför den konfigurationen med den aktuella profilen och miljön. Den rapporterar drift om det observerade tillståndet inte matchar.

Tillämpa den lagrade konfigurationen på nytt för att korrigera konfigurationsdrift:

dotnetup env set

Nuvarande terminal

Profil- och Windows miljöändringar skriver inte om miljön för den aktuella processen. Öppna en ny terminal, läs in den ändrade profilen med source eller utvärdera det genererade skriptet.

För Bash- eller Z-skal:

eval "$(dotnetup env script)"

För PowerShell:

dotnetup env script --shell pwsh | Invoke-Expression

env script följer den lagrade konfigurationen när du inte anger urvalsalternativ. Använd --dotnet, --dotnetupeller båda för att välja det genererade innehållet.

Ta bort miljökonfiguration

Ta bort alla kopplingar för hanterad miljö:

dotnetup env clear

Det här kommandot motsvarar:

dotnetup env set none --dotnetup-on-path false

Den avinstallerar inte SDK:er eller körmiljöer.