sdk: Dotnet run does not preserve colors in child processes

@mattwarren in BenchmarkDotNet brought this to my attention

Steps to reproduce

dotnet new

make Program.cs

using System;

namespace ConsoleApplication
{
    public class Program
    {
        public static void Main(string[] args)
        {
            Console.ForegroundColor = ConsoleColor.Gray;
            Console.WriteLine("Hello World!");
        }
    }
}

dotnet restore dotnet run

Expected behavior

Outputs gray text

Actual behavior

save

Environment data

dotnet --version output:

C:\Users\brthor\code\repro\run-color>dotnet --version
.NET Command Line Tools (1.0.0-beta-001828)

Product Information:
 Version:     1.0.0-beta-001828
 Commit Sha:  N/A

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.10586
 OS Platform: Windows
 Runtime Id:  win10-x64

I’d expect this to be present anywhere because we don’t do anything special to handle Console.SetColor or Console.ForegroundColor calls in child processes.

cc @anurse any ideas on how we could handle this?

About this issue

Original URL
State: closed
Created 8 years ago
Reactions: 6
Comments: 42 (35 by maintainers)

Most upvoted comments

Has this fix been released? I’m still seeing uncolored output when using dotnet watch.

C:\>dotnet --info
.NET Command Line Tools (1.0.0-preview2-003131)

Product Information:
 Version:            1.0.0-preview2-003131
 Commit SHA-1 hash:  635cf40e58

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.10586
 OS Platform: Windows
 RID:         win10-x64

stajs on Sep 21, 2016

This is a problem, it seems, with all things that wrap dotnet run, like dotnet test and dotnet watch.

I am seeing this even today with 1.0.0-preview2-003119. That’s pretty new. We need to fix this soon IMHO, it’s super annoying. @Eilon

shanselman on Jun 20, 2016

We call ForwardStdOut on the command we launch. We shouldn’t. It’s basically that simple 😃. Then the colors should flow properly on Windows.

analogrelay on Mar 21, 2016

@brthor in https://github.com/dotnet/cli/issues/1977#issuecomment-227214885 @shanselman is talking about dotnet watch and dotnet test not dotnet run having this issue. So @BrennanConroy codepath is being hit.

pakrym on Jun 20, 2016

Thanks, @miniksa. That’s helpful. And in that case it sounds like at present there’s no action item for System.Console.dll in corefx.

Which brings us back to @shanselman’s list of issues:

calling dotnet test, watch or any wrapper causes dotnet run to lose all color

As @BrennanConroy suggested, sounds like this is just a matter of removing some calls to ForwardStdOut, and this issue could be used to track that happening.

dotnet cli colors often leave the command prompt in a broken or “last color” state

Sounds like a different issue should be used to track that.

AnsiConsole is missing colors?

Sounds like a different issue should be used to track that.

Win10 1511+ has a new console that understands Ansi and would like it passed directly (but we need to probe for it, somewhere).

Nothing here for corefx. Potentially some kind of work item for dotnet if these issues aren’t addressed by simply removing the superfluous ForwardStdOut calls.

stephentoub on Jun 20, 2016

@livarcocc It isn’t dotnet run that causes the issue, its the command.Create(...).ForwardStdOut().ForwardStdErr(); that calls AnsiConsole which causes the issue

BrennanConroy on Jun 20, 2016

@piotrpMSFT @Petermarcu can we have someone look at this? It’s quite difficult to read the un-colorized output when using dotnet run (or similar). It seems the fix is as easy as not piping the sub-command’s output. The piping breaks streaming the data “live” as well as breaks any console commands that don’t go out on the stream, such as setting the current console colors.

cc @DamianEdwards

Eilon on May 19, 2016