Windows: Implement a way to enable color in console even when the output is redirected

[NickCraver]

This is a follow-up to #33980 which was closed as fixed by #47935, but only for Unix/Linux, because Unix and Windows use a different PAL for the tail end of console. The ultimate feature was enabling a new environmental variable: DOTNET_SYSTEM_CONSOLE_ALLOW_ANSI_COLOR_REDIRECTION, which when set to 1 or true will still emit color codes when the console is redirected (e.g. under CI conditions for logging).

Here's the Unix PAL implementation (also respecting NO_COLOR):

runtime/src/libraries/System.Console/src/System/ConsolePal.Unix.cs

Line 874 in ed04fef

string? envVar = Environment.GetEnvironmentVariable("DOTNET_SYSTEM_CONSOLE_ALLOW_ANSI_COLOR_REDIRECTION");

And here's the Windows PAL: https://github.com/dotnet/runtime/blob/ed04fef3b744ad179f4c570b873721d09534c017/src/libraries/System.Console/src/System/ConsolePal.Windows.cs

Having color output in environments like GitHub Actions is immensely helpful when finding errors in massive logs for example, compare these Unix and Windows runs today (here's an example PR, though the logs will likely expire long-term):

The ask is: can we please make DOTNET_SYSTEM_CONSOLE_ALLOW_ANSI_COLOR_REDIRECTION work on Windows as well?

cc @0xced @Tyrrrz @stephentoub

[ghost]

Tagging subscribers to this area: @dotnet/area-system-console
See info in area-owners.md if you want to be subscribed.

Issue Details

---

This is a follow-up to #33980 which was closed as fixed by #47935, but only for Unix/Linux, because Unix and Windows use a different PAL for the tail end of console. The ultimate feature was enabling a new environmental variable: DOTNET_SYSTEM_CONSOLE_ALLOW_ANSI_COLOR_REDIRECTION, which when set to 1 or true will still emit color codes when the console is redirected (e.g. under CI conditions for logging).

Here's the Unix PAL implementation (also respecting NO_COLOR):

runtime/src/libraries/System.Console/src/System/ConsolePal.Unix.cs

Line 874 in ed04fef

string? envVar = Environment.GetEnvironmentVariable("DOTNET_SYSTEM_CONSOLE_ALLOW_ANSI_COLOR_REDIRECTION");

And here's the Windows PAL: https://github.com/dotnet/runtime/blob/ed04fef3b744ad179f4c570b873721d09534c017/src/libraries/System.Console/src/System/ConsolePal.Windows.cs

Having color output in environments like GitHub Actions is immensely helpful when finding errors in massive logs for example, compare these Unix and Windows runs today (here's an example PR, though the logs will likely expire long-term):

The ask is: can we please make DOTNET_SYSTEM_CONSOLE_ALLOW_ANSI_COLOR_REDIRECTION work on Windows as well?

cc @0xced @Tyrrrz @stephentoub

Author:	NickCraver
Assignees:	-
Labels:	area-System.Console, untriaged
Milestone:	-

[stephentoub]

The ask is: can we please make DOTNET_SYSTEM_CONSOLE_ALLOW_ANSI_COLOR_REDIRECTION work on Windows as well?

This isn't really about making DOTNET_SYSTEM_CONSOLE_ALLOW_ANSI_COLOR_REDIRECTION "work". This is about changing Console on Windows to use ANSI escape sequences rather than using Win32 API calls as it does today.

[NickCraver]

@stephentoub yeah I agree based on what I'm aware of here (admitted novice though). From the user standpoint though, that'd be the functionality/surface still to maintain existing behavior right? We wouldn't want to suddenly light up color output in all scenarios and need some control - ultimately I'm proposing the same control when this is feasible. All I know is with online tools (Actions, DevOps, etc.) I'm searching through a lot of logs spending and a lot of time in oh so many builds...it'd be a huge human time saver for anyone in similar positions if we could colorize.

[stephentoub]

I'm not arguing for or against the scenario or its worth, just highlighting that this isn't simply a matter of flipping a switch or adding an if block to respond to the environment variable: it requires fundamentally changing what Console.ForegroundColor/BackgroundColor/ResetColor do.

[xt0rted]

This explains why I was able to get my dotnet local tools outputting color on GitHub Actions but not the dotnet cli. I'm using the helpers in System.CommandLine.Rendering which writes to Console.Out. I think the ansi support check will need updating too to force color output on Windows.

[xt0rted]

I was seeing differing results locally vs. on github so I dug into it a bit more. The way the dotnet cli emits color codes doesn't work with how the actions build log parses them. Making this change will get us color on windows, but the cli output won't give us the full experience unless github changes the build log parser, or the cli changes how colors are emitted. I opened a discussion about this but the short of it is the build log doesn't show colors when they span multiple lines.

[heaths]

Maybe tangential - and quite likely a separate feature request - but what about adding Console.IsColorEnabled or something and allowing developers to decide whether they want to emit ANSI color codes or not? For built-in console hosts on Windows, this is only a problem in conhost and even then only if virtual terminal sequences weren't enabled. It's been pretty common to enable in third party libraries e.g., golang modules or rustlang crates, since they're often used for CLIs. Providing a capability like that can lead to all sorts of console color theming capabilities / libraries.

As to "how much color" e.g., 16, 256, or truecolor, I've been in a few discussions with @DHowett from the console / Windows Terminal team about this e.g., microsoft/terminal#11057. Since Unix's ConsolePal already loads terminfo it's straight forward to know how many colors are likely supported, if any. On Windows, there's some assumptions than can be made per the aforementioned thread. IIRC, if you can enable VT sequences, truecolor is supported. To enable VT sequences, e.g. in C/C++: https://github.com/microsoft/vswhere/blob/c7a417bfb46cd6a1c3e31a91ba51193d7659b6f8/src/vswhere.lib/Console.cpp#L116-L128