.NET-Umgebungsvariablen

  • Artikel

Dieser Artikel gilt für: ✔️ .NET Core 3.1 SDK und höher

In diesem Artikel erfahren Sie mehr über die Umgebungsvariablen, die von .NET verwendet werden. Einige Umgebungsvariablen werden von der .NET-Runtime verwendet, während andere nur vom .NET SDK und der .NET-CLI verwendet werden. Einige Umgebungsvariablen werden von allen drei Komponenten verwendet.

.NET-Runtime-Umgebungsvariablen

DOTNET_SYSTEM_NET_HTTP_*

Es gibt mehrere globale Einstellungen für HTTP-Umgebungsvariablen:

  • DOTNET_SYSTEM_NET_HTTP_ENABLEACTIVITYPROPAGATION
    • Gibt an, ob die Aktivitätsweitergabe des Diagnosehandlers für globale HTTP-Einstellungen aktiviert werden soll.
  • DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP2SUPPORT
    • Wenn die Einstellung false oder 0 ist, wird die standardmäßig aktivierte HTTP/2-Unterstützung deaktiviert.
  • DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP3SUPPORT
    • Wenn die Einstellung true oder 1 ist, wird die standardmäßig aktivierte HTTP/3-Unterstützung deaktiviert.
  • DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP2FLOWCONTROL_DISABLEDYNAMICWINDOWSIZING
    • Wenn die Einstellung false oder 0 ist, wird der Standardwert außer Kraft gesetzt und der HTTP/2-Algorithmus für die dynamische Fensterskalierung deaktiviert.
  • DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_FLOWCONTROL_MAXSTREAMWINDOWSIZE
    • Der Standardwert ist 16 MB. Wurde der Wert außer Kraft gesetzt, darf die maximale Größe des Empfangsfensters des HTTP/2-Streams nicht kleiner als 65.535 sein.
  • DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_FLOWCONTROL_STREAMWINDOWSCALETHRESHOLDMULTIPLIER
    • Der Standardwert ist 1.0. Wurde der Wert außer Kraft gesetzt, führen höhere Werte zu einem kürzeren Fenster, aber langsameren Downloads. Darf nicht kleiner als 0 sein.

DOTNET_SYSTEM_GLOBALIZATION_*

  • DOTNET_SYSTEM_GLOBALIZATION_INVARIANT: Siehe Invarianten Modus einstellen
  • DOTNET_SYSTEM_GLOBALIZATION_PREDEFINED_CULTURES_ONLY: Gibt an, ob nur vordefinierte Kulturen geladen werden sollen.
  • DOTNET_SYSTEM_GLOBALIZATION_APPLOCALICU: Gibt an, ob die app-local ICU (International Components of Unicode) verwendet werden soll. Weitere Informationen finden Sie unter App-local ICU.

Invarianten Modus einstellen

Anwendungen können den invarianten Modus auf eine der folgenden Arten aktivieren:

  1. In der Projektdatei:

    <PropertyGroup>
    <InvariantGlobalization>true</InvariantGlobalization>
</PropertyGroup>

  2. In der Datei runtimeconfig.json:

    {
    "runtimeOptions": {
        "configProperties": {
            "System.Globalization.Invariant": true
        }
    }
}

  3. Durch Einstellen des Werts der Umgebungsvariablen DOTNET_SYSTEM_GLOBALIZATION_INVARIANT auf true oder 1.

Wichtig

Ein in der Projektdatei oder runtimeconfig.json festgelegter Wert hat eine höhere Priorität als die Umgebungsvariable.

Weitere Informationen finden sie unter Invarianter Globalisierungsmodus in .NET.

DOTNET_SYSTEM_GLOBALIZATION_USENLS

Dies gilt nur für Windows. Damit die Globalisierung NLS (National Language Support) verwendet, legen Sie DOTNET_SYSTEM_GLOBALIZATION_USENLS auf true oder 1 fest. Um NLS nicht zu verwenden, legen Sie DOTNET_SYSTEM_GLOBALIZATION_USENLS entweder auf false oder 0 fest.

