Roslyn-analyzers: "Do not directly await a Task" should apply only to libraries, not to applications

[svick]

Analyzer package

Microsoft.CodeQuality.Analyzers, version 2.6.0

Analyzer

DoNotDirectlyAwaitATask

Repro steps

1. dotnet new console
2. dotnet add package Microsoft.CodeQuality.Analyzers
3. Add <LangVersion>7.1</LangVersion> to the csproj.

4. Change Program.cs to:

   ```c#
   using System.Threading.Tasks;

   static class Program
   {
   static async Task Main()
   {
   await Task.Delay(1);
   }
   }
   ```

5. dotnet build

Expected behavior

No warning. ConfigureAwait(false) is useful in a library, but is generally not necessary in an application. The description of the warning also only talks about a library.

Actual behavior

> dotnet build
Microsoft (R) Build Engine version 15.5.180.51428 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restore completed in 62,24 ms for C:\code\tmp\hwapp\hwapp.csproj.
Program.cs(7,15): warning CA2007: Do not directly await a Task without calling ConfigureAwait [C:\code\tmp\hwapp\hwapp.csproj]
Program.cs(3,14): warning CA1812: Program is an internal class that is apparently never instantiated. If so, remove the code from the assembly. If this class is intended to contain only static members, make it static (Shared in Visual Basic). [C:\code\tmp\hwapp\hwapp.csproj]
  hwapp -> C:\code\tmp\hwapp\bin\Debug\netcoreapp2.0\hwapp.dll

Build succeeded.

Program.cs(7,15): warning CA2007: Do not directly await a Task without calling ConfigureAwait [C:\code\tmp\hwapp\hwapp.csproj]
Program.cs(3,14): warning CA1812: Program is an internal class that is apparently never instantiated. If so, remove the code from the assembly. If this class is intended to contain only static members, make it static (Shared in Visual Basic). [C:\code\tmp\hwapp\hwapp.csproj]
    2 Warning(s)
    0 Error(s)

Time Elapsed 00:00:09.96

I think the CA1812 above is also invalid; I reported that in a separate issue: https://github.com/dotnet/roslyn-analyzers/issues/1688.

[sharwell]

/cc @AArnott

[AArnott]

I agree that this makes sense for some applications. But for many applications, the .exe itself doesn't constitute the entire application as there may be libraries that are also app-specific that may also not need to always .ConfigureAwait(false). The flipside may also be true: that folks may want to ensure they use ConfigureAwait even in the .exe project.

If we build it into the rule itself that it turn itself off for .exe projects, then users no longer have the option of whether to have it on. But if it treats all projects equally, then users have a choice on a per-project basis to turn it off if they don't like it.

So while I agree with the sentiment for my own apps, I think it makes the rule most generally applicable to everyone if it does its job all the time, and leave it to project owners to turn it off.

[sharwell]

@mavasani I agree with the direction of leaving this to the rule set file or other project-specific configuration, and not attempt to handle this behavior within the analysis rule itself.

[svick]

Is there some way to have it off by default for applications, with some configuration knob to override that default?

[li0nsar3c00l]

Moreover I do get this warning on ASP.NET Core Projects, where it isn't correct according to https://stackoverflow.com/a/40220190

[mavasani]

I plan to add an .editorconfig option to enable end users to configure this rule, once https://github.com/dotnet/roslyn-analyzers/pull/1952 is merged in:

1. Option to configure the CompilationOptions.OutputKind for which the rule executes.
2. Option to configure if the rule should run within async void methods (see https://github.com/dotnet/roslyn-analyzers/issues/1953).

[mavasani]

This is now configurable: https://github.com/dotnet/roslyn-analyzers/pull/1958/files#diff-1b5cdc4937a8cdfc79545945ad6c0783R53. Note the default rule implementation is unchanged, and by default it runs for all output kinds.