Runtime: Freeze netstandard refs that have a package and are inbox

[ViktorHofer]

We don't want to accidently ship new APIs in a netstandard ref in a package that is already inbox on any platform. We should harvest those configurations and if they are referenced by other contracts we should also binplace them into the ref folder by adding a PackageReference here: https://github.com/dotnet/corefx/blob/master/external/netstandard/netstandard.depproj#L15.

When doing this we should also consider harvesting the impl but this needs to be considered project-wise. Freezing could also be interpreted as removing if there are no live assets going into the package.

cc @weshaggard @ericstj

[ericstj]

Was chatting with @ViktorHofer about this. We should try to formalize and centralize how we do package harvesting.

Today https://github.com/dotnet/corefx/blob/master/external/harvestPackages/harvestPackages.depproj downloads any packages that may be harvested.

Then the individual pkgprojs decide what will be harvested.

Then when someone decides they need the harvested asset when building (or testing) some other live build of a library we'll (usually myself) sprinkle PackageReferences in the various external depprojs most closely responsible for harvesting similar assets.

Nothing really keeps us honest when we do the latter and it could result in cases where parts of the build see harvested assets and later parts see a live build.

It feels like we can probably avoid some of this duplication and validate that we don't clash on binplacing.

[weshaggard]

https://github.com/dotnet/corefx/pull/32148 contributes to this effort.

[safern]

https://github.com/dotnet/corefx/pull/32096 contributes as well.

[ericstj]

This is related to the harvesting changes you're making (including for source build). It would be good if we had an APICompat step that ensured the live built asset matched the harvested asset.

[ViktorHofer]

An APICompat step is nice to have, not necessarily important for now. When a dev harvests new configurations, he/she should make sure that the new live built package doesn't accidently drop configurations. For now I'm fine with a manual verification.

The todo is here to scan through all OOB projects, find those which ship netstandard refs but are inbox in any configuration, and freeze them.

[ericstj]

I scanned through all packages which are currently inbox for netcoreapp. The following are candidates for freezing:

• Microsoft.CSharp - currently frozen version but still building the ref. It's identical to last release, we can clean this up in vNext
• System.ComponentModel.Annotations - problem here. API added this release to netstandard ref and package is still claiming to be inbox in netcoreapp2.0. Recommend we treat this as OOB and allow the new API to apply to netcoreapp2.0 as well.
• System.Reflection.Emit.* - We had to bring these back this release. Next release we'll delete the packages entirely (since they're being absorbed into ns2.1).
• System.Reflection.TypeExtensions - currently frozen version but still building the ref. It's identical to last release, we can clean this up in vNext

Leaving this issue to track clean-up in v.next. Will file product issues against the problems mentioned above.

[ericstj]

I'll use https://github.com/dotnet/corefx/issues/38849 to track the fixes to System.ComponentModel.Annotations. This issue can track the clean-up for vNext.