Fsharp has 7.0 references in the tooling going into 8.0.100

[marcpopMSFT]

See dotnet/sdk#34245

There are some packages being pulled in that target 7.0 and unless you have scenarios where fsharp is loaded into the 7.0 runtime, it's recommended to reference the 8.0 versions. The issue is that we don't want you adding codeflow from runtime to increase complexity of the codeflow graph. With rc1 being go live, the recommendation would be to target RC1 release versions once it ships and the move to RC2 and then 8.0.0.

[vzarytovskii]

For the net8 target, we should be pulling appropriate versions. I will fix it, and long term, will probably need to add them as darc dependencies.

@marcpopMSFT what would be the easiest way of ensuring we pulling correct packages after I update those?

[vzarytovskii]

@marcpopMSFT all of our 7.0 dependencies are coming from Microsoft.Build.Framework, which latest version is 17.8.0-preview-23411-01, and I couldn't find a newer one. So once it's updated, we'll update it and all of them will be gone.

Or we can stop depending on it, not sure if we need it (or its dependencies) at runtime.

Update: wondering why don't we exclude runtime assets

cc @baronfel and @KevinRansom

[marcpopMSFT]

Ahh good to know. Not sure if MS Build will be updating to have .net 8 dependencies or not. CC @dotnet/kitten who might know.

For the sdk, we're trying to adopt transitive pinning so it doesn't matter if MSBuild or NuGet update to .net 8 versions but unfortunately, that doesn't appear work for fsharp since fsharp is redeployed in the sdk as is (ie it's not pulled in as package references and rebuilt).

dotnet/sdk#34387

[rainersigwald]

Not sure if MS Build will be updating to have .net 8 dependencies or not.

We could for our .NET 8 targets but I'd rather not--it'd add a bunch of dependencies and flow we don't have today.

To fix this fully, we'd have to add an unfortunate set of coherent edges to the repo graph:

graph LR
Runtime ==> MSBuild
MSBuild ==> FSharp
Runtime --> SDK
MSBuild --> SDK
FSharp --> SDK

Loading

Excluding from the F# folder where possible sounds ideal (with download size benefits too!). If that's not possible we should weigh the above against overwriting the files at the SDK layer.

[vzarytovskii]

Going to discuss with @KevinRansom