Provide more immediate feedback when an ASP.NET Core app is running

[leahtmsft]

When you create a new ASP.NET Core app in the command line and run it with dotnet run, it can take a few seconds before any feedback is provided to the user (sometimes much longer if it's the first run). In user studies, we saw first-time .NET users get confused about whether the app is running when there initially isn't any output. Consider providing more immediate feedback that the app is building and running. Also, consider improving the app startup performance.

Repro steps:

1. dotnet new webapp -o WebApp1
2. cd WebApp1
3. dotnet run

Expected:
Near immediate feedback that the app is building and running

Actual:
It takes anywhere between 3-30 seconds before any output is displayed.

[pranavkm]

/cc @DamianEdwards

[Tratcher]

Moving to runtime as this part is managed by Extensions.Hosting.

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. Please help me learn by adding exactly one area label.

[davidfowl]

3-30 seconds sounds like an SDK cold machine build performance issue.

cc @brianrob @DamianEdwards

[eerhardt]

@leahtmsft - Can you try doing:

dotnet new console
dotnet build
dotnet run

And see how long it takes for Hello, world to be printed? Check out #8697 which talks a lot about reasons why dotnet run can take a long time. Can you also try running the .exe in bin\Debug\netcoreapp3.1? How long does that take before you see feedback on the screen? If it is nearly immediate, then this is a duplicate of #8697.

[leahtmsft]

@eerhardt it takes about 2-3 seconds for Hello,world to be printed. Running the .exe is pretty much immediate.

Rather than focusing on the performance aspect, what @danroth27 and I discovered through user testing is that if first-time .NET users don't see any indication that the command is working, they are unable to understand what is happening if they attempt to view the running Blazor app and are faced with a "This site can't be reached" page. The more immediate feedback that I was referring to meant something like adding text after the command is inputted and before the output to indicate that the command is being processed.

[eerhardt]

This isn't something that can be addressed by Extensions.Hosting (nor any managed code inside the application). The issue is that the C# code isn't being executed for 2-3 seconds after hitting dotnet run (see above that even Hello, world is taking 2-3 seconds to print). That issue is a duplicate of #8697.

Another idea would be to put an Initializing... message as the first line in the ASP.NET template, if we want to give the user an indication as soon as possible when the process starts.

Closing as there is nothing actionable Extensions.Hosting can do here. The main issue is #8697.

[danroth27]

Moving this issue to the dotnet/sdk repo per our discussion with @KathleenDollard. In addition to looking at the perf for dotnet run the proposal here is to provide some output that the app is in fact launching.

[KathleenDollard]

A Twitter conversation indicated that people feel strongly on all sides of this question

Proposal: Add verbosity to launchSettings.json and display the corresponding verbosity.
Usage: ASP.NET templates will include verbosity:minimal in their templates so new projects have feedback and existing projects are not affected

Add dotnet run profile to launchSettings.json

...
"dotnetRunSettings": {
      "verbosity": "quiet"
}
...

Valid options are the standard MSBuild options: quiet, minimal, normal, detailed and diagnostic. Abbreviations will not be supported.

It is not an error if the entry is not present. In that case, "quiet" will be inferred for backwards compatibility.

It is not an error if the entry is not present. In that case, "quiet" will be inferred.

Outputting info

verbosity: quiet, no entry, or misspelled entry

Nothing will be output. This is the same behavior as today

verbosity: minimal

The single world "Building..."

> dotnet run
Building...

verbosity: normal, detailed or diagnostic

Output with timing:

> dotnet run
05:56:37.34: Project build started \
05:56:40.04: Project build completed in 2.7s
05:56:40.31: App is launching

If the output with timing means we lose the feature, just do the minimal output.

[wli3]

@KathleenDollard @marcpopMSFT I dig the code a bit and realize the majority of the work will be changes in the launchSettings model to add in this property. It should be more on @vijayrkn 's team. Vijay is it possible for your team to get it in net5.0?

[vijayrkn]

@wli3 - This is not in our current list of deliverables for .NET 5.0/Fe timeframe. I can get a work-item added to our list but I don't think we will be able to pick it up any time soon because of the other deliverables.

Adding @timheuer to help with the prioritization for this against our other deliverables.

[KathleenDollard]

@vijayrkn This came up with a usability issue that @danroth27 and @DamianEdwards illustrated in relation to Blazor which has a serious impact on new users. Adding them for context with prioritization.

[marcpopMSFT]

#12581 has this work and it looks like it's based on dotnetRunMessages being true in the launch settings which is slightly different than the original proposal. @KathleenDollard

[RehanSaeed]

Is there any documentation around what the new dotnetRunMessages setting actually does?

I'm trying to understand whether I need to enable it when I configure other launch settings in launchSettings.json like dotnet watch, WSL2, Docker etc.

[lonix1]

There is an explanation for dotnetRunMessages on StackOverflow.