DOTNET_SYSTEM_NET_SOCKETS_*

Dieser Abschnitt konzentriert sich auf zwei System.Net.Sockets Umgebungsvariablen:

  • DOTNET_SYSTEM_NET_SOCKETS_INLINE_COMPLETIONS
  • DOTNET_SYSTEM_NET_SOCKETS_THREAD_COUNT

Socketfortsetzungen werden vom Ereignisthread an System.Threading.ThreadPool gesendet. Dadurch wird vermieden, dass Fortsetzungen die Ereignisbehandlung blockieren. Damit Fortsetzungen direkt im Ereignisthread ausgeführt werden können, legen Sie DOTNET_SYSTEM_NET_SOCKETS_INLINE_COMPLETIONS auf 1 fest. Standardmäßig ist es deaktiviert.

Hinweis

Diese Einstellung kann die Leistung beeinträchtigen, wenn es aufwendige Arbeiten gibt, die den E/A-Thread länger als nötig beanspruchen. Führen Sie entsprechende Tests durch, um sicherzustellen, dass diese Einstellung die Leistung verbessert.

Mithilfe von TechEmpower-Benchmarks, die viele kleine Socketlese- und schreibvorgänge bei sehr hoher Auslastung generieren, kann eine einzelne Socket-Engine bis zu 30 x64- und acht Arm64-CPU-Kerne auslasten. Die große Mehrheit der Szenarien in echten Umgebungen generiert keine Auslastung in dieser Größe (Hunderttausende Anforderungen pro Sekunde), und ein einzelner Producer ist fast immer ausreichend. Um jedoch sicherzustellen, dass extreme Auslastungen verarbeitet werden können, können Sie DOTNET_SYSTEM_NET_SOCKETS_THREAD_COUNT verwenden, um den berechneten Wert außer Kraft zu setzen. Wird der berechnete Wert nicht außer Kraft gesetzt, wird folgender Wert verwendet:

  • Wenn DOTNET_SYSTEM_NET_SOCKETS_INLINE_COMPLETIONS 1 ist, wird der Wert Environment.ProcessorCount verwendet.
  • Wenn DOTNET_SYSTEM_NET_SOCKETS_INLINE_COMPLETIONS nicht 1 ist, wird RuntimeInformation.ProcessArchitecture ausgewertet.
    • Im Falle von Arm oder Arm64 wird der Wert der Kerne pro Engine auf 8 festgelegt, andernfalls auf 30.
  • Bei Verwendung der ermittelten Kerne pro Engine der Höchstwert von entweder 1 oder Environment.ProcessorCount über den Kernen pro Engine.

DOTNET_SYSTEM_NET_DISABLEIPV6

Dies hilft zu ermitteln, ob die IP Version 6 (IPv6) deaktiviert ist oder nicht. Wenn die Einstellung auf true oder 1 lautet, ist IPv6 deaktiviert, sofern in System.AppContext nicht anders angegeben.

DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER

Sie können einen der folgenden Mechanismen verwenden, um einen Prozess für die Verwendung des älteren HttpClientHandler zu konfigurieren:

Verwenden Sie im Code die Klasse AppContext:

AppContext.SetSwitch("System.Net.Http.UseSocketsHttpHandler", false);

Switch AppContext kann auch durch eine Konfigurationsdatei festgelegt werden. Weitere Informationen zum Konfigurieren von Switches finden Sie unter AppContext für Bibliotheksconsumer.

Dies kann auch über die Umgebungsvariable DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER erreicht werden. Zum Deaktivieren legen Sie den Wert auf false oder 0 fest.

Hinweis

Ab .NET 5 ist die Einstellung HttpClientHandler nicht mehr verfügbar.

DOTNET_Jit* und DOTNET_GC*

