Compile error when TaskTupleAwaiter is used with System.ValueTuple 4.6.1 on .NET Framework

[jnm2]

System.Text.Json 10.0.0 depends on System.ValueTuple 4.6.1. If you're on .NET Framework and you want to use System.Text.Json 10.0.0 and you use TaskTupleAwaiter, you will hit a slew of compile errors per await:

error CS0012: The type 'ValueTuple<>' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.ValueTuple, Version=4.0.1.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'.
error CS0012: The type '(, )' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.ValueTuple, Version=4.0.1.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'.
error CS0012: The type '(, , )' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.ValueTuple, Version=4.0.1.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'.
error CS0012: The type '(, , , )' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.ValueTuple, Version=4.0.1.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'.
error CS0012: The type '(, , , , )' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.ValueTuple, Version=4.0.1.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'.
error CS0012: The type '(, , , , , )' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.ValueTuple, Version=4.0.1.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'.
error CS0012: The type '(, , , , , , )' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.ValueTuple, Version=4.0.1.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'.
error CS0012: The type 'ValueTuple<,,,,,,,>' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.ValueTuple, Version=4.0.1.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'.

This only affects TaskTupleAwaiter v1.1.0+. v1.0.0 and v1.0.1 do not have this problem.
This also only affects the latest System.ValueTuple (4.6.1). The previous System.ValueTuple (4.5.0) does not have this problem.

Repro

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

  <PropertyGroup>
    <TargetFramework>net48</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="System.ValueTuple" Version="4.6.1" />
    <PackageReference Include="TaskTupleAwaiter" Version="2.1.1" />
  </ItemGroup>

</Project>

using System.Threading.Tasks;

class C
{
    async Task M()
    {
        await (Task.FromResult(1), Task.FromResult(2));
    }
}

[jnm2]

In working scenario 1 (System.ValueTuple 4.6.1, TaskTupleAwaiter 1.0.1), the Csc MSBuild task references include a netstandard2.0 build of TaskTupleAwaiter.dll and the netstandard.dll facade.

In working scenario 2 (System.ValueTuple 4.5.0, TaskTupleAwaiter 1.0.1), the Csc MSBuild task references include a net462 build of TaskTupleAwaiter.dll and the net47 ref assembly for System.ValueTuple.dll.

In the broken scenario (System.ValueTuple 4.6.1, TaskTupleAwaiter 2.1.1), the Csc MSBuild task references include a net462 build of TaskTupleAwaiter.dll and do not include any System.ValueTuple.dll.

[jnm2]

Unlike 4.3.1 and 4.5.0, System.ValueTuple 4.6.1 includes an empty net471 folder which is why no reference assembly is added. This may be a legitimate package authoring bug in System.ValueTuple 4.6.1. (Not the first time this type of issue has raised its head with either this type or System.ValueTask.)

Despite this likely being a System.ValueTuple bug, there are options on the TaskTupleAwaiter side:

• Use a netstandard2.0 build instead of a net462 build. (Why not, anyway?)
• Add a net471 framework target to TaskTupleAwaiter.
• Possibly, update the System.ValueTuple dependency from 4.3.1 to 4.6.1.

[jnm2]

I reported the System.ValueTuple defect at dotnet/maintenance-packages#243.

[buvinghausen]

@jnm2 nothing to do on your end but I had some spare time yesterday and so I went ahead and ported the library over to using MTP2 to modernize the testing stack and plugged in Shouldly for assertions. The only other change was I put a Directory.Build.props file in the parent folder and have both the test & src props files inherit from it so now we have one place to go to maintain the supported TFM array.

[jnm2]

@buvinghausen The Shoudly commit 9e8c520 changes the NuGet package from targeting net8.0 and netstandard2.0 to having two additional targets, net9.0 and net10.0. This bloats the package size without providing value in my opinion. Due to how targeting works, any package that supports net8 automatically supports net9 and net10; the only reason to be shipping separate DLLs for net9 and net10 is if the DLLs are different in some meaningful way.

Targeting only netstandard2.0 and net8.0 telegraphs "this package supports all frameworks which are compatible with netstandard2.0, and it is specialized to use a feature that was added starting in .NET 8." (The latter being ConfigureAwaitOptions)

[jnm2]

Also, now that a fixed version https://www.nuget.org/packages/System.ValueTuple/4.6.2 is published, I'd like to remove our workaround by updating to that version and reinstating the net462 package target. The special support that our package thus provides for net462 is that an app on .NET Framework no longer has to ship all the shim assemblies for .NET Standard (at least not simply due to to the use of this library).

I was reminded of this at dotnet/maintenance-packages#243 (comment):

We don't recommend dropping .NETFramework altogether as this results in requiring applications to ship the entire OOB .NETStandard support (100+ assemblies) on .NET 4.6.1 - .NET 4.7. We'd never do this from the packages involved here.

[buvinghausen]

@jnm2 you are the maestro I will let you make those calls... I was just trying to consolidate and probably got overzealous I didn't release anything so feel free to tell me when you want to push the update out.