I'm very concerned about external packages being part of SBRP. We don't control them and hence can't upgrade TFMs and their underlying targeting packs easily. Allowing externals here would limit SBRP substantially. In addition to that, re-hosting external source code sounds concerning from a legal stand-point as well (even though the repository has an MIT license).

There are existing SBRP's that depend on Humanizer.Core,2.2.0

Do you know which libraries depend on the old Humanizer.Core 2.2.0 version? I assume those aren't SBRP ones but libraries in the stack?

Do you know which libraries depend on the old Humanizer.Core 2.2.0 version? I assume those aren't SBRP ones but libraries in the stack?

The references are coming from SBRP packages:
/repos/dotnet/src/source-build-reference-packages/artifacts/source-build/self/src/artifacts/obj/Microsoft.CodeAnalysis.CSharp.Workspaces.4.0.1/project.assets.json
/repos/dotnet/src/source-build-reference-packages/artifacts/source-build/self/src/artifacts/obj/Microsoft.CodeAnalysis.Workspaces.Common.4.0.1/project.assets.json

Our options to remove these are:

1. Upgrade the product references to eliminate these dependencies It looks like the only two come from runtime -
   • /repos/dotnet/src/source-build-reference-packages/artifacts/source-build/self/src/artifacts/obj/Microsoft.CodeAnalysis.CSharp.Workspaces.4.0.1/project.assets.json
   • /repos/dotnet/src/source-build-reference-packages/artifacts/source-build/self/src/artifacts/obj/Microsoft.CodeAnalysis.Workspaces.Common.4.0.1/project.assets.json
2. Upgrade the SBRP reference to the Humanizer version we carry in source-build - 2.14.0
3. Build multiple versions of Humanizer in source-build - Add 2.2.0 to source-build-externals

In addition to that, re-hosting external source code sounds concerning from a legal stand-point as well (even though the repository has an MIT license).

Not justifying it just calling it out, we do this in various text-only packages as well.