DOTNET-ENVIRONMENT-VARIABLES(7)

💖 NAME 💖

dotnet-environment-variables — .NET environment variables. that's the whole thing bestie, and yet it's SO much 💅

---

📚 DESCRIPTION 📚

This article applies to: ✔️ .NET 6 SDK and later versions.

okay so here's the tea 🍵 — this page is the full rundown of the environment variables .NET uses. some of them are the runtime's whole personality, some are ONLY for the .NET SDK and .NET CLI, and some are shared by all three. no skipping, we're reading all of it 🫶

🏃 .NET runtime environment variables

🌐 DOTNET_SYSTEM_NET_HTTP_*

there's a whole clique of global HTTP environment variable settings:

• DOTNET_SYSTEM_NET_HTTP_ENABLEACTIVITYPROPAGATION — tells you whether or not to enable activity propagation of the diagnostic handler for global HTTP settings.
• DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP2SUPPORT — when set to false or 0, it disables HTTP/2 support, which is enabled by default.
• DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP3SUPPORT — when set to true or 1, it enables HTTP/3 support, which is disabled by default.
• DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP2FLOWCONTROL_DISABLEDYNAMICWINDOWSIZING — when set to false or 0, it overrides the default and disables the HTTP/2 dynamic window scaling algorithm.
• DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_FLOWCONTROL_MAXSTREAMWINDOWSIZE — defaults to 16 MB. when overridden, the maximum size of the HTTP/2 stream receive window cannot be less than 65,535.
• DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_FLOWCONTROL_STREAMWINDOWSCALETHRESHOLDMULTIPLIER — defaults to 1.0. when overridden, higher values result in a shorter window but slower downloads. can't be less than 0.

🌍 DOTNET_SYSTEM_GLOBALIZATION_*

• DOTNET_SYSTEM_GLOBALIZATION_INVARIANT: see set invariant mode, right down there 👇
• DOTNET_SYSTEM_GLOBALIZATION_PREDEFINED_CULTURES_ONLY: specifies whether to load only predefined cultures.
• DOTNET_SYSTEM_GLOBALIZATION_APPLOCALICU: indicates whether to use the app-local International Components of Unicode (ICU). for more info, see App-local ICU.

🧊 Set invariant mode

apps can enable the invariant mode in any of these ways:

1. in the project file:

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

2. in the runtimeconfig.json file:

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

3. by setting the environment variable value DOTNET_SYSTEM_GLOBALIZATION_INVARIANT to true or 1.

⚠️ a value set in the project file or runtimeconfig.json has a higher priority than the environment variable. the config file is the main character here, periodt 👑

for more information, see .NET Globalization Invariant Mode — https://github.com/dotnet/runtime/blob/main/docs/design/features/globalization-invariant-mode.md

🪟 DOTNET_SYSTEM_GLOBALIZATION_USENLS

this one applies to Windows only. for globalization to use National Language Support (NLS), set DOTNET_SYSTEM_GLOBALIZATION_USENLS to either true or 1. to not use it, set DOTNET_SYSTEM_GLOBALIZATION_USENLS to either false or 0.

🔌 DOTNET_SYSTEM_NET_SOCKETS_*

this section is focused on two System.Net.Sockets environment variables:

• DOTNET_SYSTEM_NET_SOCKETS_INLINE_COMPLETIONS
• DOTNET_SYSTEM_NET_SOCKETS_THREAD_COUNT

socket continuations get dispatched to the <xref:System.Threading.ThreadPool?displayProperty=fullName> from the event thread. this keeps continuations from blocking the event handling. if you want continuations to run directly on the event thread, set DOTNET_SYSTEM_NET_SOCKETS_INLINE_COMPLETIONS to 1. it's disabled by default.

⚠️ this setting can make performance worse if there's expensive work that will end up holding onto the IO thread for longer than needed. test it, for real — make sure this setting actually helps performance. don't just set it and pray 🙏

now the benchmark lore 📊 — using TechEmpower benchmarks that generate a lot of small socket reads and writes under a very high load, a single socket engine is capable of keeping busy up to thirty x64 and eight Arm64 CPU cores. the vast majority of real-life scenarios will never generate such a huge load (hundreds of thousands of requests per second), and having a single producer is almost always enough. BUT, to be sure that extreme loads can be handled, you can use DOTNET_SYSTEM_NET_SOCKETS_THREAD_COUNT to override the calculated value. when it's not overridden, this is the value that gets used:

