System.ValueTuple 4.6.1 dropped the reference assembly for net471+, causing unresolvable compile errors in some cases

[jnm2]

Scenario:

• Community library TaskTupleAwaiter references System.ValueTuple 4.3.1 and includes a net462 target. Therefore, the APIs in the TaskTupleAwaiter binaries reference System.ValueTuple, Version=4.0.1.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51.
• An application targeting net48 references TaskTupleAwaiter. All is well; the System.ValueTuple 4.5.0 package gives the C# compiler its net47 System.ValueTuple ref assembly.
• Then, the application wants to upgrade its System.Text.Json dependency from v9 to v10. System.Text.Json 10.0.0 depends on System.ValueTuple 4.6.1, forcing the application to use the latter.
• System.ValueTuple 4.6.1 now has an empty net471 folder, so no System.ValueTuple ref assembly is given to the C# compiler.
• The application fails to compile when any TaskTupleAwaiter API is used which references System.ValueTuple, with the following errors:

  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'.

.NET Framework 4.8 defines ValueTuple in mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, and it includes a shim library System.ValueTuple, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51.

I think no binding redirect is created for the System.ValueTuple assembly because there are no conflicts after a NuGet restore, because System.ValueTuple 4.6.1 stopped putting its additional System.ValueTuple assembly in the mix. But this also looks intentional:

maintenance-packages/src/System.ValueTuple/src/buildTransitive/net471/System.ValueTuple.targets

Lines 5 to 9 in 6938f07

	<Target Name="RemoveValueTupleRedirectForNet471AndAbove" DependsOnTargets="ResolveAssemblyReferences" BeforeTargets="GenerateBindingRedirects">
	<ItemGroup>
	<SuggestedBindingRedirects Remove="System.ValueTuple, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" />
	</ItemGroup>
	</Target>

I expect it is the job of the System.ValueTuple package to provide the correct type forwards and/or binding redirects, given that community binaries have references to System.ValueTuple, Version=4.0.1.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51 because they compiled against the System.ValueTuple 4.3.1 package.

The consuming app seems to have no way to resolve this issue. There is no way to target .NET Framework 4.7.1+, while using System.Text.Json 10.0.0+, while also using TaskTupleAwaiter.

[ericstj]

Can you try setting

<DependsOnSystemRuntime>true</DependsOnSystemRuntime>

The problem here is that MSBuild is not passing the inbox System.ValueTuple to compiler, the binding redirects are a red herring those don't apply for net471 or later. We don't want bindingRedirects at all here because starting with net471 ValueTuple should be loaded from the framework/GAC.

You can alternatively use

    <Reference Include="System.ValueTuple" />

Which will only pass System.ValueTuple to the compiler. Please let us know if this works.

We should add this to the package, but it probably won't meet the bar for a release - we can make that change and have it ship next time the package ships.

[jnm2]

<DependsOnSystemRuntime>true</DependsOnSystemRuntime> in Directory.Build.props didn't resolve the compile issue. RAR overwrites DependsOnSystemRuntime to false, so I would have to set up a custom MSBuild target in order to change it back to true. This worked:

  <Target Name="OverrideDependsOnSystemRuntime" AfterTargets="ResolveAssemblyReferences">
    <PropertyGroup>
      <DependsOnSystemRuntime>true</DependsOnSystemRuntime>
    </PropertyGroup>
  </Target>

With <Reference Include="System.ValueTuple" />, the build succeeds with this warning from RAR (shown as an error here due to MSBuildTreatWarningsAsErrors):

error MSB3277: Found conflicts between different versions of "System.ValueTuple" that could not be resolved.
error MSB3277: There was a conflict between "System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" and "System.ValueTuple, Version=4.0.5.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51".
error MSB3277:     "System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" was chosen because it was primary and "System.ValueTuple, Version=4.0.5.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" was not.
error MSB3277:     References which depend on "System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" [C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.8\Facades\System.ValueTuple.dll].
error MSB3277:         C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.8\Facades\System.ValueTuple.dll
error MSB3277:           Project file item includes which caused reference "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.8\Facades\System.ValueTuple.dll".
error MSB3277:             System.ValueTuple
error MSB3277:     References which depend on or have been unified to "System.ValueTuple, Version=4.0.5.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" [].
error MSB3277:         C:\Users\jmusser\.nuget\packages\microsoft.bcl.memory\10.0.0\lib\net462\Microsoft.Bcl.Memory.dll
error MSB3277:           Project file item includes which caused reference "C:\Users\jmusser\.nuget\packages\microsoft.bcl.memory\10.0.0\lib\net462\Microsoft.Bcl.Memory.dll".
error MSB3277:             C:\Users\jmusser\.nuget\packages\microsoft.bcl.memory\10.0.0\lib\net462\Microsoft.Bcl.Memory.dll
error MSB3277:         C:\Users\jmusser\.nuget\packages\tasktupleawaiter\2.1.1\lib\net462\TaskTupleAwaiter.dll
error MSB3277:           Project file item includes which caused reference "C:\Users\jmusser\.nuget\packages\tasktupleawaiter\2.1.1\lib\net462\TaskTupleAwaiter.dll".
error MSB3277:             C:\Users\jmusser\.nuget\packages\tasktupleawaiter\2.1.1\lib\net462\TaskTupleAwaiter.dll