Es gibt zwei belastungsbezogene Features für die JIT- und JIT-generierten GC-Informationen: JIT-Belastung und GC-Lochbelastung. Diese Features bieten während der Entwicklung eine Möglichkeit, Grenzfälle und Szenarien aus der „realen Praxis“ zu ermitteln, ohne komplexe Anwendungen entwickeln zu müssen. Die folgenden Umgebungsvariablen sind verfügbar:

  • DOTNET_JitStress
  • DOTNET_JitStressModeNamesOnly
  • DOTNET_GCStress

JIT-Belastung

JIT-Belastung kann auf verschiedene Weise aktiviert werden. Legen Sie DOTNET_JitStress auf einen ganzzahligen Wert ungleich 0 fest, um basierend auf einem Hash des Methodennamens unterschiedliche Ebenen von JIT-Optimierungen zu generieren. Um alle Optimierungen anzuwenden, legen Sie z. B. DOTNET_JitStress=2 fest. Eine weitere Möglichkeit zum Aktivieren der JIT-Belastung ist das Festlegen von DOTNET_JitStressModeNamesOnly=1 und das anschließende Anfordern der Belastungsmodi (durch Leerzeichen getrennt) in der Variablen DOTNET_JitStressModeNames.

Betrachten Sie beispielsweise Folgendes:

DOTNET_JitStressModeNames=STRESS_USE_CMOV STRESS_64RSLT_MUL STRESS_LCL_FLDS

GC-Lochbelastung

Das Aktivieren der GC-Lochbelastung führt dazu, dass GCs immer an bestimmten Stellen auftreten und dies hilft, GC-Löcher zu identifizieren. Die GC-Lochbelastung kann mithilfe der Umgebungsvariablen DOTNET_GCStress aktiviert werden.

Weitere Informationen finden Sie unter Untersuchen von JIT und GC-Lochbelastung.

JIT-Speicherbarrieren

Der Code-Generator für Arm64 ermöglicht das Entfernen aller MemoryBarriers-Anweisungen, indem DOTNET_JitNoMemoryBarriers auf 1 festgelegt wird.

DOTNET_RUNNING_IN_CONTAINER und DOTNET_RUNNING_IN_CONTAINERS

Die offiziellen .NET-Images (Windows und Linux) legen die bekannten Umgebungsvariablen fest:

  • DOTNET_RUNNING_IN_CONTAINER
  • DOTNET_RUNNING_IN_CONTAINERS

Diese Werte werden verwendet, um zu bestimmen, wann Ihre ASP.NET Core-Workloads im Kontext eines Containers ausgeführt werden.

DOTNET_SYSTEM_CONSOLE_ALLOW_ANSI_COLOR_REDIRECTION

Wenn Console.IsOutputRedirectedtrue ist, können Sie ANSI-Farbcode ausgeben, indem Sie DOTNET_SYSTEM_CONSOLE_ALLOW_ANSI_COLOR_REDIRECTION auf 1 oder true festlegen.

  • DOTNET_SYSTEM_DIAGNOSTICS_DEFAULTACTIVITYIDFORMATISHIERARCHIAL: Bei 1 oder true ist das standardmäßige Format der Aktivitäts-ID hierarchisch.
  • DOTNET_SYSTEM_RUNTIME_CACHING_TRACING: Bei der Ausführung als Debug kann die Ablaufverfolgung aktiviert werden, wenn diese true ist.

DOTNET_DiagnosticPorts

Konfiguriert alternative Endpunkte, bei denen Diagnosetools mit der .NET-Runtime kommunizieren können. Weitere Informationen finden Sie in der Dokumentation zum Diagnoseport.

DOTNET_DefaultDiagnosticPortSuspend

Konfiguriert die Runtime so, dass sie beim Start angehalten wird und auf den Befehl Diagnostics IPC ResumeStartup vom angegebenen Diagnoseport wartet, sofern auf 1 festgelegt. Der Standardwert ist 0. Weitere Informationen finden Sie in der Dokumentation zum Diagnoseport.

