Lower netstandard of FSharp.Core

[enricosada]

The Microsoft.FSharp.Core.netcore support target framework netstandard1.6.
That's too high, can be lower, ref fsharp/fsharp#669 so is easier to consume fsharp libraries from c# side too.
As a note, c# has netstandard1.4 in templates, so at least that.

to check:

• lower netstandard version
• remove declared deps, if these are already transitive deps
• use same deps version of NETStandard.Library/1.6.1 or if possibile to use that package directly as base, so strange combinations of nupkgs are not resolved when used with other libraries

Is not really important for 2.0, but for 1.0 rtm is nice to have

[Pilchie]

Actually my understanding is that .NET Standard 2.0 will NOT support everything from 1.6, so if it's possible to target something lower now, it's probably better to avoid accidentally taking a dependency on something that won't be there in .NET Standard 2.0.

[cartermp]

The lowest we can go right now is netstandard1.3 since we take a dependency on System.Console. We'll just need to make sure not to have the equivalent of this when we port the project file over to MSBuild 15.

[enricosada]

netstandard1.3 is perfect. Can be lowered later if possible, or not

We'll just need to make sure not to have the equivalent of this when we port the project file over to MSBuild 15.

That's usually not used, for sure not in defaults. And when used can be passed as command line arg, as msbuild property to avoid hardcoded it.
But build specifically for one os is rare, mostly are framework dependent app

[dsyme]

Actually my understanding is that .NET Standard 2.0 will NOT support everything from 1.6

I vaguely thought I'd heard that they'd decided to make them compatible. But I've no idea where to look for an authoritative answer :-/ :)

[KevinRansom]

