[Umbrella] ValueTuple library work

[jcouv]

Documentation of the various slices in the ValueTuple package:

Targeting pack	Contents
netcoreapp1.1	Ref and lib assemblies type-forwards to System.Runtime ref assembly, which type-forwards to System.Private.Corelib (from CoreCLR or CoreRT).
netstandard1.0 and up	Assembly implements ValueTuple and depends on System.Runtime
netstandard2.0 and up	Relies on netstandard package (requires binding redirect)
PCL	Assembly implements ValueTuple, but depends on mscorlib. Note that the precedence rules on targets means that PCL is picked when targeting desktop 4.5.
desktop 4.7	type-forwards ValueTuple to mscorlib

---

Known issues

ValueTuple nupkg and net47

Most prominent issue is when targeting desktop 4.6 (or lower) and referencing the ValueTuple package, then running on machine with desktop 4.7 installed.
The symptom are that tuples don't work in EE, interactive and possibly ASP.NET.
Workaround options: (1) target 4.7, or (2) remove ValueTuple dependency, or (3) run without 4.7 installed.
See https://github.com/dotnet/corefx/issues/16195 for more details.

ValueTuple in netstandard and net47

ValueTuple in netstandard and net471

Applications targeting .NET 4.6.1 that use .NET Standard libraries might be broken when running on .NET 4.7.1

https://github.com/Microsoft/dotnet-framework-early-access/issues/9

---

Reported issues

• Multiple library redirect warnings with .NET 4.7.1 and new SDK project format project-system#2905
• Issue with ValueTuple on net471 standard#543
• https://developercommunity.visualstudio.com/content/problem/130199/155-preview-cannot-build-c-projects-using-systemva.html
• https://devdiv.visualstudio.com/DefaultCollection/DevDiv/_workitems/edit/555358
• https://github.com/dotnet/corefx/issues/31987

---

Work items

Adding System.ValueTuple to various corlib implementations:

• corefx (to first ship as nuget package version 4.3.0) (PR)
• mscorlib/desktop (to first ship with upcoming desktop framework) (changeset, bug)
• corlib/coreCLR (Adding ValueTuple and ITuple to corlib in CoreCLR coreclr#8695)
• corlib/coreRT (Adding ValueTuple and ITuple to corlib in CoreRT corert#2399)
• mscorlib/xamarin (to first ship with Xamarin Cycle10)

Add ITuple to System.Tuple and System.ValueTuple to those corlibs:

• mscorlib/desktop (to first ship in the first version after 4.7)
• corlib/coreCLR (to first ship in version 1.2 of the package)
• corlib/coreRT
• mscorlib/xamarin (done in mono/mono@ddb72c4)

After that:

• Update coreFX with type forwarders to coreCLR (done in Type forwarding for ValueTuple to CoreCLR corefx#14786)
• add tests in coreFX for the ITuple implementation in coreCLR (done in Type forwarding for ValueTuple to CoreCLR corefx#14786)
• Fix coreFX lib assembly typeforewarders in target group = "netcoreapp1.1" to point to System.Runtime instead of System.Private.CoreLib (https://github.com/dotnet/corefx/issues/15475, done with dotnet/corefx@17fdb43)
• Update coreFX with type forwarders to coreRT (https://github.com/dotnet/corefx/issues/15176) (this was done implicitly as the result of the type-forward for netcoreapp1.1 and a subsequent cleanup by Eric)
• Update coreFX with type forwarders to desktop 4.7 (issue https://github.com/dotnet/corefx/issues/15175, PR Adding type-forwards for ValueTuple to desktop 4.7 corefx#18519)
• Add ValueTuple in .Net Standard
• Add ValueTuple to .Net Standard meta-package in the meanwhile (Add reference to ValueTuple package to NetStandard2.0 meta-package standard#22, PR: Add ValueTuple to .NET Standard 2.0 standard#279)
• Add support for Xamarin in ValueTuple package (https://github.com/dotnet/corefx/issues/14235, [release/1.1.0] Inbox value tuple corefx#16447) (should ship as patch right after 1.1.0)
• Add ValueTuple to .Net Core 2.0 shared framework (issue https://github.com/dotnet/corefx/issues/17797)

Make System.ValueTuple binary serializable (https://github.com/dotnet/corefx/issues/15229) (which will ship together with ITuple above):

• mscorlib/desktop with tests (work item, changeset)
• corlib/coreCLR (Make ValueTuple types serializable coreclr#9271)
• in coreFX, update ref assembly (add serializable attribute) and add tests to cover coreCLR implementation
• corlib/coreRT (Make ValueTuple types serializable (#9271) corert#2644)
• mscorlib/xamarin (I think nothing to be done)
• Add compiler end-to-end tests (with tuple syntax)

Hash seed randomization:

• desktop (could be considered)
• coreFX (done with Guid)
• coreCLR (done with Random)
• coreRT (done with Random)

EqualityComparer optimization:

• desktop (N/A, the underlying runtime does not have the optimization)
• coreFX (N/A, cannot be done because that ValueTuple code can run on existing runtimes that don't have the underlying optimization)
• coreCLR (done)
• coreRT (Remove usage of EqualityComparer.GetHashCode in ValueTuple corert#3021)

Various BCL improvements:

• Zip and Unzip LINQ APIs (https://github.com/dotnet/corefx/issues/16011)
• GetAwaiter for tuples of Tasks (Tuple and extension methods #16159 (comment), https://github.com/dotnet/corefx/issues/16010)
• Deconstruct on KeyValuePair and DictionaryEntry (Supporting C# 7 deconstruction of KeyValuePair and DictionaryEntry coreclr#8560, VSO)

Downgrade warnings issue:
- [ ] Change dependencies of ValueTuple package to reference 1.0.0 baseline (issue, fix) (closed "by design", customer should upgrade their 1.0 projects to 1.1 to use ValueTuple).

EE bug with not loading mscorlib

• Fix in 15.3 and ported to 15.2 (Report use-site diagnostics if System.ValueTuple base type is an error type #18552)

Clash between ValueTuple.dll and mscorlib.dll from new desktop framework (in short, a workaround was added to EE and a facade assembly was added to mscorlib in desktop 4.7.1 that type unifies with ValueTuple assembly version 4.1.*):

• EE issue (https://github.com/dotnet/corefx/issues/16195, VSO)
• Scripting issue (C# Interactive doesn't work with tuple syntax when desktop framework 4.7 is installed #17157)
• Compiler workaround (EE should ignore ValueTuple from mscorlib type when duplicate found in app #17192)
• Desktop 4.7.1 fix (GAC and type unification) (Sep ETA)
• Consider removing the EE workaround

Binding redirects required for EF tests (julielerman/EFCore2NightlyNet461#1, ErikEJ/EntityFramework.SqlServerCompact#463)

But auto-generated binding redirects break type unification (https://github.com/Microsoft/dotnet-framework-early-access/issues/9)

Various bugs/proposals:

• Issue with partial trust (https://github.com/dotnet/coreclr/issues/10123)
• Verify package still works after netstandard change (https://github.com/dotnet/corefx/issues/17960)
• Proposal to optimize comparison logic (https://github.com/dotnet/corefx/issues/18666)
• LINQPad issue with 4.7.1 (https://devdiv.visualstudio.com/DevDiv/_workitems?id=479290)

Change behavior when comparing with null (https://github.com/dotnet/corefx/issues/18528) (we ended up cancelling to keep Tuple and ValueTuple APIs more stable)

• In Core 2.0 (PR Null comparer consistency coreclr#11345)
• In desktop (version after 4.7.1, to give more bake time and not require quirking)
• ValueTuple package (it will be left as-is)
• Mono?

[jcouv]

Added ValueTuple code and test code for mscorlib/desktop (changeset, bug)
Still need to enable maddog

[jcouv]

Marek added code and test for mscorlib/xamarin (mono/mono@0a515cf)

It will be part of Xamarin Cycle10 release which is expected to be in line with VS Jan/Feb release.

[jcouv]

Added ITuple to mscorlib/desktop (workitem, changeset before temporary rollback, final changeset)

[jamesqo]

When porting the change to coreclr/corert, consider cherry-picking the changes from dotnet/corefx#14187 which should substantially speed up GetHashCode.

edit: Also, dotnet/corefx#14141 may need to be ported to the version of ValueTuple already present in desktop.

[jcouv]

@jamesqo Makes sense. When I port ValueTuple to coreclr/corert, I will use the latest code from corefx at that time (so it will include the hashcode changes).

[jcouv]

Added ValueTuple and ITuple to corlib in CoreCLR (dotnet/coreclr#8695) and CoreRT (dotnet/corert#2399).

[jcouv]

Removed ITuple constraint from TRest
Desktop: workitem, changeset
CoreCLR: dotnet/coreclr#8793
CoreRT: dotnet/corert#2434

[jcouv]

Added type forwards from CoreFx (System.ValueTuple and System.Runtime) to CoreCLR's implmentation in System.Private.CoreLib (dotnet/corefx#14786)

[jcouv]

Mono now re-uses the code from CoreRT, which means it has ITuple too (mono/mono@ddb72c4)

[jcouv]

The remaining bullets from the list above will now be tracked by individual issues. None of them is essential at this point. I'll close this umbrella.

[jcouv]

An issue was reported with 15.5, possibly related to ASP.Net, but not yet diagnosed.

[Tornhoof]

Same issue happens on 15.4 after installing .NET 4.7.1 DevPack and changing the framework version to .NET 4.7.1.
I had to add the ValueTuple Nuget package (4.4) to the projects otherwise it wouldn't compile.
Error is: Error CS8137 Cannot define a class or member that utilizes tuples because the compiler required type 'System.Runtime.CompilerServices.TupleElementNamesAttribute' cannot be found. Are you missing a reference?

[jcouv]

@Tornhoof I think you're describing a problem that has been identified and acknowledged with 4.7.1.. Can you try and see if the mitigation described in this thread (manually editing auto-generated binding redirects) works for the issue you're describing?

[Tornhoof]

Yes, manually removing the value tuple redirect fixes it. Unfortunately manually removing something from the auto-generated redirects in the new SDK Project system is a bit of work, for now I prefer my NuGet workaround as it fixes the bindings automatically.