DOTNET_EnableDiagnostics

Wenn diese Einstellung auf 0 festgelegt ist, werden das Debuggen, die Profilerstellung und andere Diagnosen über den Diagnoseport deaktiviert und können von anderen Diagnoseeinstellungen nicht außer Kraft gesetzt werden. Wird standardmäßig auf 1 festgelegt.

DOTNET_EnableDiagnostics_IPC

Ab .NET 8 wird beim Festlegen von 0 der Diagnoseport deaktiviert und kann nicht von anderen Diagnoseeinstellungen außer Kraft gesetzt werden. Wird standardmäßig auf 1 festgelegt.

DOTNET_EnableDiagnostics_Debugger

Ab .NET 8 wird beim Festlegen von 0 das Debuggen deaktiviert und kann nicht von anderen Diagnoseeinstellungen außer Kraft gesetzt werden. Wird standardmäßig auf 1 festgelegt.

DOTNET_EnableDiagnostics_Profiler

Ab .NET 8 wird beim Festlegen von 0 die Profilerstellung deaktiviert und kann nicht von anderen Diagnoseeinstellungen außer Kraft gesetzt werden. Wird standardmäßig auf 1 festgelegt.

EventPipe-Variablen

Weitere Informationen finden Sie unter EventPipe-Umgebungsvariablen.

  • DOTNET_EnableEventPipe: aktiviert bei Festlegung auf 1 die Ablaufverfolgung über EventPipe.
  • DOTNET_EventPipeOutputPath: der Ausgabepfad, in den die Ablaufverfolgung geschrieben wird.
  • DOTNET_EventPipeOutputStreaming: aktiviert bei Festlegung auf 1 das Streaming in die Ausgabedatei, während die App ausgeführt wird. Standardmäßig werden Ablaufverfolgungsinformationen in einem Kreispuffer gesammelt, und der Inhalt wird beim Herunterfahren der App geschrieben.

.NET SDK- und CLI-Umgebungsvariablen

DOTNET_ROOT, , DOTNET_ROOT(x86)DOTNET_ROOT_X86DOTNET_ROOT_X64

Gibt den Speicherort der .NET-Runtimes an, wenn sie nicht am Standardspeicherort installiert sind. Der Standardspeicherort unter Windows ist C:\Program Files\dotnet. Der Standardspeicherort unter macOS ist /usr/local/share/dotnet. Der Standardspeicherort für die x64-Runtimes auf einem arm64-Betriebssystem befindet sich unter einem x64-Unterordner (also C:\Program Files\dotnet\x64 unter Windows und /usr/local/share/dotnet/x64 unter macOS). Der Standardspeicherort unter Linux variiert je nach Distribution und Installationsmethode. Der Standardspeicherort in Ubuntu 22.04 ist /usr/share/dotnet (bei Installation von packages.microsoft.com) oder /usr/lib/dotnet (bei Installation über Jammy-Feed). Weitere Informationen finden Sie in den folgenden Ressourcen:

Diese Umgebungsvariable wird nur beim Ausführen von Anwendungen über generierte ausführbare Dateien (Apphosts) verwendet. DOTNET_ROOT(x86) wird stattdessen verwendet, wenn eine ausführbare 32-Bit-Datei auf einem 64-Bit-Betriebssystem ausgeführt wird. DOTNET_ROOT_X64 wird stattdessen verwendet, wenn eine 64-Bit-Ausführbare Datei auf einem ARM64-Betriebssystem ausgeführt wird.

DOTNET_HOST_PATH

Gibt den absoluten Pfad zu einem dotnet-Host (dotnet.exe unter Windows, dotnet unter Linux und macOS) an, der zum Starten des derzeit ausgeführten dotnet-Prozesses verwendet wurde. Dies wird vom .NET SDK verwendet, um Tools zu unterstützen, die während .NET SDK-Befehlen ausgeführt werden, um sicherzustellen, dass sie dieselbe dotnet-Runtime für alle untergeordneten dotnet-Prozesse verwenden, die sie für die Dauer des Befehls erstellen. Tools und MSBuild-Aufgaben im SDK, die Binärdateien über den dotnet-Host aufrufen, berücksichtigen diese Umgebungsvariable, um eine konsistente Benutzererfahrung sicherzustellen.

