Remove private CoreFx and CoreClr transport packages

[ViktorHofer]

As we are switching away from package dependencies for CoreClr and CoreFx we should discuss remaining consumers of the private transport packages:

• https://github.com/dotnet/arcade/blob/d2d8d9f5c14e353acc7dfcf69c5fa5a8c368af40/src/Microsoft.DotNet.Build.Tasks.SharedFramework.Sdk/targets/framework.dependency.targets#L217-L218

I quickly talked with @dagood about this. The SharedFramework.Sdk requires crossgen from the CoreClr package and some OOB packages from the CoreFx one. We should probably package crossgen up and add it to BAR. For the OOB ones we already have a package which references all the OOB packages: Microsoft.Private.CoreFx.OOB which could probably be used instead.

cc @dotnet/runtime-infrastructure

[ViktorHofer]

Does someone know of other consumers of these two transport packages?

[dagood]

The SharedFramework.Sdk requires crossgen from the CoreClr package

The sharedfx SDK requires crossgen, but I think we could change that so the builder selects either:

• The NETCoreApp Runtime pack (to use in WindowsDesktop, ASP.NET Core, and Core-SDK)
• The live-built crossgen (to use in dotnet/runtime)

and some OOB packages from the CoreFx one

This is something downstream repos depend on, not the sharedfx SDK itself. WindowsDesktop depends on compat packages, ASP.NET Core brings in some more, some other downstreams like IoT may depend on others.

For the OOB ones we already have a package which references all the OOB packages: Microsoft.Private.CoreFx.OOB which could probably be used instead.

What does this help with? The packages still need to be published to a feed so the metapackage can reference them, right? The repo gains a dependency on a private/transport metapackage, and then needs to manually filter out which sub-packages it actually needs, rather than letting NuGet do it.

[safern]

For the OOB ones we already have a package which references all the OOB packages: Microsoft.Private.CoreFx.OOB which could probably be used instead.

I don't understand how we could use that package? We will still produce OOB packages. Actually this package was only for testing purposes, and I think it should go away once Mono is part of the consolidated repo.

[ViktorHofer]

That package is needed by the performance repo as well.

[safern]

That package is needed by the performance repo as well.

Ah, that's correct.