Support for .NET Core

[zeljkobajsanski]

Hi,
is there any support for .net core? We are migrating existing solution to ASP.NET 5? Our requirement is to host application on other OS than Windows

[cskardon]

Hi,
At the moment, no, time-wise I'm a little constrained to do it, but if you want to go for a Pull request with it in, it would be greatly received!! :)

[tugberkugurlu]

Is anyone looking into this? I would be willing to give this a start but wanted to check first not to duplicate the same work.

[cskardon]

Hey @tugberkugurlu, I'm not actively looking into this at the moment, feel free to go for it, and if there is anything I can do to help let me know!

[tugberkugurlu]

@cskardon great, I will give it a go and open a PR as soon as I have something viable.

[cskardon]

PS issue #120 is the same... So I can close this one and leave the other, or vice versus, whichever you'd like!

[cskardon]

@tugberkugurlu That is Amazeballs thank you!

[tugberkugurlu]

This one seems better (judging from the title 😄) because what needs to be done here is to support dotnet5.4 and net45 (if they will not change this again, sigh!), not dnxcore50. So, it will make it possible to reference this from a project which targets dotent5.4, dnxcore50, dnx451, net45 or above.

[cskardon]

10-4 - I'll close the other one pointing to this...

[JakeGinnivan]

I recently added support for .net core to Shouldly, I suggest you don't use the DNX tooling to actually do this, unless you don't want to run tests against .net 4.5 and only run your tests against dnx using the dnx runner.

Instead create a Portable class library (profile 259) and use a Shared Project to share the code between the full .net projects and the pcl library. This way you can create .net 45 and dnx test projects to verify things work on both platforms. You then use https://github.com/onovotny/ReferenceGenerator and hook it into your PCL library to update the nuspec with the dnx references, then copy the pcl dlls into lib/dotnet in your nuget package.

shouldly/shouldly#341 and shouldly/shouldly#346 are the PR's which implemented this change.

Hope that helps.

[tugberkugurlu]

I started here: https://github.com/tugberkugurlu/Neo4jClient/tree/dotnet-core Will open a PR when it reaches a stable{ish} state to discuss/review/comment/etc.

[amcdnl]

Any ETA on this?

[brantw]

+1

[dracan]

Another +1 :) Neo4j is the only library now stopping me from moving to ASP.NET Core and utilising Docker in my application. Looking at #140, it looks like there's a lot of work involved! Such a shame that so much work is required just to move libraries to the next version of .NET and be xplat :-/ Great work so far @tugberkugurlu and @cskardon!! Do you think it might be quite a while before it's ready? I'm trying to make a decision of which way to go with my project - eg. switch to REST API for Neo4j; or stay with not using Docker for this bit of my app, and wait for Neo4jClient to support .NET Core. If it's around the corner, then I'll wait - otherwise I'll probably have to switch to the REST API unfortunately.

Thanks in advance.

[tugberkugurlu]

@dracan there are a few missing stuff which seems like @cskardon is happy for it to re-implemented in a manual fashion or work around it in any other cases. These are the remaining things: #140 (comment)

Also, RC2 is a drastic change (and can even be considered as the new beta1). So, any work that will be done should be on rc2 stuff.

[cskardon]

I don't want to sideline this ticket particularly, but I've been playing with a spike where I've done as @JakeGinnivan suggested and created a PCL - this leaves the TX stuff in place for full users - and (admittedly - this is the poo bit) removes it from the Core CLR version - but would give a quicker time to get a core version out.

I agree with the RC2 wait - and that's the main thing preventing me from trying out a proper core solution.

PCL Version

On the positive there is minimal change to the code, in essence aside from converting a few Reflection class uses, the code is the same. The 'Full-fat' version still has the TX code, and the core version can have it added in, with a view to maybe joining the two implementations together later on. This minimises changes for existing users, and mitigates conversion risks. Some people utilise the TransactionScope benefits across MSTDC and this allows them to continue to do so.

On the negative - Tx implementation for core would not be there - this is because TransactionScope does not exist in core. So core = no MSTDC. The other major negative for me is wasted time (in particular yours @tugberkugurlu ) and that sucks hugely, it's never been my intention to do so.

Core Version

This gets around the headache of maintaining two (albeit small) separate projects. The code would be consistent and all subsequent changes would be core compatible.

But we would lose the TransactionScope support - due to this the Tx code would have to be re-written, and that's quite a big task in and of itself. In practical terms - this needs to be done for the PCL version as well - but not straight away.

