Repository navigation
Document why we upgrade/delete targetframeworks throughout repos #1763
Description
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.
Activity
tmds commentedon Oct 28, 2020
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 commentedon Oct 28, 2020
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
PackageReferencethat works with any framework. This is I think the big thing we run into with the dotnet/runtimesrc/librariesbuild, 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:
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.1or whatever, but from source-build they just getnet5.0, causing unexpected restore/build/publish results. But this is probably specific to this scenario.tmds commentedon Oct 29, 2020
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.
Such packages could be built on a second pass, after the runtime/sdk are built.
dagood commentedon Oct 20, 2021
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.