Is it safe to upgrade .NET Framework projects to 6.0?

[jimfoye]

I have .NET Framework projects on 4.x and 5.x. There is no indication in the nuget interface inside Visual Studio that there should be any problem upgrading these projects to use 6.0. But I'm hesitant because of this comment that @cartermp made on a Reddit post, in response to a question from someone else about upgrading:

I see no reason to ever manually mess with FSharp.Core unless it's to target a lower version when you are authoring a package intended for broad distribution.

FSharp.Core isn't any old library. It contains numerous compiler intrinsics and there is zero guarantee that any arbitrary older compiler will understand any contents within any arbitrary newer FSharp.Core. The opposite is guaranteed though, hence why downtargeting is okay for the specific scenario I mention.

Otherwise just stick with what project templates give you. That's tested and guaranteed to work.

He says, "stick with what project templates give you", which would be 5.x when creating .NET Framework projects in VS 2019. Shouldn't there be some information on this in the nuget tool, if upgrading is not supported? Or am I misunderstanding Phillip's comment?

[cartermp]

You should just stick with what the project templates get you, and also plan to migrate from the legacy .NET Framework IMO. I don't think there's anything that will bust your code if you from using FSharp.Core 6.0 (note: this is not the same thing as F# 6), but...who knows. .NET Framework is legacy, it gets tested less and less, and F# 6 still isn't released yet, so it's best to just use what the project templates give you. I imagine with VS 2022 they're using FSharp.Core 6.0 because that's tested.

[dsyme]

There are three things here

1. Updating to .NET SDK 6.0
2. Updating to FSharp.Core 6.0.0
3. Updating to F# 6.0
4. Using all the above for .NET Framework projects

The simplest thing is just to move to .NET SDK 6.0, e.g. by bumping your global.json to use a .NET 6 SDK (currently in preview). In that case, you will get FSharp.Core 6.0.0 and the preview F# 6.0 by default (unless you have explicit settings to change that).

If you want to use .NET 6 SDK but don't want to the default to F# 6.0 language version then use

<LangVersion>5.0</LangVersion>

If you want to use .NET 6 SDK but don't want to update to the default FSharp.Core 6.0.0 then use this for example:

<PackageReference Update="FSharp.Core" Version="5.0.2" />

If you want to stick with .NET SDK 5.0, then it's safe to upgrade a project to use FSharp.Core 6.0.0 and use it from F# 5.0 and .NET SDK 5.0 and VS2019 etc. and .NET Framework projects too (subject to your usual QA process, due diligence etc, and whatever the license says). Use this in your project file:

<PackageReference Update="FSharp.Core" Version="6.0.0.0" />

That said, Phillip's guidance is right and it's probably best not to, there's no real point, though it will happen automatically for C# projects for example, so it's important that it works.

there is zero guarantee that any arbitrary older compiler will understand any contents within any arbitrary newer FSharp.Core.

In practice, to my knowledge, F# compilers from all the way back to F# 2.0 can use and read FSharp.Core 6.0.0.0 - or at least from around F# 4.0 (2016? The addition of the NativePtr instrincs may have used some features for new IL instructions added about then). But he's right that there isn't a strong guarantee this will work for all older F# compilers.

[jimfoye]

I realize the primary advice is going to be to move off the Framework and on to .NET 6, I have reasons (which I don't need to get into here) for not doing that yet (and I'm sure that's true for some other folks as well).

So, my understanding is, it will probably work, I should test to make sure, but really I don't need to do this. So, I will just wait on upgading Framework projects to FSharp.Core 6.0 until I move to VS 2022.

I had already planned to move to VS 2022 as soon as RTM is out. But of course many folks will not upgrade right away. Should some wording be added to the nuget package description? Just wondering. Maybe it's not needed.

Thanks.

[dsyme]

Should some wording be added to the nuget package description?

Yes ideally we should include a link to an updatable page giving guidance on these things and any other unexpected issues that might arise