Document why we upgrade/delete targetframeworks throughout repos

[dagood]

As a repo owner, I'd expect this to be fine for source-build:

<TargetFrameworks>net461;netcoreapp2.0</TargetFrameworks>

net461 should be built using a .NET Framework targeting pack, and netcoreapp2.0 using I think Microsoft.NETCore.App/2.0.9 as a targeting pack. The result can then run on any later runtimes.

But, source-build tends to have patches that remove net461 and upgrade netcoreapp2.0 to a later version. These targetframework upgrades are somewhat viral: downstream repos have to react, and we do this with more source-build patches. In some cases, we even have source code patches to handle the API differences in new targetframeworks.

I think we need well-documented justification for this, since we're asking repo owners to take our patches for arcade-powered source-build. Or better, we should remove these changes.

/cc @dseefeld @crummel @dleeapho

---

This also figures into Establish a policy for tooling repos with arcade-powered source-build: how does one build work for 5.0 and 6.0? #1743. The 6.0 SDK may need to build the 5.0 repos, which it should be able to do. If we require SDK-version-specific patching (upgrading net5.0 to net6.0), we need to account for how to do that in a plan.

[tmds]

My 2 cents... may be too simplistic.

As a source-build user, I expect to build a .NET runtime, and SDK that works on that runtime.
Being able to set that runtime as a target framework, is a good way to build only necessary bits and eliminate prebuilts.

For cases like OmniSharp-vscode, I hope we may be getting to a place where mono can use the net5.0+ assemblies instead of requiring separate net4* targets.

cc @omajid

[dagood]

Yeah, I agree it seems good as far as building the SDK and Runtime. I don't know any reason any of the DLLs in either one of those must be compatible with a lower framework version than the current Runtime version. (Other than for OmniSharp (#1650).)

The practical problem that comes up is that repo owners generally want to target the lowest possible targetframework, for the broadest reach. They want to build with a 5.0 SDK because they want to add optimizations and APIs that only work with the 5.0 Runtime, but also produce libraries that people can run on a 3.1 or even 2.1 runtime. Then all the DLLs go into the same nupkg so people can add just one PackageReference that works with any framework. This is I think the big thing we run into with the dotnet/runtime src/libraries build, and I believe also tooling like NuGet, Roslyn, etc.

But that's not preventing us from changing it. To remove prebuilts, we add patches to manipulate the target framework, but then:

In some cases, we even have source code patches to handle the API differences in new targetframeworks.

It's then a practical matter of who owns the patches and maintenance work associated with forcing a project that normally targeting old frameworks (net472;netcoreapp2.1, netstandard2.1) to the current framework (net5.0) for source-build.

Maybe arcade-powered source-build flips the world enough to make this actually very reasonable? Repo owners can fix problems with the ultra-multi-targeting themselves when it breaks via PR validation, or if they can't figure that out, at least contact us to get it fixed it in a timely fashion rather than us finding out via prebuilts 6 months after the fact.

(We can remove the patches and instead have the projects use a source-build MSBuild property to pick the target framework. This is good, but still requires ongoing maintenance, so I don't think it's much different at a high level.)

---

A problem we might get into later on is if we actually want to include source-built nupkgs that we expect end-users to use instead of ones on the nuget.org gallery. From nuget.org they would get net472;netcoreapp3.1;netstandard2.1 or whatever, but from source-build they just get net5.0, causing unexpected restore/build/publish results. But this is probably specific to this scenario.

[tmds]

Maybe arcade-powered source-build flips the world enough to make this actually very reasonable?

I think it is reasonable to request the projects to be able to compile against the latest .NET version. The maintenance cost should not be high.

A problem we might get into later on is if we actually want to include source-built nupkgs that we expect end-users to use instead of ones on the nuget.org gallery. From nuget.org they would get net472;netcoreapp3.1;netstandard2.1 or whatever, but from source-build they just get net5.0, causing unexpected restore/build/publish results. But this is probably specific to this scenario.

Such packages could be built on a second pass, after the runtime/sdk are built.

[dagood]

In 6.0, the standard plan is no longer to upgrade TFMs. We're working more in depth with repo maintainers to apply workarounds that let source-build build the same TFMs that the Microsoft build does.