search

dotnet / fsharp

The F# compiler, F# core library, F# language service, and F# tooling integration for Visual Studio
https://dotnet.microsoft.com/languages/fsharp
MIT License
3.87k stars 779 forks source link

Fsharp has 7.0 references in the tooling going into 8.0.100 #15782

Open marcpopMSFT opened 1 year ago

marcpopMSFT commented 1 year ago

See https://github.com/dotnet/sdk/issues/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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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).

https://github.com/dotnet/sdk/pull/34387

rainersigwald commented 1 year ago

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

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 commented 1 year ago

Going to discuss with @KevinRansom