• when DOTNET_SYSTEM_NET_SOCKETS_INLINE_COMPLETIONS is 1, the <xref:System.Environment.ProcessorCount?displayProperty=nameWithType> value is used.
• when DOTNET_SYSTEM_NET_SOCKETS_INLINE_COMPLETIONS is not 1, <xref:System.Runtime.InteropServices.RuntimeInformation.ProcessArchitecture?displayProperty=nameWithType> is evaluated:
  • when Arm or Arm64 the cores per engine value is set to 8, otherwise 30.
• using the determined cores per engine, the maximum value of either 1 or <xref:System.Environment.ProcessorCount?displayProperty=nameWithType> over the cores per engine.

🚫 DOTNET_SYSTEM_NET_DISABLEIPV6

helps determine whether or not Internet Protocol version 6 (IPv6) is disabled. when set to either true or 1, IPv6 is disabled — unless it's otherwise specified in the <xref:System.AppContext?displayProperty=nameWithType>.

🕸️ DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER

you can use one of the following mechanisms to configure a process to use the older HttpClientHandler:

from code, use the AppContext class:

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

the AppContext switch can also be set by a config file. for more info on configuring switches, see AppContext for library consumers.

the same can be achieved via the environment variable DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER. to opt-out, set the value to either false or 0.

🚨 starting in .NET 5, this setting to use <xref:System.Net.Http.HttpClientHandler> is no longer available. it's gone, bestie, we don't talk about it 💀

🐳 DOTNET_RUNNING_IN_CONTAINER and DOTNET_RUNNING_IN_CONTAINERS

the official .NET images (Windows and Linux) set these well-known environment variables:

• DOTNET_RUNNING_IN_CONTAINER
• DOTNET_RUNNING_IN_CONTAINERS

these values are used to determine when your ASP.NET Core workloads are running in the context of a container. container detection, but make it iconic 🫧

🎨 DOTNET_SYSTEM_CONSOLE_ALLOW_ANSI_COLOR_REDIRECTION

when <xref:System.Console.IsOutputRedirected?displayProperty=nameWithType> is true, you can emit ANSI color code by setting DOTNET_SYSTEM_CONSOLE_ALLOW_ANSI_COLOR_REDIRECTION to either 1 or true. colorful output in a redirected stream? slay 💅🌈

🩺 DOTNET_SYSTEM_DIAGNOSTICS and related variables

• DOTNET_SYSTEM_DIAGNOSTICS_DEFAULTACTIVITYIDFORMATISHIERARCHIAL: when 1 or true, the default Activity Id format is hierarchical.
• DOTNET_SYSTEM_RUNTIME_CACHING_TRACING: when running as Debug, tracing can be enabled when this is true.

🔌 DOTNET_DiagnosticPorts

configures alternate endpoints where diagnostic tools can communicate with the .NET runtime. see the Diagnostic Port documentation for more information.

⏸️ DOTNET_DefaultDiagnosticPortSuspend

configures the runtime to pause during startup and wait for the Diagnostics IPC ResumeStartup command from the specified diagnostic port when set to 1. defaults to 0. see the Diagnostic Port documentation for more information.

🛑 DOTNET_EnableDiagnostics

when set to 0, it disables debugging, profiling, and other diagnostics via the Diagnostic Port — and it can't be overridden by other diagnostics settings. defaults to 1.

📡 DOTNET_EnableDiagnostics_IPC

starting with .NET 8, when set to 0, it disables the Diagnostic Port and it can't be overridden by other diagnostics settings. defaults to 1.

🐞 DOTNET_EnableDiagnostics_Debugger

starting with .NET 8, when set to 0, it disables debugging and it can't be overridden by other diagnostics settings. defaults to 1.

🔬 DOTNET_EnableDiagnostics_Profiler

starting with .NET 8, when set to 0, it disables profiling and it can't be overridden by other diagnostics settings. defaults to 1.

🎬 EventPipe variables

see EventPipe environment variables for more information.

• DOTNET_EnableEventPipe: when set to 1, enables tracing via EventPipe.
• DOTNET_EventPipeOutputPath: the output path where the trace will be written.
• DOTNET_EventPipeOutputStreaming: when set to 1, enables streaming to the output file while the app is running. by default trace information is accumulated in a circular buffer and the contents are written at app shutdown.

---

🧰 .NET SDK and CLI environment variables

📍 DOTNET_ROOT, DOTNET_ROOT(x86), DOTNET_ROOT_X86, DOTNET_ROOT_X64

specifies the location of the .NET runtimes, if they are not installed in the default location. here's where things live by default:

