Update to FSharp.Core for F# 4.1 and release .NET Standard 1.6 support in v2.next

[kurtschelfthout]

Now that VS 2017 is out, the pressure to support .NET Standard and .NET Core is only going to grow. We currently have the code to make FsCheck .NET Standard 1.6 and .NET Core compatible in the fscheck3 branch. This effectively ties together the timelines for .NET Standard support and v3.

I don't think this is a good situation.

.NET Standard support feels more urgent than getting v3 out, which is getting a fair amount of improvements (random generation, parallel/async testing, API cleanup) but really 2.x is very usable right now as is.

Concretely what I propose is the following:

• Update FsCheck to target FSharp.Core for F# 4.1: https://www.nuget.org/packages/FSharp.Core/
• Release FsCheck with a minor version increment, e.g. currently 2.8.0 so that it supports .NET Standard 1.6 directly

So really we support more or less the same set of platforms as before, except for folks targeting older versions of FSharp.Core.

Thoughts?

[eriawan]

@kurtschelfthout
I suggest to do the upgrade now, but we should also:

1. watch/track the availability of updated F# 4.1 tooling on Visual Studio 2017.
2. start to target .NET Standard 2.0 instead of .NET Standard 1.6 by tracking the .NET Standard 2.0, because the .NET Standard 1.6 is not quite complete port from .NET Framework 4.6.1. To keep in sync with .NET Standard 2.0, we can set to use .NET Standard 1.6.1 API surface now, but we should also keep track with .NET Standard 2.0 release. We can always check https://apisof.net/ and dotnet/corefx repository to track this.
3. We should have an issue to track the TODO list of .NET Standard compliance implementation as well. But the list needs to be defined first 🙂

Side note:

• As far as I know, there is no .NET Standard project template available for F# in VS 2017. CMIIW for this.
• Once we start to use VS 2017, we should also use the nightly build of Visual F# 4.1 tooling. Current F# tooling in the initial installation of VS 2017 has bugs. See the announcement of this in https://blogs.msdn.microsoft.com/dotnet/2017/03/14/announcing-nightly-releases-for-the-visual-f-tools/
• about the list of third point, I could offer my help 🙂

Yup, this is my own thoughts/0.02$

[kurtschelfthout]

Thanks for your comments.

watch/track the availability of updated F# 4.1 tooling on Visual Studio 2017.

Do you mean as a practical concern to develop FsCheck in VS2017? The approach we have in the branch doesn't need VS support, it uses dotnet CLI to build/test/package for .NET Core/.NET Standard (need to check this), which I think we can just copy.

start to target .NET Standard 2.0 instead of .NET Standard 1.6 by tracking the .NET Standard 2.0,

Why would FsCheck target 2.0? We currently target net452 which is compatible with netstandard13. But, FSharp.Core only targets 1.6. The advice (reasonably) for libraries is to target the lowest version of .NET Standard we can get away with - so as it stands that seems to be 1.6. Also that would make FsCheck automatically compatible with .NET Standard >= 1.6, including 2.0. Right?

We should have an issue to track the TODO list of .NET Standard compliance

I don't understand why - can you elaborate?

[eriawan]

Do you mean as a practical concern to develop FsCheck in VS2017? The approach we have in the branch doesn't need VS support, it uses dotnet CLI to build/test/package for .NET Core/.NET Standard (need to check this), which I think we can just copy.

Yes. Because validating build to comply with .NET Standard is easier with tooling support, imho.

But, FSharp.Core only targets 1.6. The advice (reasonably) for libraries is to target the lowest version of .NET Standard we can get away with - so as it stands that seems to be 1.6.

The .NET Standard 1.6 relies on .NET Framewok 4.6.1 as the baseline. This will be in sync with FSharp.Core that comply with .NET Standard 1,6. Yes, .NET Standard 1.6 is the best version to comply today, I agree.

Also that would make FsCheck automatically compatible with .NET Standard >= 1.6, including 2.0. Right?

Not really. .NET Standard 2.0 is a strict superset of .NET Standard 1.6, therefore .NET Standard 1.6 is compatible with .NET Standard 2.0. Yes, on the perspective of API side, making FsCheck to comply with .NET Standard 1.6 will also run or compatible in .NET Standard 2.0.

We should have an issue to track the TODO list of .NET Standard compliance

I don't understand why - can you elaborate?

Unfortunately, on the base of project system used in .NET Standard 2.0 is totally different from .NET Standard 1.6. Some of us may still use the now legacy model of MSBUILD project that has GUIDs in it. Starting with .NET Standard 2.0 (and also .NET Core 2.0) the VS tooling and project system will use Visual Studio CPS (Common Project System), and there's no backward compatibility even though you can still consume .NET standard 1.6 library at run time.
Therefore, there's no guarantee that existing codebase and project system (including the .fsproj and .sln) will be forward compatible for .NET Standard 2.0.

Also, in the .NET Standard 2.0 readyness, if we are looking at the roadmap of .NET Standard 2.0, version 2.0 will be released in this year, approximately Q3 2017. See https://github.com/dotnet/core/blob/master/roadmap.md
The .NET Standard 2.0 will also be the baseline of .NET Core 2.0, which is due to be released at the same time as .NET Standard 2,0. Therefore, assessing and focusing in ,NET Standard 2.0 is more relevant to me, because .NET Standard 2.0 has backward compatibility at runtime library level, but it's closer to match the .NET Framework API 4.6 API parity, I have checked this, using MS ApiPort and check it against the list in https://apisof.net website.
This is why I proposed to have TODO list of API parity/compliance checking against .NET Standard 1.6 or 2.0, by creating an issue as the umbrella of tasks of verifying API readiness against .NET Standard.
And I believe (based on the roadmap on the link) it's also easier to start to focus on .NET Standard 2.0 now, It's easier for me because I'm afraid by the time we finished complying with .NET Standard 1.6, we may have harder effort to comply with .NET Standard 2.0 later based on the tooling and the timeline of the .NET Standard 2.0 itself, as it's near in preview and release.