Tools, die dotnet während eines SDK-Befehls aufrufen, sollten den folgenden Algorithmus verwenden, um es zu finden:

  • wenn DOTNET_HOST_PATH festgelegt ist, verwenden Sie diesen Wert direkt
  • verlassen Sie sich andernfalls auf dotnet über die PATH-Umgebungsvariable des Systems

Hinweis

Die DOTNET_HOST_PATH-Umgebungsvariable ist keine allgemeine Lösung zum Auffinden des dotnet-Hosts. Sie soll nur von Tools verwendet werden, die vom .NET SDK aufgerufen werden.

DOTNET_LAUNCH_PROFILE

Mit dem Befehl dotnet run wird diese Variable auf das ausgewählte Startprofil festgelegt.

Angesichts der folgenden Datei launchSettings.json:

{
  "profiles": {
    "First": {
      "commandName": "Project",
    },
    "Second": {
      "commandName": "Project",
    }
  }
}

Und der folgenden Datei Program.cs:

var value = Environment.GetEnvironmentVariable("DOTNET_LAUNCH_PROFILE");
Console.WriteLine($"DOTNET_LAUNCH_PROFILE={value}");

Erzeugen die folgenden Szenarien die gezeigte Ausgabe:

  • Startprofil angegeben und vorhanden

    $ dotnet run --launch-profile First
DOTNET_LAUNCH_PROFILE=First

  • Startprofil nicht angegeben, das erste wird ausgewählt

    $ dotnet run
DOTNET_LAUNCH_PROFILE=First

  • Startprofil angegeben, aber nicht vorhanden

    $ dotnet run --launch-profile Third
The launch profile "Third" could not be applied.
A launch profile with the name 'Third' doesn't exist.
DOTNET_LAUNCH_PROFILE=

  • Ohne Profil starten

    $ dotnet run --no-launch-profile
DOTNET_LAUNCH_PROFILE=

NUGET_PACKAGES

Der Ordner für globale Pakete. Wenn er nicht festgelegt wird, wird standardmäßig ~/.nuget/packages unter Unix oder %userprofile%\.nuget\packages unter Windows verwendet.

DOTNET_SERVICING

Gibt den Speicherort des Wartungsindex an, der vom freigegebenen Host verwendet wird, wenn die Laufzeit geladen wird.

Gibt an, ob bei der ersten Ausführung .NET-Willkommens- und -Telemetriemeldungen angezeigt werden. Bei Festlegung auf true werden diese Meldungen unterdrückt (akzeptierte Werte: true, 1 oder yes), bei Festlegung auf false werden die Meldungen zugelassen (akzeptierte Werte: false, 0 oder no). Sofern dies nicht so festgelegt wurde, lautet der Standardwert false und die Meldungen werden bei der ersten Ausführung angezeigt. Dieses Flag hat keine Auswirkung auf die Telemetrie (siehe DOTNET_CLI_TELEMETRY_OPTOUT zum Deaktivieren der Übermittlung von Telemetriedaten).

DOTNET_CLI_PERF_LOG

Gibt an, ob Leistungsdetails zur aktuellen CLI-Sitzung protokolliert werden. Aktiviert, wenn 1, true oder yes festgelegt sind. Diese Einstellung ist standardmäßig deaktiviert.

DOTNET_GENERATE_ASPNET_CERTIFICATE

Gibt an, ob ein ASP.NET Core-Zertifikat erstellt werden soll. Der Standardwert ist true. Dieser kann jedoch außer Kraft gesetzt werden, indem diese Umgebungsvariable entweder auf 0, false oder no festgelegt wird.

DOTNET_ADD_GLOBAL_TOOLS_TO_PATH