I have tried getting it down to netstandard1.3 before but failed each time. Although I can’t for the life of me remember why … I think there are some APIs we use that we use that need a higher version. But I can’t for the life of me remember what. Also it doesn’t really matter what version of dotnet that the compiler uses, it only matters what versions the assemblies it builds target. Or am I missing something? Kevin From: Enrico Sada [mailto:notifications@github.com] Sent: Monday, February 27, 2017 11:53 AM To: Microsoft/visualfsharp <visualfsharp@noreply.github.com> Cc: Subscribed <subscribed@noreply.github.com> Subject: Re: [Microsoft/visualfsharp] Lower netstandard of FSharp.Core (#2501) netstandard1.3 is perfect. Can be lowered later if possible, or not We'll just need to make sure not to have the equivalent of this when we port the project file over to MSBuild 15. That's usually not used, for sure not in defaults. And when used can be passed as command line arg, as msbuild property to avoid hardcoded it. But build specifically for one os is rare, mostly are framework dependent app — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fvisualfsharp%2Fissues%2F2501%23issuecomment-282832908&data=02%7C01%7CKevin.Ransom%40microsoft.com%7Cf5d1db948ee84b93a35408d45f4a4319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636238219958165340&sdata=Kq0mq7%2FqIUmUeYQOip2lNo7L1iK%2BsQZxcYdW%2FibtQIE%3D&reserved=0>, or mute the thread<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAE76Fiu9HMVDTC2VpJIpCEeJH2ZKS2Skks5rgymjgaJpZM4MNc6N&data=02%7C01%7CKevin.Ransom%40microsoft.com%7Cf5d1db948ee84b93a35408d45f4a4319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636238219958165340&sdata=uLhlbX89yktiBHqQTuOMfkLAg8THje7w%2FhpCMK7u7eg%3D&reserved=0>.

[Pilchie]

Actually my understanding is that .NET Standard 2.0 will NOT support everything from 1.6
I vaguely thought I'd heard that they'd decided to make them compatible. But I've no idea where to look for an authoritative answer :-/ :)

@terrajobst - can you answer

[slang25]

I recall the same thing, it was announced that .NET Standard 2.0 would not contain the new APIs introduced in 1.5 & 1.6 so that it could be more broader reaching, in a way making the existence of 1.5 & 1.6 "a mistake".

See Immo here between 9 and 11 minutes.

There was a lot of push back from the community that this was not cool, my understanding is that they then decided to revert this decision and have 2.0 be a strict superset of 1.6, while still allowing it to run on .NET 4.6.1, what happens when the few missing APIs get called at runtime on that platform I do not know.

I'm sure @terrajobst can clarify.

[KevinRansom]

I will try to lowere fsharp.core.dl to 1.3. I expect the issues I had were in the compiler. It's quite likely that we can probably keep fsharp.core.dll requiring a low version of .NetStandard for ever, unless we have to leap up to a higher version for some new API.

Let me see what I can do.

Kevin

[KevinRansom]

fsharp.core needs Exit() and BindingFlags both of which are not exposed until netstandard 1.5. So there is not a lot of milage in a netstandard5 fsharp.core since the netstandard 2.0 will go further for some definition of magic that is .Net Standard foo.

We could strip them out like we do for portable libraries but I don't really see the point right now.

[enricosada]

@KevinRansom thx a lot for checking.

If is not something easly done (and netstandard1.5 doesnt change anything), we can just wait a bit, maybe not netstandard2.0, but at least some time.
Maybe after the repo use new sdk, no need to complicate current build coreclr, because we just need to add additional target framework in FSharp.Core package, so no changes for users

The part about check deps, to use the same as .NETStandard v1.6 or v1.6.1 remains, i'll do that later

@Pilchie yes something is removed, if i read right the 2.0 diff with 1.6. dunno if matter for f#. but maybe is not up-to-date

[enricosada]

/cc @dustinmoris

[masaeedu]

fsharp.core needs Exit() and BindingFlags both of which are not exposed until netstandard 1.5.

@KevinRansom Is that Environment.Exit? Maybe the missing API can be implemented in a NuGet package? There is still some utility in trying to get down to .NET Standard 1.3, if only to support the .NET 4.6 runtime (.NET Standard 2.0 will support 4.6.1).

[dsyme]

@KevinRansom Is it possible to ship have a .NET Standard 1.3 and a .NET standard 1.6?

[KevinRansom]

Yes ... but ... there isn't much point ... profile 259 is more than good enough for that kind of compatibility. And doesn't have us building, testing and shipping another another FSharp.Core.dll profile.

[dsyme]

@KevinRansom Hmmmm... are people in this thread willing to build an F# libray ecosystem based on Profile259? @enricosada What's the problem with that approach - is it psychological (want to forget all about PCLs and start afresh) or technical?

[masaeedu]

The problem with this approach is that the tooling is very new, and anything that isn't .NET Standard proper is unlikely to have good support. Not everyone is intimately familiar with the intricacies of MSBuild or PCLs, and you often have bugs like dotnet/sdk#391 that you need to understand and work around.

In theory, whatever subset of the code is building on profile 259 should build as-is on .NET Standard 1.0, because there is a 1-1 mapping between the API surface they support. See the table at the bottom here: https://docs.microsoft.com/en-us/dotnet/articles/standard/library#pcl-compatibility

[masaeedu]

As mentioned on that page:

Profile-based PCLs packaged as netstandard are easier to consume than typically packaged profile-based PCLs in project.json. netstandard packaging is compatible with existing users.

So this is just a question of adjusting that build so that an easy-to-consume .NET Standard 1.0 package is produced in addition to whatever nupkgs you're already distributing.

[KevinRansom]

@masaeedu So ... what doesn't work if you use profile 259?

[enricosada]

@dsyme i dont think is a big issue atm. was something worth investigate if was easier to do (lower to 1.5 doesnt matter at all), didnt know about exit (thx @KevinRansom to check that).
But as i wrote, can be done later, to not complicate build system now ihmo.
The FSharp.Core can be update to support another target, so netstandard1.6 and netstandard1.3, for example, but not urgent

Pratical usage is: library author (f#) want to publish a library.
Because depends on fsharp.core, that mean will need at least netstandard1.6. So will work on .net full >= 4.6.1, ref netstandard version matrix. netcore/mono are not affected.

So if library author want to support .net 4.5 or 4.6 need to add another target, depending on fsharp.core net40.

uwp/winphone are not an issue for f#.

Maybe is not an issue in f# ecosystem, but can be a bit noisy if a c# lib (usually netstandard is low by default, so they go all in with netstandard) want to use a f# lib.

All that is useless with netstandard2.0 because that is gonna reset everything.

Other than that, nothing else afaik.

As @KevinRansom said, they can also use the fsharp.core pcl package and Microsoft.NETCore.Portable.Compatibility.

[cartermp]

Shipping a netstandard1.3 version of FSharp.Core would require work on our part to factor out our dependencies on BindingFlags and System.Environment.Exit. This is work we could do, but we also have significant holes in other areas and investments needed in the upcoming netstandard2.0 support that it may not be worthwhile for us to factor FSharp.Core in that way.

[KevinRansom]

I think we have a consensus.

Closing.

[dsyme]

@enricosada

Pratical usage is: library author (f#) want to publish a library. Because depends on fsharp.core, that mean will need at least netstandard1.6. So will work on .net full >= 4.6.1, ref netstandard version matrix. netcore/mono are not affected. So if library author want to support .net 4.5 or 4.6 need to add another target, depending on fsharp.core net40.

Really? Let's say they want to make an .NET Standard 1.3 F# library. Then they just need to reference the Profile259 FSharp.Core from their library. What goes wrong with that?

[davidfowl]

Really? Let's say they want to make an .NET Standard 1.3 F# library. Then they just need to reference the Profile259 FSharp.Core from their library. What goes wrong with that?

You need to add imports to your project file because even though portable is API "compatible", it's still not netstandard. It would be better to have a netstandard1.0 or netstandard1.1 asset that as well as the PCL259 dll.