We could end up having a 1.1x version which maintains the full version + bug fixes and a 2.x version which is core, and I'm not sure what is easier to manage, though I would probably go the PCL route as it can all be in one solution.

So - here's the thing - I'm not totally up to speed with the core stuff, so I can't say if either way is better or worse from that POV, but I'd like to get there sooner rather than later as I want to put the Neo4j 3.0 Bolt code in, and that's a big change that merge wise seems impractical to do before core is done.

Any thoughts would be gratefully received, and apologies to anyone (well @tugberkugurlu) :/

[tugberkugurlu]

The other major negative for me is wasted time (in particular yours @tugberkugurlu ) and that sucks hugely, it's never been my intention to do so.

Don't worry about it at all. Whatever works best here is all OK for me. I just wantted to kick start this as early as possible and pull request was helpful to visualize. So, all OK for me for this to be taken to any direction as you see fit 👍

So - here's the thing - I'm not totally up to speed with the core stuff, so I can't say if either way is better or worse from that POV, but I'd like to get there sooner rather than later as I want to put the Neo4j 3.0 Bolt code in, and that's a big change that merge wise seems impractical to do before core is done.

I would say next milestone would be a better start. It's still not certain it will not change but I suspect there will be a lot more changes. The good side of getting a early start and pushing a pre-release would give people a chance to test it out in the wild and have a more stable release when everything hits prod.

Neo4j Bolt library also doesn't support .NET Core today but they are planning to get there: neo4j/neo4j-dotnet-driver#52

[amcdnl]

@tugberkugurlu I spoke w/ their team on phone, they said 3.1 timeframe is when we could expect core support.

@cskardon don't know if you've seen this article regarding current state of affairs on rc2 - https://blogs.msdn.microsoft.com/dotnet/2016/05/06/net-core-rc2-improvements-schedule-and-roadmap/

[cskardon]

Please give it a whirl -> I fully expect there to be issues - it's pre-release after all.
TX DOES NOT WORK IN CORE

https://www.myget.org/feed/neo4jclient-tx/package/nuget/Neo4jClient

V3 Feed: https://www.myget.org/F/neo4jclient-tx/api/v3/index.json
V2 Feed: https://www.myget.org/F/neo4jclient-tx/api/v2

[TheRubble]

@cskardon Hi just trying that new Core library, where is the source that's backing it? I'd be more than happy to patch up things as I find them.

[cskardon]

@TheRubble I'll shift the source into this repo shortly - probably tomorrow or thursday (remind me if I have forgotten) - I've just moved house - currently awaiting BT to actually get me connected to the internet.

[cskardon]

@TheRubble I sneaked some WiFi - have a look at: https://github.com/Readify/Neo4jClient/tree/DotNetCore

[TheRubble]

@cskardon Love it 👍 Sneaky Wifi

[cskardon]

Just pushed core3 update to the myget - this is using the RTM versions of the core codebase, I've left Neo4jClient as pre-release for now.

[cskardon]

So.
I'm holding off on going rtm with the core version as I was planning to put transactions in.
The unfortunate thing is that core doesn't support System.Transactions and Neo4jClient currently uses that for it's Tx management.

Recently (today-ish) the core team have started to look into getting System.Transactions into core for 1.1 (see https://github.com/dotnet/corefx/issues/2949).

This leads to 2 options in my view -

1. Redo the Tx code for Core now
2. Wait and see if core 1.1 will work with the current Tx code.

Both have risks - doing (1) means potential errors introduced and potentially managing two tx frameworks for a while. (2) means no Tx support for the core version for a while, and potentially having to do (1) later on down the road regardless.

I'm leaning towards (2) at the moment, as whilst I personally don't use DTC - I assume some people do - and I don't want to pull the rug on those and limit them to 1.1.x versions only.

Any thoughts on this would be greatly received.

PS. If anyone has tried / is using the core version in a project, feedback on it's general workiness would be great!

[TheRubble]

@cskardon
Hi,
I'm currently using this in a project and have had absolutely zero issues so far. I think it's a upfront decision that transactions aren't supported and therefore solutions can be designed with this constraint in mind.

Once this functionality is available I'll refactor the project.

Thanks for all your work really appreciated made my life easier.

[cskardon]

Hallo!
I'm going to close this now, as the Core version (2.0.0) is on Nuget - remember - no transactions in core.

I've opened issue #199 to cover that when Core 1.1 is available.

[rliberoff]

When can we expect to have transactions support when working with .NET Core (2.0)?

[cskardon]

@rliberoff Please only comment on one issue at a time. This issue was closed with reference to another issue (#199) which you have already commented on.