<Nullable> has no effect in old-style csproj

Visual Studio Version: 16.3.1 and 16.4p1

<Nullable>enable</Nullable> is not getting picked up by old-style csprojs. Everything works if we have to put #nullable enable in every file, but that’s distasteful. Is there another workaround

We can’t move to SDK-style csproj until https://github.com/dotnet/project-system/issues/4938 ships in 16.4 in November.

Command-line builds show that NRT is enabled and producing the expected warnings, but the IDE is adamant that nothing is in a nullable context.

Full repro for 16.3.1 and 16.4p1:

public class C
{
    // CS8632 The annotation for nullable reference types should only be used in code within a
    // '#nullable' annotations context.
    //                  ↓
    public void M(string? nullableParameter)
    {
    }
}

Old-style csproj from new project template but with LangVersion 8.0 and Nullable enable:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <ProjectGuid>0098472d-d4d6-4ea1-9a6b-142942f81782</ProjectGuid>
    <OutputType>Library</OutputType>
    <AppDesignerFolder>Properties</AppDesignerFolder>
    <RootNamespace>OldStyleCsproj</RootNamespace>
    <AssemblyName>OldStyleCsproj</AssemblyName>
    <TargetFrameworkVersion>v4.7.2</TargetFrameworkVersion>
    <FileAlignment>512</FileAlignment>
    <Deterministic>true</Deterministic>
    <LangVersion>8.0</LangVersion>
    <Nullable>enable</Nullable>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    <DebugSymbols>true</DebugSymbols>
    <DebugType>full</DebugType>
    <Optimize>false</Optimize>
    <OutputPath>bin\Debug\</OutputPath>
    <DefineConstants>DEBUG;TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
    <DebugType>pdbonly</DebugType>
    <Optimize>true</Optimize>
    <OutputPath>bin\Release\</OutputPath>
    <DefineConstants>TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
  </PropertyGroup>
  <ItemGroup>
    <Reference Include="System"/>
    
    <Reference Include="System.Core"/>
    <Reference Include="System.Xml.Linq"/>
    <Reference Include="System.Data.DataSetExtensions"/>
    
    
    <Reference Include="Microsoft.CSharp"/>
    
    <Reference Include="System.Data"/>
    
    <Reference Include="System.Net.Http"/>
    
    <Reference Include="System.Xml"/>
  </ItemGroup>
  <ItemGroup>
    <Compile Include="Class1.cs" />
    <Compile Include="Properties\AssemblyInfo.cs" />
  </ItemGroup>
  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
 </Project>

User Impact:

Have to choose between not using NRTs in these projects or adding #nullable enable to every source file.

[jnm2]

Thanks for the update. At the end of November when https://github.com/dotnet/project-system/issues/4938 ships, we will be able to use SDK-style csproj.

I would like to express strong disappointment that C# 8 is not supported on .NET Framework, and with the concept that @terrajobst stated: “we don’t support individual language features, we support the set.” Every C# version since at least 3 has had features that only light up when certain types are available. C# 8 is not unique in this. For IAsyncEnumerable, Range, etc, it’s just business as usual as with ValueTuple, FormattableString, Task, and so on. The only thing that is actually different from every previous version is Default Interface Methods which only lights up on capable .NET runtime versions.

C# 8 should be fully supported on .NET Framework, .NET Standard, and .NET Core 2.1, with the definition of full support including the specification that DIM does not light up. Here’s the consequence of not defining full support this way:

• Library authors are put in an impossible situation. If they want to respond to the growing demand to ship nullability annotations, they must either target only .NET Core 3.0 which your own guidelines correctly say is poor practice (https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/) or they must use C# 8.0 on .NET Framework and Standard which you are now also saying not to do.

• There are desktop application developers who cannot move to .NET Core until visual designers are working. You are telling us not to benefit from anything in C# 8. In twelve months, maybe we’ll be able to move if the designers work and there aren’t more outlying issues like https://github.com/dotnet/project-system/issues/4938 which require us to first discover them and then push for them ourselves.

Desktop developers may all be able to move to .NET Core in a year if we’re lucky, but are you really pressuring library authors to drop support for .NET Standard, .NET Framework, and .NET Core 2.1, or else pressuring them to stay unannotated for their end users? How did you intend for this dilemma to be received?

[RudeySH]

We’ve discussed this issue on StackOverflow (here) and came to the conclusion that only Visual Studio’s IntelliSense does not recognize <Nullable>, but msbuild does. And, like @jnm2 also said, using #nullable enable in every file fixes the problem in Visual Studio.

Now tell me, when msbuild supports building .csproj with C# 8.0, and IntelliSense supports the use of #nullable enable, than obviously C# 8.0 is supported in .NET Framework, at least to some degree? Besides nullable reference types, I have verified that some other new features (like using declaration) also work just fine.

If we can get a complete list of what C# 8.0 features work, and what features don’t work in .NET Framework, that would be much more helpful than just saying “it’s not supported”.