`dotnet watch` removes console color

[zbecknell]

Describe the bug

Whatever changed with how the console output is redirected in preview 8 causes the colors and extra logging to go missing. The below output compares running dotnet run and dotnet watch run:

To Reproduce

Create a new blank hosted project:

dotnet new blazorwasm --hosted

Then run both dotnet run and dotnet watch run on the Server project. Notice there are no colors with watch as well as less output.

For example, I can add this to the WeatherForecastController.Get() method:

_logger.LogWarning("Hope it's not too hot!");

Now view the difference in output when navigating to the Fetch Data page:

Further technical details

• Include the output of dotnet --info

.NET SDK (reflecting any global.json):
 Version:   5.0.100-preview.8.20417.9
 Commit:    fc62663a35

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19041
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\5.0.100-preview.8.20417.9\

Host (useful for support):
  Version: 5.0.0-preview.8.20407.11
  Commit:  bf456654f9

.NET SDKs installed:
  3.1.103 [C:\Program Files\dotnet\sdk]
  3.1.202 [C:\Program Files\dotnet\sdk]
  3.1.401 [C:\Program Files\dotnet\sdk]
  5.0.100-preview.8.20417.9 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.All 2.1.21 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.21 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.0-preview.7.20365.19 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.0-preview.8.20414.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.21 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.0-preview.7.20364.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.0-preview.8.20407.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.1.3 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.1.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.1.7 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.0-preview.7.20366.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.0-preview.8.20411.6 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

• The IDE (VS / VS Code/ VS4Mac) you're running on, and it's version

Tested in Windows Terminal and VS Code terminal.

[zbecknell]

Here's the minimal repro: https://github.com/zbecknell/Preview8Repro

[zbecknell]

Also note: my other logging output destinations are still receiving entries just fine, so it's just the console that's affected.

[ghost]

Thanks for contacting us. We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[danlofquist]

Had the exactly the same issue, I managed to get it working, however a bit hacky.

In the LaunchSettings.json, set command name to something other than 'Project', that seems to mess it up. for example. "commandName": "ProjectX".

"Project" launches Kestrel but without a valid name it loads Kestrel anyway, you do get an error message but it still works. Seems to have something to do with Kestrel launch. Or you can set the log level in the environment variables in the same file.

     "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development",
        "logging__loglevel__microsoft_aspnetcore_hosting" : "Information"
      }

[zbecknell]

@danlofquist Thanks for this workaround! Note that it does disable browser auto-launch and auto-reload when using dotnet watch, but I'd still rather have proper logging in most instances.

[zbecknell]

As of 5.0.0-rc2 we now have all logged items showing in the console (the most important part!), but the color is still missing.

I'm going to edit the title to reflect this improvement.

[danlofquist]

As of 5.0.0-rc2 we now have all logged items showing in the console (the most important part!), but the color is still missing.

It seems to work now, at least on Mac!

[xshaheen]

Same problem here dotnet run works correctly with colors but dotnet watch run work with no colors. If I user @danlofquist workaround I lost the configured port and environment variables in the launch profile and the browser will not launch.

.NET SDK (reflecting any global.json): Version: 5.0.100 Commit: 5044b93829

Runtime Environment: OS Name: Windows OS Version: 10.0.19042 OS Platform: Windows RID: win10-x64 Base Path: C:\Program Files\dotnet\sdk\5.0.100\

[wh33ler]

Same problem here dotnet run works with colors but dotnet watch run does not.

.NET SDK  (reflecting any global.json):
 Version:   5.0.100
 Commit:    5044b93829

Runtime Environment::
 OS Name:     Mac OS X
 OS Version:  11.0
 OS Platform: Darwin
 RID:         osx.11.0-x64
 Base Path:   /usr/local/share/dotnet/sdk/5.0.100/

[kanadaj]

Same issue.

.NET SDK (reflecting any global.json):
 Version:   5.0.100
 Commit:    5044b93829

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19042
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\5.0.100\

Host (useful for support):
  Version: 5.0.0
  Commit:  cf258a14b7

[kieranhoney]

I'm having exactly the same issue, this was working correctly before transitioning to .NET 5. Interestingly I have two projects in the solution, one for an ASP core API and another for a Blazor server application. I can see no difference between either configuration however when running 'dotnet watch run' the API outputs colour correctly, the Blazor application is only in black and white.

[minoibno]

I also had this problem with .NET 5. I found that the problem was a misconfiguration in my launchSettings.json. The launchSettings.json uses the RootNamespace as the profile identifier and I had edited the RootNamespace in my .csproj file. All I had to do is make the profile name in the launchSettings.json equal to the RootNamespace property of the .csproj file and then it worked.

[rabberbock]

For me the issue looks like it has something to with the launchBrowser setting in the launchSettings.json.

Repro

1. dotnet new webapi --name ConsoleColor
2. cd ConsoleColor
3. dotnet watch -v run

