Sdk: Ability to suppress welcome message

[adamralph]

The "Welcome to .NET Core 3.0!... " spiel adds considerable noise to CI logs.

While we can work around this by creating a file named "%HOME%/.dotnet/$(dotnet --version).dotnetFirstUseSentinel", this is hacky and adds noise to bulid configs.

It would be better to have a CLI option to suppress the message, e.g.

dotnet build --no-welcome

or

dotnet build --skip-first-time-experience

etc.

[khellang]

IMO, the welcome message should respect the --nologo flag:

Doesn't display the startup banner or the copyright message. Available since .NET Core 3.0 SDK.

[adamralph]

@khellang that would work for me too

[wli3]

Will an environment variable to disable the first run message be enough?

Most of our envs don’t have a commandline counterpart. And it would bloat commandline options if enabled -- it need to be on every command, makes it harder to read help. And the scenario of it is narrow.

[adamralph]

@wli3 thanks for the response.

I'd be happy with an env var instead of a CLI option.

However, I'm currently favouring @khellang's suggestion of the --nologo option suppressing this message. --nologo effectively means "no frills please, just run the command". The vast majority of CI scripts will already be using --nologo so we will get this new feature for free when we start using a new version of the SDK. While the env var will work, it would require everyone to change their build scripts to set it.

I'll change the title of this issue to be less specific about the solution.

[richlander]

I like the CLI-based "--nologo" option because it is a well understood command. As much as possible, we should be making the CLI intuitive.

[wli3]

I like the CLI-based "--nologo" option because it is a well understood command. As much as possible, we should be making the CLI intuitive.

A different option name might be fine, but I don't think we should reuse --nologo. It is not a well understood command. And in fact it is very misleading. dotnet CLI does not print some message every single time like msbuild. This is a one time per installation case. And we already has the verbosity option.

[khellang]

A different option name might be fine, but I don't think we should reuse --nologo. It is not a well understood command.

What do you mean? nologo flags are everywhere, and as @adamralph pointed out:

[it] effectively means "no frills please, just run the command"

I get that it doesn't print something on every run and that MSBuild and the CLI are different beasts, but it feels very awkward to pass --nologo through the dotnet executable and get all that "Welcome to .NET Core!" fluff.

[wli3]

--nologo is in dotnet build only. However the first run message would show up in most of the CLI command run like _dotnet new_.

Alternatively
Would it be ok for only _dotnet build --nologo_ to suppress welcome message?

[eiriktsarpalis]

~I believe --no-logo is the preferred naming convention, at least as far as posix conventions are concerned.~

Scratch that, I didn't realise it's reusing an existing thing.

[eiriktsarpalis]

Would it be ok for only dotnet build --nologo to suppress welcome message?

I tend to agree with your previous point

A different option name might be fine, but I don't think we should reuse --nologo. It is not a well understood command. And in fact it is very misleading. dotnet CLI does not print some message every single time like msbuild. This is a one time per installation case. And we already has the verbosity option.

[adamralph]

Would it be ok for only _dotnet build --nologo_ to suppress welcome message?

No, that would not be enough. For example, some of my builds run dotnet run to kick off a build script, others run dotnet build explictly, and others just run dotnet test and allow the build to be performed implicitly. The welcome message should be suppressed in all cases.

[am11]

before dotnet-cli 3.0:

export DOTNET_SKIP_FIRST_TIME_EXPERIENCE=1
dotnet new console

(aligns with other knobs DOTNET_CLI_TELEMETRY_OPTOUT etc.; many users including AppVeyor CI service were relying on it to keep the build job outputs clean)

in 3.0 (since 3.0 RC2: https://github.com/dotnet/cli/commit/7efbf4770630fd370779d222ce9aba35ffe56100):

touch "$HOME"/.dotnet/"$(dotnet --version)".dotnetFirstUseSentinel
dotnet new console

i think it would be just fine if DOTNET_SKIP_FIRST_TIME_EXPERIENCE is back in 3.1.

[sungam3r]

dotnet CLI does not print some message every single time like msbuild.

@wli3 It depends on the environment. In GitHub Actions I see this message every time after actions/setup-dotnet@v1 / dotnet build.

[adamralph]

@sungam3r the .NET SDK is being installed and run for the very first time in that scenario.

[sungam3r]

I understand it. I am talking exactly about that.

[adamralph]

@sungam3r then this comment holds:

dotnet CLI does not print some message every single time like msbuild.

The dotnet CLI is not printing some message every single time. It's printing it the first time only.

[jaykrell]

-nologo is ancient, like for Visual C++.

[jnm2]

@jaykrell Csc.exe, msbuild.exe (and dotnet build) and the WiX toolset are current tools I know of that use it. Looks like most of the Windows .NET SDK tools use it too, like peverify.exe.

[FiniteReality]

The welcome message is absolutely a hindrance in CI situations. In a C++ project using CMake which has .NET Core support, I have to explicitly work around the welcome message in order to allow CMake to correctly configure and build the project in a CI server.

This is necessary as I have CMake invoke dotnet msbuild to gather some information about the project, like the contents of the Compile ItemGroup, and also the value of TargetFileName so that CMake can correctly rebuild the projects and copy any build outputs on build.

My current work-around is to run dotnet help in the CI build scripts, piping the output to the appropriate null device on Windows and Linux. However, it would be preferable if I could suppress this message entirely, so that I do not have to explain to new developers that they have to run dotnet help before building the project just to make sure that our CMake scripts don't fail.

[sfoslund]

Solved by dotnet/cli#13275

[gitfool]

@sfoslund this looks like we've gone full circle back to the equivalent of the original environment variable, DOTNET_SKIP_FIRST_TIME_EXPERIENCE, which is _perfect_, thank you! 💯

(Dealing with the sentinel file per user, especially when using docker run for the build ci, where the user and / or $HOME is remapped to another user, has been a royal PITA!)

[adamralph]

Which version will this be released in?

[sfoslund]

@adamralph It will be in 3.1.300.

[adamralph]

@sfoslund thanks. Should it be on the 3.1.3xx milestone then?