What changed in System.ValueTuple 4.4.0 -> 4.5.0?
Asked Answered
C

1

20

I consider updating my System.ValueTuple references from 4.4.0 to (current) 4.5.0.

To avoid regressions, I'd like to find out what changed between those two releases. The nuget page says:

Release Notes

https://go.microsoft.com/fwlink/?LinkID=799421

which links to the .NET Core github repository.

Is the "Release Notes" link broken or does the .NET Core github repository actually contain the changelog for System.ValueTuple? If the latter, where exactly is it? I tried searching for System.ValueTuple in the repository, which yields a few results but did not help me find the changes between version 4.4.0 and 4.5.0.

Cloutier answered 4/9, 2018 at 12:47 Comment(7)
You should probably ask about the differences between runtimes/SDKs. The System.* packages act as polyfills that redirect to the runtime's implementation if it's a better match and provide an implementation for earlier runtimes. They are also a rather big pain if there's a mismatch as they add a lot of transient dependencies and binding redirects that aren't always removed when the new version comes out. Just look at Nick Craver's tweets for the last year. You should probably target .NET 4.7.2 if you want to use .NET Standard 2.0 libraries, so you don't have to use the packages at all.Triglyceride
The 4.5.0 DLL for .NET 4.7 contains a [assembly: AssemblyInformationalVersion("4.6.26515.06 @BuiltBy: dlab-DDVSOWINAGE059 @Branch: release/2.1 @SrcCode: https://github.com/dotnet/corefx/tree/30ab651fcb4354552bd4891619a0bdd81e0ebdbf")] attribute (not the core repo but corefx), if that helps.Britisher
I had the same problems for the last year. Each time I moved from framework version to the next, eg 4.6.2 to 4.7.0 to 4.7.1 I had to fight a lot of leftover binding redirects to 4.4 packages. In the end the only reliable solution was to remove all those packages and redirects and add them back again. Immo Lanwerth recently acknowledged that the polyfills didn't work as intended to add Standard 2.0 compatibility to downrage runtimes. In the end, if you want Standard 2.0 you'll have to target the 4.7.2 runtime, or .NET Core 2.0Triglyceride
Nothing changed. It is notable how .netcore made semantic versioning utterly useless. If you download the 4.5.0 nuget package then you actually get version 4.0.3.0. The commit history on the reference assemblies hints that versioning is getting out of hand pretty badly.Addressee
@HansPassant I think your comment would be more helpful if you move it to the answer section. As I guess you are actually answering the question, and seems to be the only answer we might get.Bernini
There is no point in a "nothing changed" answer, only having to maintain it for the rest of my natural life to update such an answer when it does change. I have no idea why the OP keeps this question around.Addressee
@HansPassant: Because people consider it useful (according to the upvotes, which keep trickling in even now that everyone using the classical Framework should be on .NET 4.8). And I think the risk of the answer changing is minimal (if they ever change the System.ValueTuple nuget package, I'm pretty sure they would increase the version number as well).Cloutier
G
3

The sourcecode for System.ValueTuple can be found here.

According to the Nuget-History, Version 4.4.0 was released on 09.08.2017 and 4.5.0 was released on 29.05.2018.

So, according to the git history, this is the only commit that has been made within this timeframe (fixing a documentation typo):

  public T1 Item1;

  /// <summary>
- /// The current <see cref="ValueTuple{T1, T2}"/> instance's first component.
+ /// The current <see cref="ValueTuple{T1, T2}"/> instance's second component.
  /// </summary>
  public T2 Item2;
Grayling answered 23/3, 2021 at 14:13 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.