Gibt an, ob der Umgebungsvariablen PATH globale Tools hinzugefügt werden. Der Standardwert ist true. Um dem Pfad keine globalen Tools hinzuzufügen, legen Sie 0, false oder no fest.

DOTNET_CLI_TELEMETRY_OPTOUT

Gibt an, ob Daten zur Nutzung von .NET-Tools gesammelt und an Microsoft gesendet werden. Legen Sie true fest, um die Telemetriefunktion zu deaktivieren (Wert true, 1 oder yes wird akzeptiert). Legen Sie andernfalls fest, dass false Sie sich für die Telemetriefeatures (Wertefalse0, oder no akzeptiert) anmelden möchten. Ohne Festlegung ist der Standardwert false, und die Telemetriefunktion ist aktiviert.

DOTNET_SKIP_FIRST_TIME_EXPERIENCE

Wenn DOTNET_SKIP_FIRST_TIME_EXPERIENCE auf true festgelegt ist, wird der NuGetFallbackFolder nicht auf den Datenträger erweitert, und es werden eine kürzere Begrüßungsnachricht und ein kürzerer Telemetriehinweis angezeigt.

Hinweis

Diese Umgebungsvariable wird in .NET Core 3.0 und höher nicht mehr unterstützt. Verwenden Sie stattdessen DOTNET_NOLOGO.

DOTNET_MULTILEVEL_LOOKUP

Gibt an, ob die .NET-Runtime, das freigegebene Framework oder das SDK am globalen Speicherort aufgelöst werden. Ohne Festlegung ist der Standardwert 1 (logisch true). Legen Sie den Wert auf 0 (logisch false) fest, damit keine Auflösung am globalen Speicherort erfolgt und isolierte .NET-Installationen verwendet werden. Weitere Informationen zu Lookup mit mehreren Ebenen finden Sie unter Multi-level SharedFX lookup (SharedFX-Lookup mit mehreren Ebenen).

Hinweis

Diese Umgebungsvariable gilt nur für Anwendungen für .NET 6 und frühere Versionen. Ab .NET 7 sucht .NET nur an einem Speicherort nach Frameworks. Weitere Informationen finden Sie unter Suche mit mehreren Ebenen ist deaktiviert.

DOTNET_ROLL_FORWARD

Bestimmt das Rollforwardverhalten. Weitere Informationen finden Sie unter Die Option --roll-forward für den Befehl dotnet.

DOTNET_ROLL_FORWARD_TO_PRERELEASE

Wenn diese Option auf 1 (aktiviert) festgelegt ist, wird das Rollforward von einer endgültigen Produktversion zu einer Vorabversion aktiviert. Wenn eine endgültige Releaseversion der .NET-Runtime angefordert wird, werden standardmäßig (0 – deaktiviert) nur installierte endgültige Releaseversionen beim Rollforward berücksichtigt.

Weitere Informationen finden Sie unter Die Option --roll-forward für den Befehl dotnet.

DOTNET_ROLL_FORWARD_ON_NO_CANDIDATE_FX

Deaktiviert Rollforward der Nebenversion, wenn 0 festgelegt ist. Diese Einstellung wird in .NET Core 3.0 durch DOTNET_ROLL_FORWARD abgelöst. Stattdessen sollten die neuen Einstellungen verwendet werden.

DOTNET_CLI_FORCE_UTF8_ENCODING

Erzwingt die Verwendung der UTF-8-Codierung in der Konsole, auch für ältere Versionen von Windows 10, die UTF-8 nicht vollständig unterstützen. Weitere Informationen finden Sie unter SDK no longer changes console encoding after completion (Das SDK ändert die Konsolencodierung nach Abschluss nicht mehr.).

DOTNET_CLI_UI_LANGUAGE