[ericstj]

Can you try

    <Reference Include="System.ValueTuple" SpecificVersion="true" />

[jnm2]

That works without issues!

[ericstj]

Cool, I filed a bug to fix RAR. If we could turn back time maybe we should have bumped the minor version for every assembly when it was brought back into the .NETFramework targeting pack.

[ceisele-r]

We are facing the same or a similar issue with .net Framework 4.8.

When having the following workaround

  <ItemGroup Condition="$([MSBuild]::VersionGreaterThanOrEquals('$([MSBuild]::GetTargetFrameworkVersion('$(TargetFramework)'))','4.7.1')) And $([MSBuild]::VersionLessThan('$([MSBuild]::GetTargetFrameworkVersion('$(TargetFramework)'))','5.0'))">
    <Reference Include="System.ValueTuple" SpecificVersion="true" />
  </ItemGroup>

in the Directory.Build.props, we receive the following warning during build

3>------ Rebuild All started: Project: WebSeite, Configuration: Debug Any CPU ------
3>  Consider app.config remapping of assembly "System.ValueTuple, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" from Version "4.0.3.0" [] to Version "4.0.5.0" [] to solve conflict and get rid of warning.
3>C:\Program Files\Microsoft Visual Studio\18\Professional\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets(2437,5): warning MSB3247: Found conflicts between different versions of the same dependent assembly. In Visual Studio, double-click this warning (or select it and press Enter) to fix the conflicts; otherwise, add the following binding redirects to the "runtime" node in the application configuration file: <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"><dependentAssembly><assemblyIdentity name="System.ValueTuple" culture="neutral" publicKeyToken="cc7b13ffcd2ddd51" /><bindingRedirect oldVersion="0.0.0.0-4.0.5.0" newVersion="4.0.5.0" /></dependentAssembly></assemblyBinding>

However, when we then add that binding redirect

<dependentAssembly>
  <assemblyIdentity name="System.ValueTuple" publicKeyToken="CC7B13FFCD2DDD51" culture="neutral"/>
  <bindingRedirect oldVersion="0.0.0.0-4.0.5.0" newVersion="4.0.5.0"/>
</dependentAssembly>

...we receive the following exception during runtime in an Asp.net WebForms project

An exception of type 'System.IO.FileNotFoundException' occurred in mscorlib.dll but was not handled in user code
Die Datei oder Assembly "System.ValueTuple, Version=4.0.5.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.

This makes kind of sense, as in GAC, we could only find the System.ValueTuple in v4.0.0.0 (and not v4.0.5.0).

If we now change the binding redirect to

<dependentAssembly>
  <assemblyIdentity name="System.ValueTuple" publicKeyToken="CC7B13FFCD2DDD51" culture="neutral"/>
  <bindingRedirect oldVersion="0.0.0.0-4.0.5.0" newVersion="4.0.0.0"/>
</dependentAssembly>

(so that System.ValueTuple is used in version 4.0.0.0), it works and in the debugger, we can also see that the v4.0.0.0 version is loaded from the GAC.

My general understanding of the situation is the following:

• Starting with .net Framework 4.7.1, System.ValueTuple is shipped as part of .net Framework. That's also the reason why in the System.ValueTuple Nuget Package v4.6.1 removes a suggested binding redirect ( see https://nuget.info/packages/System.ValueTuple/4.6.1 -> build/net471/System.ValueTuple.targets )
  • This means that System.ValueTuple should be used from GAC for .net Framework >=4.7.1 (instead of being provided via the Nuget package/dependency)
• However, in our GAC, we can only find System.ValueTuple in v4.0.0.0 - and not 4.0.5.0 (or 4.0.3.0)
  • That's the reason we get the System.IO.FileNotFoundException for System.ValueTuple@4.0.5.0 when adding the suggested binding redirect.
  • That's also the reason it works when we add the binding redirect to System.ValueTuple@4.0.0.0 - as that's present in GAC.

Unfortunately, the above mentioned

<Reference Include="System.ValueTuple" SpecificVersion="true" />

does not work for us.

I guess in our case it might also play a role that we are introducing the System.ValueTuple as transient dependency of another Nuget package.

We are actually pretty confused about the potential solution, therefore I am wondering if

• my general understanding of the situation is correct?
• there is any bug (maybe this one or MSB3277 When referencing a framework assembly with newer build or servicing version msbuild#12780 ) which would fix this issue for us if fixed?
• it might be ok to "downgrade" the System.ValueTuple dependency to v4.0.0.0 for now using the above mentioned binding redirect (this feels bad, though), as we did not find any other solution that works

[Solvitt]

We have exactly the same issue as the previous user.

We upgraded MS Graph and MSAL which in turn removed the reference to System.ValueTuple (.Net 4.8) from the project and then requested that we change the redirect to:

	<dependentAssembly>
		<assemblyIdentity name="System.ValueTuple" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
		<bindingRedirect oldVersion="0.0.0.0-4.0.5.0" newVersion="4.0.5.0" />
	</dependentAssembly>

When we run the code obviously the dll is now missing and we get a cannot load message.

We have also downgraded the redirect as per the previous user to the standard 4.0.0.0 but we are concerned that this is not the right solution, Although all the office interfaces seem to be working correctly.