Support .NET Standard
markhepburn opened this issue · comments
I appreciate this is probably tricky to address and not a priority, but floating it out there anyway.
We'd love to experiment with this, but our main projects still need to run on a net40 server.
I had a brief attempt; the fparsec dependencies were relatively easy to back-port, but there's more complications here (the read-only collections are an obvious issue, but even replacing those with the mutable interfaces still left a lot of errors).
Any thoughts on how feasible it should be?
Hey Mark,
I'm on vacation until tomorrow, but I'll take a look at this when I'm back.
We use some features that require 4.5, but to my knowledge none of them are
necessary to the operation of the library. I expect it should be possible
to target 4.0.
Another aspect of this is that at some point I was wanting to target the
.NET standard for compatibility with Core. I could probably make a pass to
do that and get 4.0 support for free.
On Sun, Sep 18, 2016, 5:36 PM Mark Hepburn notifications@github.com wrote:
I appreciate this is probably tricky to address and not a priority, but
floating it out there anyway.We'd love to experiment with this, but our main projects still need to run
on a net40 server.I had a brief attempt; the fparsec dependencies were relatively easy to
back-port, but there's more complications here (the read-only collections
are an obvious issue, but even replacing those with the mutable interfaces
still left a lot of errors).Any thoughts on how feasible it should be?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#34, or mute the thread
https://github.com/notifications/unsubscribe-auth/AB2Kwnkb8jQm7Wo5wJNgUSIJLEWVG2i3ks5qrdkBgaJpZM4KAEI6
.
The dependencies FParsec and FParsec-Pipes cannot be used yet with netstandard1.6 framework. (Also only FParsec can be used with net40)
I'll try to make a proposal PR for this to convert the projects to the project.json structure.
Hi Chad, thanks for looking into this! Actually as timing would have it I've just (finally, finally) heard that we can get an upgrade to 4.5, so it's less of an issue for me personally now. Having bumped into issues like this for a while now though I'm always curious. Core support would be great too at some point; we're actively investigating that.
I didn't run any tests at the time, but I got fparsec-pipes to compile on net40 by re-implementing Seq.indexed. The lack of immutable collections in net40 might be the biggest issue -- it was probably the main thing I noticed when arriving from Java.
@StefH that's a good point about the F# projects. We'll have to wait until F# 4.1 releases so that F# projects can target the .NET standard (https://blogs.msdn.microsoft.com/dotnet/2016/07/25/a-peek-into-f-4-1/).
@markhepburn I'll talk to the author of the fparsec-pipes library to see what he thinks about supporting net40. I can send him a pull request if the changes aren't too invasive.
F# is supported in .NET Core already, isn't it? It looks like "Visual Studio Tools for F# 4.1" is the part that is yet to be updated - so it would be commandline only initially I guess. But I've seen some references to people using F# from the dotnet commandline. (I.e in issues around EF Core ;) - guess it's not at 100% yet!)
Does using project.json imports (with net40) not do the trick for FParsec?
Update - with an imports: [ "net451" ] and dep on "Microsoft.NETCore.Portable.Compatibility": "1.0.1" as well as "GraphQL.Net": "0.2.4", I was able to package restore/build. But some error loading System.Core 4.0.0.0 kills building a schema at runtime. I don't have my head around the entire ecosystem yet...
I haven't played around a whole lot with Core or Standard, but it was my understanding that F# tooling for those targets was still in preview. I definitely want to target .NET Standard as soon as possible, but I also don't want to sacrifice having an easy build in VS to make that happen (both for myself and for contributors).
I'm talking with some F# guys in their Slack channel to get ideas on what the best way forward is.
Reporting back:
Had a discussion with @cartermp about the best way forward for platform compatibility with F#, and it seems like the simplest thing to do is to wait until the release of .NET Core 1.0, .NET Standard 2.0, and Visual Studio "15" (all should release at/around the same time). To me, this quote seals the deal:
Today the tooling for .NET Core/Standard (and this includes build system) is completely independent, and it’s very difficult to get it to talk to existing code. With VS 15 it’s msbuild-based, and is designed to talk to existing projects.
After reviewing the options, I've decided that I will not be targeting .NET 4.0 with this library. In the future, I would like to execute queries using asynchronous APIs where available, but to do this I don't want to have to take a dependency on Microsoft.Bcl.Tasks.
However, I do want to support .NET Standard when it's available for F#. Given that a lot of the discussion in this issue has been about .NET Standard, I'm renaming the issue to track support .NET Standard.
To reiterate, I want to target .NET Standard as soon as possible - so work on this issue will resume when Visual Studio "15" releases.
Makes sense to me 👍
@ckimes89 Hey, just tried pulling this package into a net core 1.1 app and it failed. Any update on building a core nuget package?
@cburnette I was putting off all netcore work until .NET Standard 2.0 was released (which, afaik, is still being released with VS2017). The main reason for this is that the story for targeting netcore with F# libraries is currently not great, and that most of those problems should be solved with .NET Standard 2.0.
@ckimes89 Just a reminder now that .NET Standard 2.0 has been released; will you retarget graphql-net to it?
What about version for Net Core? Thx
+1
+1
+1
+1
+1
+1
Would it be possible to swap over to the same lexer/parser that graphql-dotnet uses, which already supports .NET Standard 1.1? Any particular reason to use the F# parser which seems to be holding this back?
It's worth noting that FParsec now targets .NET Standard 1.6.
@cartermp Well noted 👍
Any update on this issue?
I would love to see this in .net core, too. Is there something one could do to help? I allready fiddeled around with the sourcecode, but was not all too sucesfull...
@vertonghenb
do you know f#? I never done this and just tried to port the projects but failed as the "pipes" project is not ported to .net core yet. Maybe there is an easy fix for somebody that knows F#.
Somebody here suggested using the parser from graphql which I think is a good idea (but mostly because I do not know f#). But I would be pretty suprised, if the AST is the same ^^. I will check it out and see what I can find.
@ckimes89
maybe there is some quick fix that comes to your mind?
edit: ok, it seems swapping out the parser would require a lot of work, at least if you do not know how the f# parser really works (which is my case ;) ). So I tried once more to port the F# projects with the rest and I think this is possible, if you get rid of the pipes project. I actually do not know what the pipes do, but to me it seems like some syntactic sugar, that might be removable. But again, I do not know F# :/ The test projects are portable, as is the graphql.net project. I am just stuck on the f# stuff...
@MarianPalkus
I just read on the fsharp pipes project, that you are porting this to .net core? Is there something one might help?
I'd love this in dotnet core as well. I started a similar project ages ago as GraphQL was just coming out, I never fully supported the graphql standard although I want to. It does run on dotnet core though as that is what I use. I'd rather help make 1 library that supports the graphql spec and builds IQueryable expressions though.
@ckimes89 @MarianPalkus is this something you want help with? Happy to connect and talk more about it.
Well....
FYI: i could make it work with asp net core, take a look at #87 (comment)
cool, this seems promising. I will try and build it when I have som time to confirm it works. Maybe the owner can confirm this, too. Does not seem all to complicated.