.NET 8: Tracking for TFM trimming, and elimination of net4* targeting in Linux source-build

[mmitche]

Description

Tracking for #2901. Requires #3013. source-build net4* targeting elimination required #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 #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 #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 #2974

Repositories

• TFM trimming, and elimination of net4* targeting in Linux source-build arcade#10721
• TFM trimming, and elimination of net4* targeting in Linux source-build aspnetcore#43696
• [cecil] TFM trimming, and elimination of net4* targeting in Linux source-build runtime#83991
• TFM trimming, and elimination of net4* targeting in Linux source-build command-line-api#1834
• TFM trimming, and elimination of net4* targeting in Linux source-build deployment-tools#217
• TFM trimming, and elimination of net4* targeting in Linux source-build diagnostics#3341
• [emsdk] TFM trimming, and elimination of net4* targeting in Linux source-build runtime#83278
• TFM trimming, and elimination of net4* targeting in Linux source-build format#1711
• TFM trimming, and elimination of net4* targeting in Linux source-build fsharp#13829
• TFM trimming, and elimination of net4* targeting in Linux source-build installer#14434
• TFM trimming, and elimination of net4* targeting in Linux source-build linker#3016
• TFM trimming, and elimination of net4* targeting in Linux source-build runtime#74950
• TFM trimming, and elimination of net4* targeting in Linux source-build msbuild#7936
• TFM trimming, and elimination of net4* targeting in Linux source-build NuGet/Home#12074
• TFM trimming, and elimination of net4* targeting in Linux source-build razor#7071
• TFM trimming, and elimination of net4* targeting in Linux source-build roslyn-analyzers#6144
• TFM trimming, and elimination of net4* targeting in Linux source-build roslyn#63746
• TFM trimming, and elimination of net4* targeting in Linux source-build sdk#27642
• TFM trimming, and elimination of net4* targeting in Linux source-build sourcelink#868
• TFM trimming, and elimination of net4* targeting in Linux source-build symreader#266
• TFM trimming, and elimination of net4* targeting in Linux source-build templating#5192
• TFM trimming, and elimination of net4* targeting in Linux source-build test-templates#248
• TFM trimming, and elimination of net4* targeting in Linux source-build microsoft/vstest#3989
• TFM trimming, and elimination of net4* targeting in Linux source-build xdt#464
• TFM trimming, and elimination of net4* targeting in Linux source-build xliff-tasks#663

[mmitche]

@MichaelSimons Here is the bones of the tracking issue I'm going to open in the repos, can you take a look?

@ericstj For non-source-build cases where we need to target netframework, and any netframework TFM will do, is there a preferred TFM? I'm mostly thinking of non-shipping packages or tooling, as this would be a breaking change otherwise.

[ericstj]

For non-source-build cases where we need to target netframework, and any netframework TFM will do, is there a preferred TFM

In dotnet/runtime we have a preference for libraries - the minimum last supported framework which we define as NetFrameworkMinimum. There is likely a different preference for things that are part of VS and that's whatever VS's pre-requisite framework is. I'm not certain what that is, but I do see the SDK targeting net472. cc @marcpopMSFT @ViktorHofer

[ViktorHofer]

In dotnet/runtime, all libraries target NetCoreAppCurrent and that refers to the .NETCoreApp version currently being developed. Packages target additional frameworks like net6.0, net7.0, net462, netstandard2.0 and netstandard2.1.

IMHO if feasible, for source build, we should only build NetCoreAppCurrent. In dotnet/runtime we already support building just a slice of the graph but as NuGet still restores all target frameworks we would need to rewrite the TargetFrameworks property to trim the other frameworks out.

[mmitche]

IMHO if feasible, for source build, we should only build NetCoreAppCurrent. In dotnet/runtime we already support building just a slice of the graph but as NuGet still restores all target frameworks we would need to rewrite the TargetFrameworks property to trim the other frameworks out.

What about internal tooling or non-shipping packages? Do we have any cases where we are building framework bits in runtime today?

It would be awesome to code up the TargetFrameworks properties in such a way that it's globally overridable on the runtime side. It is less ideal to have a ton of conditionals in every project.

[ViktorHofer]

What about internal tooling or non-shipping packages? Do we have any cases where we are building framework bits in runtime today?

Yes, we have msbuild tasks that target .NET Framework but those target .NETCoreApp as well. For source build I guess it's OK to not build the .NET Framework msbuild tasks.

It would be awesome to code up the TargetFrameworks properties in such a way that it's globally overridable on the runtime side. It is less ideal to have a ton of conditionals in every project.

Yes that should be possible via a clever regex pattern (because we not just target net7.0 but also net7.0-windows, net7.0-unix, etc.). A regex pattern applied on the $(TargetFrameworks) property in a targets file should be able to remove anything except $(NetCoreAppCurrent).

That said, the feasibility question regarding repositories only relying on $(NetCoreAppCurrent) assets still stands. We in dotnet/runtime are technically able to only produce $(NetCoreAppCurrent) assemblies and packages but if dependent repositories require other target frameworks like net6.0 or .NETStandard then this wouldn't work.

[mmitche]

Yes, we have msbuild tasks that target .NET Framework but those target .NETCoreApp as well. For source build I guess it's OK to not build the .NET Framework msbuild tasks.

Do you think that the framework tasks are still required at all?

That said, the feasibility question regarding repositories only relying on $(NetCoreAppCurrent) assets still stands. We in dotnet/runtime are technically able to only produce $(NetCoreAppCurrent) assemblies and packages but if dependent repositories require other target frameworks like net6.0 or .NETStandard then this wouldn't work.

I think we should keep netstandard where we actually want to release a package as netstandard. Downstream repos should not be targeting net6 (for various reasons) in source build. Those binaries going to be running on a net7 runtime, regardless of whether they want net6 or not.

[ViktorHofer]

I think we should keep netstandard where we actually want to release a package as netstandard.

How many of those packages do we have? As .NETStandard's public api surface is limited I noticed that many/most packages that offer a .NETStandard asset, multi-target to benefit from newer .NETCoreApp features. I would be surprised if we have many packages that are .NETStandard only. It might make sense for the stack to always target the very latest. (That's what we do in runtime).

Do you think that the framework tasks are still required at all?

They should not be required. Also FWIW msbuild was considering making it possible to load .NETCoreApp tasks in the .NET Framework version of msbuild and inside VS so that we can remove the .NETFramework task variants.

[mmitche]

How many of those packages do we have? As .NETStandard's public api surface is limited I noticed that many/most packages that offer a .NETStandard asset, multi-target to benefit from newer .NETCoreApp features. I would be surprised if we have many packages that are .NETStandard only. It might make sense for the stack to always target the very latest. (That's what we do in runtime).

Roger that. At least we need a way to evaluate what we are producing and then we can make decisions.

[MichaelSimons]

@NikolaMilosavljevic - What work remains here? Can this be closed?