.NET Core support discussion

[tjaskula]

Some of the libraries or frameworks that depends on that library cannot be upgraded to .NET Core because FSharp.Quotations.Evaluator doesn't support it. I would like to discuss if adding .NET Core support for
netstandard1.6 might of interest to you.

[manofstick]

I don't know what is involved, but it sounds like a good idea. I probably could find some time this weekend (maybe!) to investigate, or if you've already got a plan then I'm happy to accept a PR.

[tjaskula]

Thanks. I'll be happy to work on that one

[dsyme]

We should just convert the library to .NET Standard 1.6 or 2.0. sooner or later (and not have a specific version for .NET Framework).

Nearly all the library projects under http://github.com/fsprojects should go the same way. It's going to be a big endeavour to convert them all, and we may archive some in the process, but it's really important to do it

[tjaskula]

@dsyme Thanks for details. Are there any recommendations or standards to follow for fsprojects for this conversion? I may just inspire myself from what has been already done on one of them.

[dsyme]

@tjaskula Roughly this involves

1. Making sure latest FAKE is being used (doing a .paket\paket.exe update and submitting as a separate PR)

2. converting the project file to the .NET SDK project file format, e.g. delete loads of stuff fsprojects/FSharp.Data@master...dsyme:ns2#diff-c64e6937c9d61836ece07888b82ad1a8

3. targeting the library at netstandard1.6 or netstandard2.0

4. fixing build.fsx to build using the .NET SDK, e.g. here

5. Test projects should probably still be .NET 4.x/Mono projects (that is, we won't yet run tests on .NET Core - were just building a .NET Standard library and testing it's use on .NET 4.x/Mono). We can talk about converting tests separately, I'm not experience in doing it

6. We may hit issues with documentation generation. I was looking at ExcelFinancialFunctions - which generated a portable library - and documentation generation seemed to fail. We may hit similar issues when generating .NET Standard libraries.