4. Remove launchBrowser setting from launchSettings.json

I wonder if the web socket refresh server is messing up the color output. I have not had the time to look into this yet, but perhaps it has to do with the following:

https://github.com/dotnet/aspnetcore/blob/7d73bdaf4b5b3f0775f200b492fd4131ca63d353/src/Tools/dotnet-watch/src/LaunchBrowserFilter.cs#L65-L67

[zbecknell]

Alright, so I finally had time to dig into this.

It's the browser launch specifically that's the culprit. This is because the browser launch depends on reading the standard output from the underlying Process (as you discovered @rabberbock).

When the process is started if it has any handler attached to OnOutput it must set RedirectStandardOutput to true:

https://github.com/dotnet/aspnetcore/blob/cd5303d6d82b067ec5365970229fe34588f924d0/src/Tools/dotnet-watch/src/Internal/ProcessRunner.cs#L102

When this happens we lose our colors. The DataReceivedEventHandler.Data property only contains text with no color info. At the same time, we can't just "look" at the output and still have it appear as it normally would in the console.

What to do?

Given the way this works right now, we cannot have colors and launch the browser (unless there's a way to stop redirecting output when the process has already started, which I didn't find).

The downside is that we also lose the excellent auto-refresh feature, which as far as I can tell could run completely separately from the browser launching. So my proposal for a fix is to simply decouple the two and allow the refresh server to launch without also needing the browser to launch.

I am submitting a simple PR that just moves the refresh server code out of the if statement that launches the browser.

[drk-mtr]

Still an issue - surprised this hasn't got more attention as I find the colours really useful. Removing launchBrowser from launchSettings.json works for me but won't suit other developers on the team so it'd be good to have a proper fix.

[Stoom]

That is such an odd fix... Hopefully the dotnet cli team can fix this the right way.

[dotnetshadow]

I think the title of this issue probably masks the fact it's still happening today even in .net 6, not sure if the title could mention .net 6 and it might be looked at?

[tesar-tech]

Any news for upcoming .net 7?

[treymack]

Another workaround that might not affect other devs on the team - set this environment variable before running dotnet watch:

DOTNET_WATCH_SUPPRESS_LAUNCH_BROWSER=1

In tasks.json in VSCode, that could look like this:

        {
            "label": "Watch ProjectName API",
            "command": "dotnet",
            "type": "process",
            "args": [
                "watch",
                "run",
                "--non-interactive",
                "--project",
                "${workspaceFolder}/src/ProjectName.API/"
            ],
            "options": {
                "env": {
                    "DOTNET_WATCH_SUPPRESS_LAUNCH_BROWSER": "1",
                }
            },
...

[Eltee-Taiwo]

Bump. It's been a year and still just as frustrating.

[mikibakaiki]

still happening! removing the "launchBrowser": true works

[jharrison-dlcg]

I'm also getting this with a simple command line application. .net 8.

[kijanawoodard]

Can confirm on .net 8 blazor created with dotnet new blazor. needed to set "launchBrowser": false to get colors back.

[iappwebdev]

Can confirm this with a web api app. It is insane, that this issue hasn't been fixed for so long.

[iappwebdev]

So I found a solution: set applyThemeToRedirectedOutput to true in the logger configuration. From here: color themes not appearing in output

Log.Logger = new LoggerConfiguration()
            .WriteTo.Console(theme: AnsiConsoleTheme.Literate, applyThemeToRedirectedOutput: true)
            .CreateLogger();

Or in appsettings.json:

"WriteTo": [
  {
    "Name": "Console",
    "Args": {
      "applyThemeToRedirectedOutput": true,
      "theme": "Serilog.Sinks.SystemConsole.Themes.AnsiConsoleTheme::Literate, Serilog.Sinks.Console",
      "outputTemplate": "{Timestamp:yyyy-MM-dd HH:mm:ss.fff} [{Level:u3}] {Message:lj}   [{SourceContext}]{NewLine}{Exception}"
    }
  }
]

Read the configuration:

services.AddSerilog((hostingContext, loggerConfiguration) => loggerConfiguration.ReadFrom.Configuration(configuration));

[olumuyiwa-agboola]

Thank you @iappwebdev, your work around works!

[Meligy]

The applyThemeToRedirectedOutput flag works for Serilog, and I can't believe that it's been there for years. Thanks!

It's still a bit similar to turning off browser starting though. As browser starting does not work if you turn it on. I created an issue for Serilog here https://github.com/serilog/serilog-sinks-console/issues/156.

Given everything, not starting the browser sounds like the tradeoff I'm willing to take.

[aradalvand]

We're almost at .NET 9 and this still hasn't been fixed.

[WillEhrendreich]

Applying the suggestion of setting $env:DOTNET_WATCH_SUPPRESS_LAUNCH_BROWSER=1 has worked, so that's good. I'm shocked this hasn't been taken care of yet though. Do most people not use watch?