Legt die Sprache der CLI-Benutzeroberfläche mit einem Gebietsschemawert wie en-us fest. Die unterstützten Werte sind identisch mit denen für Visual Studio. Weitere Informationen finden Sie im Abschnitt zum Ändern der Sprache des Installationsprogramms in der Visual Studio-Installationsdokumentation. Es gelten die Regeln des .NET-Ressourcen-Managers, sodass Sie keine genaue Übereinstimmung auswählen müssen, sondern auch Nachfolger in der CultureInfo-Struktur auswählen können. Bei einer Festlegung auf fr-CA findet und verwendet die Befehlszeilenschnittstelle z. B. die fr-Übersetzungen. Wenn Sie eine nicht unterstützte Sprache festlegen, greift die Befehlszeilenschnittstelle auf Englisch zurück.

DOTNET_DISABLE_GUI_ERRORS

Für generierte ausführbare Dateien mit aktivierter Benutzeroberfläche – deaktiviert das Dialogfeld-Popupfenster, das normalerweise bei bestimmten Fehlerklassen angezeigt wird. Es schreibt nur an stderr und beendet sich nur in diesen Fällen.

DOTNET_ADDITIONAL_DEPS

Entspricht der CLI-Option --additional-deps.

DOTNET_RUNTIME_ID

Setzt die erkannte RID außer Kraft.

DOTNET_SHARED_STORE

Speicherort des „gemeinsamen Speichers“, auf den die Assemblyauflösung in einigen Fällen zurückgreift.

DOTNET_STARTUP_HOOKS

Liste der Assemblys zum Laden und Ausführen von Startuphooks.

DOTNET_BUNDLE_EXTRACT_BASE_DIR

Gibt ein Verzeichnis an, in das eine Einzeldateianwendung vor der Ausführung extrahiert wird.

Weitere Informationen finden Sie unter Ausführbare Einzeldateien.

DOTNET_CLI_HOME

Gibt den Speicherort an, in den unterstützende Dateien für .NET CLI-Befehle geschrieben werden sollen. Zum Beispiel:

  • Beschreibbare Pfade für Workload Packs, Manifeste und andere unterstützende Daten.
  • First-run sentinel/lock files for aspects of the .NET CLI's first-run migration and notification experiences.
  • Der standardmäßige Installationsspeicherort des lokalen .NET-Tools.

DOTNET_CLI_CONTEXT_*

  • DOTNET_CLI_CONTEXT_VERBOSE: Um einen ausführlichen Kontext zu aktivieren, legen Sie die Einstellung auf true fest.
  • DOTNET_CLI_CONTEXT_ANSI_PASS_THRU: Um einen ANSI-Passthrough zu aktivieren, legen Sie die Einstellung auf true fest.

DOTNET_CLI_WORKLOAD_UPDATE_NOTIFY_DISABLE

Diese Variable deaktiviert Downloads von Ankündigungsmanifesten im Hintergrund für Workloads. Der Standardwert lautet false (nicht deaktiviert). Ist die Variable auf true festgelegt, sind Downloads deaktiviert. Weitere Informationen finden Sie unter Ankündigungsmanifeste.

DOTNET_CLI_WORKLOAD_UPDATE_NOTIFY_INTERVAL_HOURS

Diese Variable gibt die Mindestanzahl an Stunden an, die zwischen Downloads von Ankündigungsmanifesten im Hintergrund für Workloads liegen müssen. Der Standardwert ist 24, was nicht häufiger als einmal pro Tag ist. Weitere Informationen finden Sie unter Ankündigungsmanifeste.

DOTNET_TOOLS_ALLOW_MANIFEST_IN_ROOT

Gibt an, ob lokale .NET SDK-Tools im Stammordner unter Windows nach Toolmanifestdateien suchen. Der Standardwert ist false.

COREHOST_TRACE

