Runtime: Update master branch NETStandard.Library.Ref to produce 2.2 (for 5.0)

[dagood]

@nguerrera pointed out in https://github.com/dotnet/core-sdk/pull/3741#discussion_r310339695 that core-setup master still produces 2.1 NETStandard.Library.Ref. dotnet/standard now produces 2.2 from its master branch (https://github.com/dotnet/standard/pull/1344), which core-setup should probably match.

A consideration is that we should move this package to dotnet/standard, https://github.com/dotnet/standard/issues/1209, but we don't have the prereqs to do so right now. It might be useful to just do this small amount of work to get it flowing.

/cc @wtgodbe

[wtgodbe]

CC @JunTaoLuo @dougbu. @dagood, this is blocking Asp.Net repos since they're consuming 2.1.0-alpha versions of this package from master, which the SDK automatically rolls forward to the latest on nuget (preview7), which doesn't contain some new API that they rely on.

[JunTaoLuo]

Would appreciate an eta when available since our master branches are blocked currently.

[dagood]

Is changing the package version enough, or do you know if there's an assumption somewhere that the major.minor of the package is the same as the major.minor of the TFM? https://github.com/dotnet/core-setup/pull/7646 is just the package version. If needed, Core-Setup can move stuff into the right place without much effort, but don't want to do that unless needed.

If infra problems clear up, no reason this can't go in today.

[nguerrera]

Why are your branches blocked? I saw something about NuGet picking a different older version somewhere but that sounds like the issue with packages disappearing if that’s what the blocker is. If the alpha package is found it should work.

[nguerrera]

Please don’t bump the version to 2.2 with 2.1 tfm

[nguerrera]

they're consuming 2.1.0-alpha versions of this package from master, which the SDK automatically rolls forward to the latest on nuget (preview7), which doesn't contain some new API that they rely on.

The SDK does no such roll forward of targeting pack versions. NuGet rolls forward package versions if the exact version is not found in some cases, and warns.

I saw something about packages going missing, are we sure that's not what is happening. Can you share a pointer to a failing build or binlog?

[dagood]

Filed https://github.com/dotnet/standard/issues/1421 to get to 2.2 with consistency.

The missing package issues are tracked at https://github.com/dotnet/arcade/issues/3620.

[wtgodbe]

@JunTaoLuo can you share a link to one of the failed builds?

[JunTaoLuo]

My bad, it wasn't a roll forward that cause the issue for us. We did an oopsie when porting over @nguerrera's fix for targeting netcoreapp5.0 and accidentally removed the mechanism to specify an exact version of the targeting pack to use and ended up falling back to the bundled targeting pack in the SDK. False alarm, we're not blocked on this.

[dagood]

Closing: there's no plan to declare netstandard2.2 (https://github.com/dotnet/standard/issues/1421) and without that, we can't do this. It also shouldn't be blocking anyone.

[nguerrera]

I don't agree with this. You have to pick a version for your branch that is ahead of 2.1.

[dagood]

Do you have any suggestion about what to do, with the constraint of not bumping the version to 2.2 with the netstandard2.1 tfm?

[nguerrera]

I think they should bump the TFM. They are producing bits in a branch that is logically after the final 2.1 surface area, that needs a new TFM. Maybe they don't want the next one to be 2.2, but they should assign one and 2.2 is the lowest possible. Later they can bump to 3.0 or whatever.