Make use of Arcade's NetCurrent property

[mthalman]

There is a lot of usage of hardcoded TFM values throughout the repo. This causes issues when migrating to newer major versions of .NET. For example, now that .NET 9 development is in process, the source in the fsharp repo really needs to be targeting net9.0 in order to work with source build. Today, this is done in a patch. But patches are not very sustainable because any changes in this repo surrounding the edits in the patch cause conflicts, which have happened multiple times so far for fsharp in the .NET 9 timeframe.

To avoid patches, or at least to help reduce the amount of edits in a patch, this repo can be updated to make use of Arcade's NetCurrent property. This allows the TFM to be dynamically updated via Arcade over time and avoids constant source changes for each release. Often times there is pushback from repos not wanting to be on the latest TFM (which is currently net9.0) because it may be a hinderance on the dev experience. In that case, following the pattern that Roslyn has done is a good option. They hardcode the desired TFM they want to use for normal dev scenarios, but when running in the context of source build, they use NetCurrent.

[vzarytovskii]

@mthalman

How's it going to work when we make it conditional (based on source build), and then insert into 8.0.3xx for example?

Right now we have release branch (17.10) inserting in sdk main, and 8.0.3xx.

Our code flows main -> release branches. We usually have one at the time active release branch.

[mthalman]

NetCurrent would be net8.0 for 8.0.3xx and it would be net9.0 for main, which is exactly what we'd want.

[vzarytovskii]

NetCurrent would be net8.0 for 8.0.3xx and it would be net9.0 for main, which is exactly what we'd want.

How is it controlled? Arcade only flows to main for us, since we only work with main at any given time, unless we backport something to the release branch.

Our flow is PR -> main -> current release branch.

[mthalman]

When source build runs in the VMR, there's only one version of Arcade that is used by everything. So it doesn't matter what version of Arcade that the fsharp repo is using because in the context of the VMR, it will be using the version of Arcade that exists in the VMR. So in an 8.0 branch, Arcade's NetCurrent will be net8.0 and in a 9.0 branch, Arcade's NetCurrent will be net9.0. The key is that the fsharp repo needs to be using this property in some way in order for us to have a central point of control.

And even if NetCurrent wasn't used we would still benefit from the fsharp repo defining a build property that is consumed instead of hardcoded TFM values because it would at least consolidate things to one need to apply a patch to a single file. But the goal is to not have to patch anything, so the recommendation is still to use Arcade's NetCurrent.

[vzarytovskii]

When source build runs in the VMR, there's only one version of Arcade that is used by everything. So it doesn't matter what version of Arcade that the fsharp repo is using because in the context of the VMR, it will be using the version of Arcade that exists in the VMR. So in an 8.0 branch, Arcade's NetCurrent will be net8.0 and in a 9.0 branch, Arcade's NetCurrent will be net9.0. The key is that the fsharp repo needs to be using this property in some way in order for us to have a central point of control.

And even if NetCurrent wasn't used we would still benefit from the fsharp repo defining a build property that is consumed instead of hardcoded TFM values because it would at least consolidate things to one need to apply a patch to a single file. But the goal is to not have to patch anything, so the recommendation is still to use Arcade's NetCurrent.

A-ha, I see, thanks for explaining that. We will probably adopt Roslyn's approach for now. I will try to get to it this week.

Need to also propagate it to tests somehow though. Some of them rely on TFM being in the path.