ContentFiles not included with multiple TargetFrameworks and --no-incremental after upgrading to 6.0.300

Describe the bug

After installing the 6.0.300 SDK, running dotnet build --no-incremental fails when using <TargetFrameworks> (plural) and including a nuget package that bundles source files as contentFiles (as described in docs here).

Specifically, multi-targeted projects using the popular Nullable library by @manuelroemer started failing non-incremental builds after upgrading to 6.0.300. This library provides a shim for nullability annotations on older targets, and does so by including several .cs.pp source files under contentFiles in its nuget package. The problem isn’t with this library, but that the files it provides are being excluded from the build.

It does work when passing a specific framework (such as -f net48), or when only specifying a single <TargetFramework>. So I believe the problem is with content files not being included when dispatching to each framework’s build.

Everything does work when the .NET SDK is pinned to 6.0.203 in a global.json file, so this is new for 6.0.300.

I tried on both Windows 11 21H2 and macOS 12.4 with the same results.

To Reproduce

See minimal repro in issue here: https://github.com/manuelroemer/Nullable/issues/24

Failed build output:

C:\Users\mattj\Code\MyApp>dotnet build --no-incremental                                          
Microsoft (R) Build Engine version 17.2.0+41abc5629 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  All projects are up-to-date for restore.
C:\Users\mattj\Code\MyApp\Program.cs(16,35): error CS0246: The type or namespace name 'NotNullWhenAttribute' could not be found (are you m
issing a using directive or an assembly reference?) [C:\Users\mattj\Code\MyApp\MyApp.csproj]
C:\Users\mattj\Code\MyApp\Program.cs(16,35): error CS0246: The type or namespace name 'NotNullWhen' could not be found (are you missing a 
using directive or an assembly reference?) [C:\Users\mattj\Code\MyApp\MyApp.csproj]
  MyApp -> C:\Users\mattj\Code\MyApp\bin\Debug\net6.0\MyApp.dll

Build FAILED.

C:\Users\mattj\Code\MyApp\Program.cs(16,35): error CS0246: The type or namespace name 'NotNullWhenAttribute' could not be found (are you m 
issing a using directive or an assembly reference?) [C:\Users\mattj\Code\MyApp\MyApp.csproj]
C:\Users\mattj\Code\MyApp\Program.cs(16,35): error CS0246: The type or namespace name 'NotNullWhen' could not be found (are you missing a  
using directive or an assembly reference?) [C:\Users\mattj\Code\MyApp\MyApp.csproj]
    0 Warning(s)
    2 Error(s)

Time Elapsed 00:00:01.01

Working build output (without --no-incremental):

C:\Users\mattj\Code\MyApp>dotnet build                 
Microsoft (R) Build Engine version 17.2.0+41abc5629 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  All projects are up-to-date for restore.
  MyApp -> C:\Users\mattj\Code\MyApp\bin\Debug\net48\MyApp.exe
  MyApp -> C:\Users\mattj\Code\MyApp\bin\Debug\net6.0\MyApp.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:00.94

Further technical details

• Include the output of dotnet --info

C:\Users\mattj>dotnet --info
.NET SDK (reflecting any global.json):
 Version:   6.0.300
 Commit:    8473146e7d

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.22000
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\6.0.300\

Host (useful for support):
  Version: 6.0.5
  Commit:  70ae3df4a6

.NET SDKs installed:
  2.1.818 [C:\Program Files\dotnet\sdk]
  3.1.419 [C:\Program Files\dotnet\sdk]
  5.0.408 [C:\Program Files\dotnet\sdk]
  6.0.202 [C:\Program Files\dotnet\sdk]
  6.0.203 [C:\Program Files\dotnet\sdk]
  6.0.300 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.All 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.25 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.25 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.25 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

• The IDE (VS / VS Code/ VS4Mac) you’re running on, and its version N/A - occurs on command line

• Here are binlogs that may be useful: binlogs.zip

Thanks

[asherber]

On .pp files: https://docs.microsoft.com/en-us/nuget/create-packages/source-and-config-file-transformations#specifying-source-code-transformations

It may have been a workaround in Nullable, but in other libraries (like LibLog), it’s a legitimate way to include transformable source code files in a NuGet package.

[gtbuchanan]

The issue appears to be related to the use of .pp as the file extension to hide the file in Visual Studio. I believe this is fixed with https://github.com/manuelroemer/IsExternalInit/pull/14 and https://github.com/manuelroemer/Nullable/pull/26. I couldn’t find any official info about the .pp file extension so I’m not sure if it was just a hack nor why this would only be a problem with the Rebuild target and TargetFrameworks property.

@seesharper I see that LightInject.Source is also using this strategy so it might benefit from the same change as an alternative to waiting for this to be fixed here.