Sdk: dotnet run always prints info/compilation stuff to stdout; it shouldn't

[ljw1004]

Steps to reproduce

do dotnet new and dotnet restore and dotnet build and dotnet run > output.txt

Expected behavior

It should create a file output.txt with the contents Hello World!

Actual behavior

The actual contents of the output.txt file are

Project t (.NETStandard,Version=v1.5) was previously compiled. Skipping compilation.
Hello World!

Rationale

I am writing a text-processing utility, similar to grep/sed/awk. It's obviously crucial that my utility can emit its output directly to stdout without this banner getting in the way.

Environment data

dotnet --version output: 1.0.0-beta-002133

[mellinoe]

I'd like to +1 this. It would be nice if dotnet run didn't print any extra stuff when the project is ready to run. What are others' thoughts on this?

[eerhardt]

/cc @cdmihai

[eerhardt]

maybe it should only print out the "previously compiled" message on --verbose runs.

It would work something like this:

• When dotnet build is called directly, print out the messages as usual.
• When dotnet run is called directly, it calls dotnet build, it should pass in a --verbosity minimal parameter, so build only prints out absolutely necessary things (like build failures)
• When dotnet --verbose run is called directly, everybody prints out everything.

[cdmihai]

There could be some msbuild like flags for the dotnet driver to:

• turn off console logging (--no-console-logger)
• enable file logging (--file-logger)
• have some logging levels (diagnostic, verbose, normal, minimal, etc)

That way users could turn of console logging and enable file logging to separate CLI output (which would go to a file) from the app output.

Or simpler, have dotnet run --no-build. Or dotnet run --no-CLI-output

[eerhardt]

I dislike the dotnet run --no-build option because I always think the default should do the most appropriate thing for the most users.

In this case, if a user calls dotnet run with no options, they don't care whether the project needs to be recompiled or not, they asked the project to be run, so they should only see run's output.

But of course, if the build fails and the project couldn't be run, then the user does care about those errors, because the project was not able to be run.

[brthor]

I like @eerhardt 's POV. When you consider the user's expectations when typing dotnet run it makes sense.

But from another perspective if there's an incremental bug (there's some) and they're expecting their latest bits to run, it might be worthwhile to see that that isn't happening.

[ljw1004]

I come from a perspective of a compiled language where, when you execute it, it never attempts to recompile, and instead only executes the most recent compilation result.

If someone comes from perspective of a script language, they expect the act of executing it to run the latest source code.

I guess ASP.NET has come from the perspective of pretending to be an interpreted language by making the act of compilation be seamless and under-the-hood. Or maybe emulating the "Run" button in IDEs such as Delphi and VS which do an automatic execute-before-run. That's what we've got now in dotnetcli -- except it's not quite seamless.

I wonder, are any other _compiled_ and _command-line-driven_ languages out there also trying to pull the same trick? What do Go and Swift do? Are users really benefiting from having the compilation step be invisible, or are they already well used to it?

[plioi]

I suggested this over in dotnet/cli#3594, but that may get closed as a dupe of this.

Other dotnet commands have --verbosity as an option. dotnet help shows that --verbose is a 'common' option. For consistency, all commands could instead have --verbosity, and dotnet run's default could be set very low.

[blackdwarf]

Dupe of dotnet/cli#3594 . Closing.

[ljw1004]

@glennc advises that dotnet mydll.dll is the way for end users to run the executable, rather than dotnet exec

[shanselman]

It really feels like this needs to get done. I blogged recently about doing "Auto testing" with dotnet watch test, and the verbose output is super annoying. I noticed it, and the comments noticed it.

I don't think it's fair to close this and say just do "dotnet foo.dll" as there are clearly reasons to want to supress some output.

How about a /q or something?

/cc @blackdwarf

[blackdwarf]

@shanselman the Preview 3 bits have dotnet run as very silent by default.

[cheesemacfly]

Could we have what was proposed here: https://github.com/dotnet/cli/issues/13#issuecomment-147847226 instead of just silent/verbose?

[blackdwarf]

@cheesemacfly in the next release of the CLI tools, we will accept --verbosity switch that will accept MSBuild values.

[cheesemacfly]

@blackdwarf ah sweet, I missed that information. Looking forward to the next release!