Cannot understand this NRT warning; maybe a bug?

[qrli]

The exchangeName variable should be non-null on line 28:

Visual Studio correctly says that exchangeName is not null:

But the compiler issues warning saying it may be null:

Why?

[CyrusNajmabadi]

can you supply a repro?

[qrli]

After try and error several times, I think I finally reduced it to minimum. It seems to be caused by netstandard2.0.
csproj:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFrameworks>net8.0;netstandard2.0</TargetFrameworks>
    <ImplicitUsings>enable</ImplicitUsings>
	  <LangVersion>10.0</LangVersion>
	  <Nullable>enable</Nullable>
  </PropertyGroup>

</Project>

Program.cs:

Console.WriteLine("Hello, World!");
new Foo().NRTIssue(null);

class Foo
{
    public void NRTIssue(string? s = null)
    {
        if (string.IsNullOrEmpty(s))
            s = "foo";
        M(s);
    }

    void M(string nonNullString)
    {
    }
}

[CyrusNajmabadi]

It is likely not annotated in that tfm.

[MaceWindu]

Yep, IsNullOrEmpty annotations appeared quite late, making multi-tfm projects being polluted by !'s

[qrli]

I came up with this solution:

  <PropertyGroup Condition="'$(TargetFramework)' == 'net6.0'">
    <nullable>Enable</nullable>
  </PropertyGroup>
  <PropertyGroup Condition="'$(TargetFramework)' == 'netstandard2.0'">
    <nullable>Annotations</nullable>
  </PropertyGroup>

[jasonmalinowski]

For what it's worth, @qrli's approach is what we do in Roslyn, effectively: only use the latest TFM for actual validation, the other ones annotation only.

[MaceWindu]

@qrli, that's a nice workaround. Unfortunatelly doesn't work well when you have tfm-specific code for which you need analysis.