Steuert die Diagnoseablaufverfolgung von den Hostingkomponenten wie dotnet.exe, hostfxr und hostpolicy.

  • COREHOST_TRACE=[0/1] – Standardwert ist 0 – Ablaufverfolgung deaktiviert. Wenn auf 1 festgelegt, ist die Diagnoseablaufverfolgung aktiviert.

  • COREHOST_TRACEFILE=<file path> – hat nur dann Auswirkungen, wenn die Ablaufverfolgung durch Festlegen von COREHOST_TRACE=1 aktiviert wird. Wurde dies so festgelegt, werden die Ablaufverfolgungsinformationen in die angegebene Datei geschrieben, andernfalls in stderr.

  • COREHOST_TRACE_VERBOSITY=[1/2/3/4] – Standardwert ist 4. Die Einstellung wird nur verwendet, wenn die Ablaufverfolgung über COREHOST_TRACE=1 aktiviert wird.

    • 4 – alle Ablaufverfolgungsinformationen werden geschrieben
    • 3 – nur Informationen, Warn- und Fehlermeldungen werden geschrieben
    • 2 – nur Warn- und Fehlermeldungen werden geschrieben
    • 1 – nur Fehlermeldungen werden geschrieben

Die übliche Methode, ausführliche Ablaufverfolgungsinformationen zum Start der Anwendung zu erhalten, besteht darin, vor der Ausführung der Anwendung COREHOST_TRACE=1 und COREHOST_TRACEFILE=host_trace.txt festzulegen. Im aktuellen Verzeichnis wird eine neue Datei host_trace.txt mit detaillierten Informationen erstellt.

SuppressNETCoreSdkPreviewMessage

Bei Festlegung auf true wird beim Aufrufen von dotnet keine Warnung angezeigt, wenn ein Vorschau-SDK verwendet wird.

Konfigurieren von MSBuild in der .NET CLI

Um den MSBuild prozessextern (Out-of-Process) auszuführen, legen Sie die Umgebungsvariable DOTNET_CLI_RUN_MSBUILD_OUTOFPROC entweder auf 1, true oder yes fest. Standardmäßig wird MSBuild prozessintern (In-Process) ausgeführt. Um zu erzwingen, dass MSBuild einen externen, langlebigen Arbeitsknotenprozess zum Erstellen von Projekten verwendet, legen Sie DOTNET_CLI_USE_MSBUILDNOINPROCNODE auf 1, true oder yes fest. Dadurch wird die Umgebungsvariable MSBUILDNOINPROCNODE auf 1 festgelegt (bezeichnet als MSBuild Server V1), da der Eingabeprozess den größten Teil der Arbeit an diese weiterreicht.

DOTNET_MSBUILD_SDK_RESOLVER_*

Hierbei handelt es sich um Außerkraftsetzungen, die dazu verwendet werden, zu erzwingen, dass die aufgelösten SDK-Aufgaben und -Ziele aus einem bestimmten Basisverzeichnis stammen und eine bestimmte Version an MSBuild melden, was - falls unbekannt - möglicherweise null ist. Ein wichtiger Anwendungsfall dafür ist das Testen von SDK-Aufgaben und -Zielen, ohne sie mithilfe der .NET Core SDK bereitzustellen.

  • DOTNET_MSBUILD_SDK_RESOLVER_SDKS_DIR: Setzt das .NET SDK-Verzeichnis außer Kraft.
  • DOTNET_MSBUILD_SDK_RESOLVER_SDKS_VER: Setzt die .NET SDK-Version außer Kraft.
  • DOTNET_MSBUILD_SDK_RESOLVER_CLI_DIR: Setzt den dotnet.exe-Verzeichnispfad außer Kraft.

DOTNET_NEW_PREFERRED_LANG

Konfiguriert die Standardprogrammiersprache für den Befehl dotnet new, wenn der Switch -lang|--language ausgelassen wird. Standardwert: C#. Gültige Werte sind C#, F# oder VB. Weitere Informationen finden Sie unter dotnet new.

dotnet watch-Umgebungsvariablen

Informationen zu dotnet watch-Einstellungen, die als Umgebungsvariablen verfügbar sind, finden Sie unter dotnet watch-Umgebungsvariablen.

Siehe auch