[kurtschelfthout]

@eriawan I understand, you are mostly worried about upgrading the FsCheck codebase to be .NET Standard and CPS compatible. To be honest I am very reluctant to change much at this point, as the past year has shown that MSFT changes their approach roughly every 3 months. Also F# is lagging behind in tool support and will for the foreseeable future. Stuff like Ionide and OmniSharp are getting better and better and I've considered a few times to not bother with VS at all. Personally I wouldn't mind but I think lots of contributors are still using it so I don't want to jump the gun.

Anyway, for this particular issue, I am not concerned with the FsCheck codebase per se: I would just like the FsCheck NuGet package to be easily consumable from .NET Standard projects. As demonstrated on the fscheck3 branch, that seems doable without switching to the CPS and so on.

Granted, the time may come, with .NET Standard 2.0, when this becomes a necessity, but 6 months is an eternity in MSFT time and I don't have the time or inclination to follow every moodswing ;)

[kurtschelfthout]

I've noticed that in a proper nuspec, one can add dependencies per target framework. See https://docs.microsoft.com/en-us/nuget/schema/nuspec#dependencies. So conceivably it should be possible to keep FSharp.Core 3.1 support for the frameworks we target now (net452, portable profiles) and only need 4.1 for .NET Standard. That would be like having our cake and eat it too, I think.

Unfortunately paket pack does not support this (yet) fsprojects/Paket#913 but I think it's worth switching to NuGet pack for it.

[wallymathieu]

Even if the tooling has changed from project.json to csproj libraries that use project.json can still be used if they are made into nuget packages.

[enricosada]

@kurtschelfthout so, tooling doesnt matter. your project.json (preview2) can generate netstandard1.6 package, like the fsproj (rtm)

Your plan is ok

Update FsCheck to target FSharp.Core for F# 4.1

that's the right package to use, any 4.1.*)

release a package with netstandard1.6

awesome!

As a feedback, dont wait for .net standard 2.0. it doesnt really matter, and will be ok only in Q3.

@kurtschelfthout you can use .net core 1.0 rtm (fsproj) to generate the netstandard1.6 like now in fscheck3 branch.
is going to be another fsproj in same directory (instead of the project.json). you dont need to go all in with new fsproj (as @eriawan said, is not yet supported in VS if that matter for you), you can have both, in same directory. like now with project.json.

@eriawan as a note, tooling for netstandard1.6 and netstandard2.0 is the same. .net core and netstandard already works, is just VS who doesnt support it.
if you are waiting VS support, that will support both (same fsproj can also target net45 or any target fw).

Please release a netstandard1.6 package if possibile, so ecosystem can start use this awesome library!
Any issue feel free to ping me.

If you want is a good idea to convert project.json (preview2) to use rtm (fsproj). No source code changes, just the project files (is just a tooling change).

[kurtschelfthout]

@enricosada if you have some time at some point can you take a look at the PR #371 and see if you think this is the right way to do things?

I added .netcore projects in the new format, no project.json (I figured I might as well use the newest format). I think it works, at least it builds, tests, and produces a nupkg with a netstandard1.6 folder in it :)

Few questions -

1. I was under the impression paket had some .NET Core support, in particular to reference nuget packages and possibly even to pack the FsCheck package with the .NET Core stuff in there. Am I wrong? Any docs for how to use or examples or pointers? I think this would simplify things a lot as I now have the same version numbers for dependencies in paket.lock and in the netcore fsproj, etc.
2. I notice the netcore build does not produce a pdb, is that expected? (If not expected, do you know if it can be sourcelinked?)

[enricosada]

sry @kurtschelfthout i have no free time to do that in the next week.
Sry about that, dont want to say yes, and after not doing it.

I think you can try to ask in #dotnetcore channel in fsharp.org slack, there are some ppl there who can do it, or check other F# proj in ecosystem who already has done that for dev.

[kurtschelfthout]

@enricosada no problem mate, I'll figure something out. I think I'll just test the outcome of the current approach manually, if that works the process can always be improved afterwards.

[kurtschelfthout]

I've released an rc2 for FsCheck, FsCheck.Xunit and FsCheck.Nunit wit .NET Standard support here:
https://www.nuget.org/packages/FsCheck/2.9.0-rc2
https://www.nuget.org/packages/FsCheck.Xunit/2.9.0-rc2
https://www.nuget.org/packages/FsCheck.NUnit/2.9.0-rc2

It looks relatively ok, except what's wrong is that FsCheck.Xunit and NUnit in NET Standard version have a dependency on FsCheck >= 1.0.0. I don't know where that version comes from...it should be 2.9.0-rc2.

[0x53A]

I think when using nuget pack, the version needs to be set at RESTORE time, not at pack time. Otherwise it will default to 1.0
There was another project with a similar issue, but can't find that right now.

Edit: may be NuGet/Home#4337
NuGet/Home#4867

[kurtschelfthout]

@0x53A yes, looks like setting the version at restore time helped. Also needed to set the version everywhere, even for the FsCheck.Test project or things went wrong seemingly arbitrarily (like FsCheck.Xunit referring to 1.0.0 while FsCheck.NUnit had the right version...). Pretty strange.

Anyway, 2.9.0-rc3 is on NuGet and it looks ok to me. Please test if you can.

[kurtschelfthout]

Since this has been released in 2.9, I'm going to close this issue. Any problems with consuming netstandard, please open a new issue or PR.