Any plans to make this compile against .net core?

[feugen24]

I ask since there is asp.net rc, and this would allow to run it on linux/mac.

[louthy]

Wouldn't even know where to start. Any thoughts on the best approach?

[feugen24]

I asked because i saw dapper already ported, but i'll actually try it on rc2 since i don't think i'll have the time until then.
Good resource:
http://docs.asp.net/en/latest/dnx/projects.html

Also it might help to have vs2015 update 1, not sure but tooling might be improved.
http://blogs.msdn.com/b/webdev/archive/2015/11/18/announcing-asp-net-5-release-candidate-1.aspx

As for the process I assume you need to create a new project, add dependencies, copy files and build.
And transition should probably be done after the dependencies themselves are migrated(i just thought of this)
dotnet/reactive#148
dotnet/reactive#151

[louthy]

@feugen24 It turns out there's a portability checking tool

http://dotnet.readthedocs.org/en/latest/porting/supporting-core.html

• LanguageExt.Core is ready to go bar Rx. So I guess as soon as there's a .NET Core version of Rx then I can make the move too.
• LanguageExt.Process and LanguageExt.Process.Redis is also mainly blocked by Rx, and a few other minor issues like the use of CallContext, but they're fixable relatively easily.
• LanguageExt.Process.FSharp - ready to go
• LanguageExt.ProcessJS - ready to go

Thanks for the heads up and the links. I'll need to do a bit more reading to be sure I know what I'm doing here. I am surprised that the Process system is as close as it is to being portable, so if that can run cross-platform I'll be very happy.

[louthy]

@feugen24 - Ok, it looks like I have a dnxcore50 build that is all happy, even with Rx. I don't have the means to test it out at the moment. But if you open up the project.json in LanguageExt.Core then you should be able to build both dnxcore50 and dnx451 builds.

That really wasn't a fun process!

[louthy]

@feugen24 - Slowly getting through all of the projects. So far we have:

Project	dnx451	dnx461	dnxcore50	blockage
LanguageExt.Core	yes	yes	yes
LanguageExt.FSharp	yes	yes	yes
LanguageExt.Process	yes	yes	yes
LanguageExt.Process.Redis	yes	no	no	StackExchange.Redis
LanguageExt.ProcessJS	yes	yes	no	SignalR
LanguageExt.ProcessJS.Tests	yes	no	no	SignalR
LanguageExt.Tests	yes	no	no	Won't be unblocked until all the others are

• StackExchange.Redis are very close : Core 5 StackExchange/StackExchange.Redis#202
• SignalR - can't find any evidence of it working with dnxcore50, which seems odd! No packages resolve for Microsoft.AspNet.SignalR

The process continues!

[IanYates]

My understanding is that SignalR won't be a part of the original ASP.Net v5 release. I watch the SignalR v2.x repository on GitHub and, for the first time in what feels like a few months, there's finally some activity there from MS folk. So I guess they're getting back to regular ASP.Net maintenance and will then do SignalR v3 after the ASP.Net v5 release. It has its own repo but, IIRC, it's empty.

[louthy]

@IanYates Thanks for the info Ian. Do you have a link to where that was mentioned by any chance?

[IanYates]

It's listed as "future" here https://github.com/aspnet/Home/wiki/Roadmap#future-work - Q3 calendar year 2016. So I guess ~10 months away if all goes well.

[louthy]

@IanYates Thanks for the heads up, that's good to know.

[plouh]

How about ifdeffng out the Rx dependencies from UWP/.NetCore build for now? As far as I know, they are not very crucial part of the library compared to the overall usefulness, so until Rx people has gotten their libraries compiling, those could be removed.

It's only a couple of MatchAsync end delay -functions that we can easily live without, given that we wouldn't have Rx observables in .NetCore anyway.

[louthy]

@plouh - Rx isn't a blockage any more.

[BrainCrumbz]

@louthy is that because Rx have been ported somehow to CoreCLR? I was also checking Rx.NET issue 148 and could not figure out that.

Thanks

[louthy]

@BrainCrumbz It is available to include in DNX builds, so I believe it has been ported, yes. I've paused this migration until MS decide themselves what it is they're doing.

[masaeedu]

@louthy Haven't dug into the codebase, but what are you using SignalR for?

[louthy]

It's used for ProcessJS, which is a JavaScript actor-system that can talk
directly to the C# Process system via a SignalR hub.
On Thu, Jul 28, 2016 at 19:35 Asad Saeeduddin notifications@github.com
wrote:

@louthy https://github.com/louthy Haven't dug into the codebase, but
what are you using SignalR for?

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#70 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB5kkyfMBiBdd28bFI356euKREpI814aks5qaPZSgaJpZM4GsmFM
.

[masaeedu]

@louthy Given that the actor system stuff is in a different project, couldn't LanguageExt.Core and the associated nuget package be transitioned to .NET Core now?

[louthy]

@masaeedu It already is. As is the Process system. The only thing that isn't on
.NETCore is ProcessJS (which relies on SignalR)

On Wed, Oct 19, 2016 at 21:29 Asad Saeeduddin notifications@github.com
wrote:

@louthy https://github.com/louthy Given that the actor system stuff is
in a different project, couldn't LanguageExt.Core and the associated nuget
package be transitioned to .NET Core now?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#70 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB5kk0IJLanyMdCUiyXfla__tnebolhlks5q1n2UgaJpZM4GsmFM
.

[DamianReeves]

Any reason why .NET core support targets netframework1.6 instead of 1.3 for example?

[louthy]

I don't remember the exact reason, but I did try to get it running for 1.3, so something got in the way. I'm away from the project for a few days, I'll check later next week.

[louthy]

@DamianReeves Curiosity got the better of me. It seems whatever was blocking me using 1.3 before, now isn't (apart from on LanguageExt.FSharp, which only needs 1.4).

Anyway, I've deployed v1.9.5 of all the language-ext nuget packages which depends on netstandard13.

[DamianReeves]

Thanks for the quick turnaround on this.

[louthy]

All compatible with NET Standard 1.3. Closing.