We can certainly experiment now and convert 1-2 libraries (I've been looking at FSharp.Data as you can see). Personally I think we should wait a few weeks fbefore doing anything en-masse. By then

• .NET SDK 2.0 is finalized
• .NET SDK 2.0 will be widely available on CI servers
• Some bugs will have been ironed out in F#
• Tooling to edit new-style .NET SDK projects will delivered as part of Visual Studio 2017 Update 3 (it is already available for Ionide)

It's just wasting our time before then to do anything em-masse.

[dsyme]

@tjaskula One thing that would be really, really great is if we could have a guide on http://fsharp.github.io that describes this process.

Would you be interested in taking the notes above and converting them into a guide and maintaining it over the next few months? I and @enricosada would help contribute technical details. All you have to do to create a guide is submit a PR to https://github.com/fsharp/fsharp.github.io/ adding an appropriate new file under https://github.com/fsharp/fsharp.github.io/tree/master/_posts

We would then also eventually update ProjectScaffold to generate netstandard1.6 or netstandard2.0 libraries by default

[dsyme]

@tjaskula BTW I notice this just posted by @forki https://fsprojects.github.io/Paket/paket-and-dotnet-cli.html

[sergey-tihon]

Does it worth to do the migration to new project format now? (When VS does not support new *.fsproj file) When I worked on .net core support for FsUnit/NUnit @enricosada said that the recommended approach to keep both files (old fsproj and new fsproj) to be able to use VS.

[tjaskula]

@dsyme Thanks for all those details. This is awesome. Of course I'll make the guide to document the process, that might be adjusted after the .NET SDK 2.0 is finalized.

@manofstick you can assign me to this issue. I'm starting to work on that.

[dsyme]

Does it worth to do the migration to new project format now? (When VS does not support new *.fsproj file) When I worked on .net core support for FsUnit/NUnit @enricosada said that the recommended approach to keep both files (old fsproj and new fsproj) to be able use VS.

@sergey-tihon See this comment from me:

We can certainly experiment now and convert 1-2 libraries (I've been looking at FSharp.Data as you can see). Personally I think we should wait a few weeks before doing anything en-masse.

[enricosada]

ihmo poc is best atm, to support both (old sdk and new sdk) like now lib are doing, can be done obv, but is friction and not painless, so as @dsyme said, just wait a bit when vs 2017 support it, so zero reason to stay using old (except vs2017, all ides (xamstudio/vscode/emcas/vim/rider) already works with sdk 1.0 or 2.0, and tooling in ecosystem too).

I have in todo a guide old sdk -> new sdk using a random project (with the usual structure) as example:

1. complete conversion using same target frameworks (net45), but to use new sdk fully (dotnet pack, fake, paket, dotnet test etc)
2. how to add netstandard later for lib and netcoreapp for .net core console

in two steps, because you first fix the sdk/fake/paket issues producing the same output, and later you add netstandard and fix api compatibility.
The new sdk support multiple target framework as first class, so is easy to support both, like <TargetFramework>netstandard1.6;net45</TargetFramework> and usual ides (dunno VS, but think that too later with update) already support working with multiple targeting

i have already done lot of tutorial to support in parallel old sdk/new sdk, but just repeal and replace is better strategy soon (and with helper fsx script, can be automated a lot, to convert old fsproj -> new fsproj).

[dsyme]

Yes I think it's better to just prepare a PR which rips out old-style project files and replaces them with new ones. I don't want anyone to waste precious time by bifurcating projects. VS support for .NET SDK projects, .NET Standard and .NET Core is coming, let's not bifurcate any more.

We can choose when to accept the PR in a few weeks or months, and people can cherry-pick it at the moment. We shouldn't struggle to get these PRs green if CI is not easily supporting .NET SDK 2.0 - I don't want to see any more manual installs of .NET SDK during CI (except in the really core projects that have it today).

I'm really, really fed up with the bifurcation caused by .NET Core and new .NET SDK tooling. I like what I see in .NET SDK 2.0 and I want to see the community on a strong path to simplicity and convergence.

That said, I have concerns about the F# Interactive and F# type provider tooling support for .NET Standard 2.0 libraries. See dotnet/fsharp#3307 and dotnet/fsharp#3309. We're working through these but we should not really create a mass of widely shared .NET Standard 2.0 libraries until we've sorted out these issues (private libraries are fine, also libraries only used by fsc.exe). Equally, we shouldn't spread FUD about .NET Standard 2.0 - .NET Standard 2.0 is a great thing and will be an excellent basis going forward, and we have to rebuild community confidence that .NET Core/.NET Standard/.NET Framework is going to be simple and fun rather than full of headaches.

[enricosada]

I'm really, really fed up with the bifurcation caused by .NET Core and new .NET SDK tooling

Atm the bifurcation exists just in F#. In c# everyone just move to new csproj, and that'it (also for just use it for net46, without .net core or .net standard, because slimmer, easier by cli and multi fw, and support wildcard compile who is nice in c#).

@dsyme marketing ihmo should be: "move .net to new sdk, ignore netstandard/netcore/dotnetcli and add these later"

For F# (vs c#) is an issue because we cannot move completly yet, because VS is not ready yet, and noone want to lose that (also if rider/vscode/xamstudio works) ). but new libs use it, like fable, or early adopter github search
but tooling and lib and helpers (fake/paket/ci/test lib) are solid already.

We shouldn't struggle to get these PRs green if CI is not easily supporting .NET SDK 2.0

yes atm is not by default. as a note, if you need it for the PR, possibilities are:

• travis is https://github.com/dotnet/docs/blob/master/.travis.yml#L16-L20 just use the release/2.0.0-preview2 branch (or whatever you need)
• appveyor is https://github.com/dotnet/docs/blob/master/appveyor.yml#L10-L14 same as before, choose the right branch
• use this function like we do in fsac https://github.com/fsharp/FsAutoComplete/blob/master/test/FsAutoComplete.IntegrationTests/TestHelpers.fsx#L207-L245 if you have an fsi ready

Pratically, download a script, execute it to unzip in a dir, add that dir to PATH

i really need to write a dotnetup nightly like cargo/rust does sigh

working through these but we should not really create a mass of widely shared .NET Standard 2.0 libraries

Yes, lib initially should also support net45 too as best pratice.

@dsyme again, maybe we should prepare a doc, to explain what new sdk matter for F#, and best pratices. maybe the final nail in the https://github.com/dotnet/netcorecli-fsc/wiki coffin, and add that to fsharp/fsharp wiki/website?

Ihmo everyone should also add net46 if possibile because is simple stupid with new sdk multiple framework support, is just

<TargetFramework>net46</TargetFramework>

to

<TargetFrameworks>net46;netstandard1.6</TargetFrameworks>

not a big deal because these net46 will build also using dotnet cli, so with dotnet build or pack, is just not possibile to run it (if runtime is not installed)

same for using msbuild /t:Pack (.net full), to build net46;netstandard1.6or evennetcoreapp`. are just normal tfm

[dsyme]

@dsyme marketing ihmo should be: "move .net to new sdk, ignore netstandard/netcore/dotnetcli and add these later"

That's reasonable.

[dsyme]

add that to fsharp/fsharp wiki/website?

Use http:://fsharp.github.io. That's our website for F# Core Engineering, and that's what we do. We should use it more

[dsyme]

@dsyme marketing ihmo should be: "move .net to new sdk, ignore netstandard/netcore/dotnetcli and add these later"

One concern is that the compiler executing on .NET Core is slower, due to the lack of NGEN on install? Or is some kind of crossgen run? I haven't kept track of this

[enricosada]

doesnt matter ihmo.

• if in .net, devs will use msbuild, so will use ngen'd compiler because is bundled in VS and ngen'd (that was the primary reason for kevin to not use FSharp.Compiler.Tools, but ihmo was better to just ngen after unzip the nupkg, but it's ok)
• on mono msbuild, will use mono fsc, again, like before
• on .net core with dotnet msbuild (btw faster than mono version afaik), will continue to use .net core fsc, so is faster.

[enricosada]

reason to not move afaik are (today):

• VS support of new project system
• VS doesnt bundle partial fsharp.net.sdk , so doesnt work OOTB with msbuild.exe (again, cli bundle it, why VS doesnt want.. sigh), but will work with sdk 2.0 OOTB
• PCL are deprecated in new sdk, so 1-1 matting is not always possibile
• mix old sdk and new sdk project in proejct references
• require mono 5, and running old fsproj in mono 5 has bugs (afaik) and fsi too maybe. parallel mono is not easy

all bugs i know have workaround (and less bugs than old sdk anyway), and usually situation is better like on FSAC new project parsing (who completly replace old project cracker) is solid AND fast. and devs like it

[dsyme]

• if in .net, devs will use msbuild, so will use ngen'd compiler because is bundled in VS and ngen'd (that was the primary reason for kevin to not use FSharp.Compiler.Tools, but ihmo was better to just ngen after unzip the nupkg, but it's ok)

OK, yes, good point I suspect a lot of devs will use dotnet CLI tooling, but we can tell them to use msbuild

[tjaskula]

Does this mean that if convert the whole project to support the current .NET SDK, the PR won't be accepted until VS support is fixed, etc. ?
My initial request was just to get this library complient with netstandard1.6. For exemple, the whole Akka.NET C# is converted to .NET Core right now and it will be released, unfortunatelly without F# API if we don't do the needed stuff here.
So this can be a temprary choice, and F# API can be added later on, once everything is fixed again in F# space.

[enricosada]

My initial request was just to get this library complient with netstandard1.6. For exemple, the whole Akka.NET C# is converted to .NET Core right now and it will be released, unfortunatelly without F# API if we don't do the needed stuff here.

that's a good reason for an hastly release.
I'd like to help, want to chat in slack?
And no, lot of lib support just netstandard1.6 (with new sdk) and old fsproj for everything else.

So if you want to do that (ihmo, i am not project maintainer):

• avoid sdk 2.0. is preview now, so more bleeding edge, and more annoying atm.
• use sdk1.0, it works (more info in wiki ), and transition to 2.0 will be later REALLY REALLY smooth )
• add in parallel, dont convert everything. the goal is just to release a package with netstandard1.6 support asap.
  • just dotnet new lib -lang f# and add a library in same directory, like suave does in src/Suave/Suave.netcore.fsproj
  • make that lib compile (dotnet build)
  • make a package with that lib with just netstandard1.6 (dotnet pack)
  • in the build script, invoke dotne pack and merge that package in current one. exists a tool for that dotnet-mergenupkg and in build fsx is like this

any issue, concat me. is a matter of 30min for small libs, if api of netstandard1.6 is enough (usually is for small lib).

[dsyme]

and it will be released, unfortunatelly without F# API if we don't do the needed stuff here.
....
that's a good reason for an hasty release.

It's a good forcing function, but we should not delay Akka.NET on this. Rushing things can lead to real problems.

If we don't make it in time, we should work separately to get the F# .NET Core support in place. They will have an incremental update

[enricosada]

@dsyme i was speaking of not wait sdk2.0 rtm.

my proposed is the same flow used by everyone (sauve/argu/paket/anyone) who have a netstandard1.6 lib. It's the only sane workflow atm for reduce friction and maintain features, pretty much battle tested.
we can also run whole test suite too for netstandard. is not too risky.

also this netstandard version will be used only by netstandard akka.net, so low risk anyway (alternative is doesnt exists :D), will not create regression in net46

[dsyme]

@dsyme i was speaking of not wait sdk2.0 rtm.

By all means give it a go. What I meant is that we should have good processes, good tracking of issues, good step-by-step progress, and "haste not waste" :)

[tjaskula]

@dsyme @enricosada thanks for all precious advices. I'm committing myself to the task :)

[tjaskula]

I've sent a PR with .NET Core support but it seems that there are issue on build servers. FYI, the build process hasn't change for CI so Dotnet core stuff isn't invoked. Just a bare minimum.

[enricosada]

I'll send a PR to that PR to add .net core in CI too, awesome work @tjaskula !

[tjaskula]

Thanks for you help @enricosada. Really helpful to make it happen

[manofstick]

Implemented in #16