[emsdk] TFM trimming, and elimination of net4* targeting in Linux source-build

[NikolaMilosavljevic]

Description

Trim away unneeded TFMs, and conditionalize away non-applicable TFMs for Linux source build.

Requires dotnet/source-build#3013. source-build net4* targeting elimination required dotnet/source-build#2974

The purpose of this operation is twofold:

• Reduce the number of TFMs present overall in .NET's build, potentially improving build time.
• Eliminate framework TFMs, drastically reducing the size of the source build repository size.

When TFMs other than the latest .NET Core TFM are targeted in source-build, the reference assets for that TFM must be provided via a source build reference package. This is a 'text only' package that is assembled from IL at the beginning of the build to satisfy the required reference assets. In Microsoft's build, these would be restored from the internet, but in source build this is not allowed.

These SBRPs are large. All told, the total size contribution for just the netframework 4* TFMs is around 3GB. Not only does this have a significant contribution to the source build repo size, but it also affects build time. For Linux source build, we spend large amounts of time building assets that are simply thrown away at the end.

An 'ideal' would be a single TFM used throughout all of the .NET build, source build or otherwise. This is not possible. There are legitimate reasons to target older TFMs, especially netstandard. However, we should be able to justify each additional TFM.

To complete this work, repositories will use the tooling provided via dotnet/source-build#2901 to identify the TFMs in use in their repository. For each TFM, they should do the following:

• If the TFM can be eliminated, or upgraded to latest (e.g. target the latest netcore explicitly, or use net472), do so. netframework TFM removal for tools and internal code is likely low hanging fruit.
• Requires Design for unified behavior controls source-build#2974 If the TFM is a framework TFM, it should be conditionalized out in source build for Linux.

It is a goal that the form of this conditionalization remain consistent across projects, and used relatively sparingly. How this conditionalization should be done will be designed in dotnet/source-build#2974. Once that is done, this issue will be updated with implementation details.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[MichaelSimons]

@NikolaMilosavljevic - Issues like this (repo specific) should be logged in the product repos instead of source-build. It is also more consistent with the other issues in dotnet/source-build#3014.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[NikolaMilosavljevic]

@NikolaMilosavljevic - Issues like this (repo specific) should be logged in the product repos instead of source-build. It is also more consistent with the other issues in dotnet/source-build#3014.

Yes, that is the plan, but dotnet/emsdk does not allow issues, so I created it in dotnet/source-build until I verified the correct repo (dotnet/runtime) and moved it there. Issue was needed as a reference in emsdk PR.