• on Windows: C:\Program Files\dotnet
• on macOS: /usr/local/share/dotnet
• for the x64 runtimes on an arm64 OS: under an x64 subfolder, so C:\Program Files\dotnet\x64 on windows and /usr/local/share/dotnet/x64 on macOS.
• on Linux: it varies depending on distro and installment method. the default location on Ubuntu 22.04 is /usr/share/dotnet (when installed from packages.microsoft.com) or /usr/lib/dotnet (when installed from Jammy feed).

for more information, see the following resources:

• Troubleshoot app launch failures
• GitHub issue dotnet/core#7699 — https://github.com/dotnet/core/issues/7699
• GitHub issue dotnet/runtime#79237 — https://github.com/dotnet/runtime/issues/79237

these environment variables are used only when running apps via generated executables (apphosts). the order in which the environment variables are considered is:

1. DOTNET_ROOT_<ARCH>, where <ARCH> is the architecture of the running executable (apphost). for example:
   • DOTNET_ROOT_ARM64 is used for an Arm64 process.
   • DOTNET_ROOT_X64 is used for an x64 process. this process might be running on x64 or Arm64 architecture.
   • DOTNET_ROOT_X86 is used for an x86 process. this process might be running on x86 or x64 architecture.
2. DOTNET_ROOT(x86) is used when a 32-bit process is running on 64-bit Windows. in other cases, this environment variable is ignored.
3. DOTNET_ROOT.

okay that's the runtime + SDK root drama, and there is SO much more coming — keep scrolling bestie, we're not even close to done ✨

DOTNET_HOST_PATH 🛣️

Okay bestie, listen. This one holds the absolute path to a dotnet host — that's dotnet.exe on Windows, and dotnet on Linux and macOS — the one that was used to launch the dotnet process you're currently running. Like, the actual one, not a vibes-based guess.

So what's it for? The .NET SDK uses it to help tools that run during .NET SDK commands make sure they use the same dotnet runtime for any child dotnet processes they spin up for the duration of that command. Tools and MSBuild Tasks inside the SDK that invoke binaries via the dotnet host are expected to honor this env var so everyone gets a consistent experience. Respect the variable, periodt.

If you're a tool that invokes dotnet during an SDK command, here's the algorithm, no cap:

• if DOTNET_HOST_PATH is set, use that value directly
• otherwise, rely on dotnet via the system's PATH

🚨 Important caveat, and I mean it: DOTNET_HOST_PATH is not a general solution for locating the dotnet host. It is only intended to be used by tools that are invoked by the .NET SDK. Don't be out here using it for everything, it's giving "specialized, not universal." 🙈

---

DOTNET_LAUNCH_PROFILE 🚀

The dotnet run command sets this variable to the selected launch profile. That's it, that's the whole vibe.

Given this launchSettings.json file:

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

And this Program.cs file:

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

The following scenarios produce the output shown:

• Launch profile specified and exists 💖

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

• Launch profile not specified, first one selected 🌸

$ dotnet run
DOTNET_LAUNCH_PROFILE=First

• Launch profile specified but does not exist 💀

$ 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=

• Launch with no profile 🫶

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

---

NUGET_PACKAGES 📦

The global packages folder, bestie. If you don't set it, it defaults to ~/.nuget/packages on Unix or %userprofile%\.nuget\packages on Windows. She picks her own home if you don't pick one for her. ✨

---

DOTNET_SERVICING 🔧

Specifies the location of the servicing index that the shared host uses when it's loading the runtime. Point her at the index, she does the rest.

---

DOTNET_NOLOGO 🙅‍♀️

Specifies whether .NET welcome and telemetry messages are displayed on the first run. Set to true to mute these messages (values true, 1, or yes accepted) or set to false to allow them (values false, 0, or no accepted). If it's not set, the default is false and the messages will be displayed on the first run.

👀 Heads up: this flag does not affect telemetry. If you want out of telemetry, see DOTNET_CLI_TELEMETRY_OPTOUT for opting out of sending telemetry. Two separate things, don't confuse them.

---

DOTNET_CLI_PERF_LOG 📊

Specifies whether performance details about the current CLI session are logged. Enabled when set to 1, true, or yes. This is disabled by default. Turn it on when you wanna see the receipts. 🔥

---

DOTNET_GENERATE_ASPNET_CERTIFICATE 📜

Specifies whether to generate an ASP.NET Core certificate. The default value is true, but you can override that by setting this environment variable to either 0, false, or no. Iconic little toggle.

---

DOTNET_ADD_GLOBAL_TOOLS_TO_PATH 🧰

Specifies whether to add global tools to the PATH environment variable. The default is true. To not add global tools to the path, set it to 0, false, or no.

---

DOTNET_CLI_TELEMETRY_OPTOUT 🕵️‍♀️

Specifies whether data about the .NET tools usage is collected and sent to Microsoft. Set to true to opt out of the telemetry feature (values true, 1, or yes accepted). Otherwise, set to false to opt in to the telemetry features (values false, 0, or no accepted). If it's not set, the default is false and the telemetry feature is active. Your privacy, your call. 💅

---

DOTNET_SKIP_FIRST_TIME_EXPERIENCE 🌟

If DOTNET_SKIP_FIRST_TIME_EXPERIENCE is set to true, the NuGetFallbackFolder won't be expanded to disk, and a shorter welcome message and telemetry notice will be shown.

💀 This environment variable is no longer supported in .NET Core 3.0 and later. Use DOTNET_NOLOGO as a replacement. She's retired, let her rest.

---

DOTNET_MULTILEVEL_LOOKUP 🪜

Specifies whether the .NET runtime, shared framework, or SDK are resolved from the global location. If it's not set, it defaults to 1 (logical true). Set the value to 0 (logical false) to not resolve from the global location and have isolated .NET installations instead.

For more information about multi-level lookup, see Multi-level SharedFX Lookup (https://github.com/dotnet/core-setup/blob/master/Documentation/design-docs/multilevel-sharedfx-lookup.md).

🚨 This environment variable only applies to applications that target .NET 6 and earlier versions. Starting in .NET 7, .NET only looks for frameworks in one location. For more information, see Multi-level lookup is disabled.

---

DOTNET_ROLL_FORWARD ⏩

Determines roll forward behavior. For more information, see the --roll-forward option for the dotnet command.

---

DOTNET_ROLL_FORWARD_TO_PRERELEASE 🧪

If set to 1 (enabled), enables rolling forward to a pre-release version from a release version. By default (0 — disabled), when a release version of .NET runtime is requested, roll-forward will only consider installed release versions.

For more information, see the --roll-forward option for the dotnet command.

---

DOTNET_CLI_FORCE_UTF8_ENCODING 🔤

Forces the use of UTF-8 encoding in the console, even for older versions of Windows 10 that don't fully support UTF-8. For more information, see SDK no longer changes console encoding when finished.

---

DOTNET_CLI_UI_LANGUAGE 🗣️

Sets the language of the CLI UI using a locale value such as en-us. The supported values are the same as for Visual Studio. For more information, see the section on changing the installer language in the Visual Studio installation documentation.

The .NET resource manager rules apply, so you don't have to pick an exact match — you can also pick descendants in the CultureInfo tree. For example, if you set it to fr-CA, the CLI will find and use the fr translations. And if you set it to a language that is not supported, the CLI falls back to English. She's multilingual, she's adaptable, she ate. 🌈

---

DOTNET_DISABLE_GUI_ERRORS 🪟

For GUI-enabled generated executables — disables the dialog popup, which normally shows for certain classes of errors. It only writes to stderr and exits in those cases. No popup, no drama, just the exit. 😌

---

DOTNET_ADDITIONAL_DEPS ➕

Equivalent to CLI option --additional-deps.

---

DOTNET_RUNTIME_ID 🆔

Overrides the detected RID. That's the whole thing. Short and slay.

---

DOTNET_SHARED_STORE 🏬

Location of the "shared store" which assembly resolution falls back to in some cases. Your little fallback boutique. 🛍️

---

DOTNET_STARTUP_HOOKS 🪝

List of assemblies to load and execute startup hooks from.

---

DOTNET_BUNDLE_EXTRACT_BASE_DIR 🗂️

Specifies a directory to which a single-file application is extracted before it is executed.

For more information, see Single-file executables.

---

DOTNET_CLI_HOME 🏠

Specifies the location that supporting files for .NET CLI commands should be written to. For example:

• User-writable paths for workload packs, manifests, and other supporting data.
• First-run sentinel/lock files for aspects of the .NET CLI's first-run migrations and notification experiences.
• The default .NET local tool installation location.

She needs a home base and this is it. 🫶

---

DOTNET_CLI_CONTEXT_* 🧠

• DOTNET_CLI_CONTEXT_VERBOSE — To enable a verbose context, set to true.
• DOTNET_CLI_CONTEXT_ANSI_PASS_THRU — To enable an ANSI pass-through, set to true.

---

DOTNET_CLI_WORKLOAD_UPDATE_NOTIFY_DISABLE 🔕

Disables background download of advertising manifests for workloads. Default is false — not disabled. If set to true, downloading is disabled. For more information, see Advertising manifests.

---

DOTNET_CLI_WORKLOAD_UPDATE_NOTIFY_INTERVAL_HOURS ⏰

Specifies the minimum number of hours between background downloads of advertising manifests for workloads. The default is 24, which is no more frequently than once a day. For more information, see Advertising manifests.

---

DOTNET_TOOLS_ALLOW_MANIFEST_IN_ROOT 🌱

Specifies whether .NET SDK local tools search for tool manifest files in the root folder on Windows. The default is false.

---

DOTNET_HOST_TRACE 🔍

This variable applies to .NET 10 and later versions. For older versions, replace the DOTNET_HOST_ prefix with COREHOST_.

Controls diagnostics tracing from the hosting components, such as dotnet.exe, hostfxr, and hostpolicy.

• DOTNET_HOST_TRACE=[0/1] — default is 0 — tracing disabled. If set to 1, diagnostics tracing is enabled.
• DOTNET_HOST_TRACEFILE=<file path> — has an effect only if tracing is enabled by setting DOTNET_HOST_TRACE=1. When set, the tracing information is written to the specified file; otherwise, the trace information is written to stderr.
• DOTNET_HOST_TRACE_VERBOSITY=[1/2/3/4] — default is 4. The setting is used only when tracing is enabled via DOTNET_HOST_TRACE=1.
  • 4 — all tracing information is written
  • 3 — only informational, warning, and error messages are written
  • 2 — only warning and error messages are written
  • 1 — only error messages are written

The typical way to get detailed trace information about application startup is to set DOTNET_HOST_TRACE=1 and DOTNET_HOST_TRACEFILE=host_trace.txt and then run the application. A new file host_trace.txt will be created in the current directory with the detailed information. Detective mode: activated. 🕵️‍♀️✨

---

COREHOST_TRACE 🔎

Controls diagnostics tracing from the hosting components, such as dotnet.exe, hostfxr, and hostpolicy.

🚨 Starting with .NET 10, use the DOTNET_HOST_TRACE environment variables instead. The COREHOST_TRACE variables work the same as DOTNET_HOST_TRACE variables.

• COREHOST_TRACE — see DOTNET_HOST_TRACE.
• COREHOST_TRACEFILE — see DOTNET_HOST_TRACEFILE.
• COREHOST_TRACE_VERBOSITY — see DOTNET_HOST_TRACE_VERBOSITY.

---

SuppressNETCoreSdkPreviewMessage 🤫

If set to true, invoking dotnet won't produce a warning when a preview SDK is being used. Silenced, respectfully.

---

Configure MSBuild in the .NET CLI 🛠️

To execute MSBuild out-of-process, set the DOTNET_CLI_RUN_MSBUILD_OUTOFPROC environment variable to either 1, true, or yes. By default, MSBuild will execute in-proc.

To force MSBuild to use an external working node long-living process for building projects, set DOTNET_CLI_USE_MSBUILDNOINPROCNODE to 1, true, or yes. This will set the MSBUILDNOINPROCNODE environment variable to 1, which is referred to as MSBuild Server V1, as the entry process forwards most of the work to it. She's delegating, and honestly? Main character energy. 👑

🛠️ DOTNET_MSBUILD_SDK_RESOLVER_* 🛠️

ok so these are the overrides, bestie. They force the resolved SDK tasks and targets to come from a given base directory and report a given version to MSBuild — and that version may be null if it's unknown, which is fine, no drama. The one key use case here: testing SDK tasks and targets without deploying them by using the .NET Core SDK. lowkey genius.

• DOTNET_MSBUILD_SDK_RESOLVER_SDKS_DIR — overrides the .NET SDK directory.
• DOTNET_MSBUILD_SDK_RESOLVER_SDKS_VER — overrides the .NET SDK version.
• DOTNET_MSBUILD_SDK_RESOLVER_CLI_DIR — overrides the dotnet.exe directory path.

---

🗣️ DOTNET_NEW_PREFERRED_LANG 🗣️

This one configures the default programming language for the dotnet new command when the -lang|--language switch is omitted. The default value is C#. Valid values are C#, F#, or VB. For more info, go look at dotnet new. ✨

---

⌚ dotnet watch ENVIRONMENT VARIABLES ⌚

For information about dotnet watch settings that are available as environment variables, see dotnet watch environment variables. 👑

---

💖 SEE ALSO 💖

• dotnet command
• Runtime Configuration Files (https://github.com/dotnet/sdk/blob/main/documentation/specs/runtime-configuration-file.md)
• .NET runtime configuration settings

---

and that's a wrap on this whole page, bestie 🫶 this edition dropped 2025-10-30, lives at dotnet-envir...nt-variables(7), and yeah the name really do get truncated like that — iykyk. go forth and set your environment variables, you absolute icon 💅🌸