Akka on .Net Core/PCL

[ehaskins]

I'm interested in running Akka.net on .Net Core in ASP.net vNext. That currently isn't supported, but it doesn't look like it'd be insurmountable to make Akka's core a PCL.

• Using System.Configuration - Could this be extracted into a separate library?
• Using IClonable - Some precompiler statements should resolve that
• Using System.Runtime.Serialization namespace
• Using System.Runtime.Remoting namespace

I've only spent about an hour looking at this, so I'm probably missing something harder, but has anyone given this more serious thought or consideration?

[Aaronontheweb]

@ehaskins I haven't given this much thought - this is the second or third time it's come up though.

Using System.Configuration - Could this be extracted into a separate library?

What we really use this for is automatically loading Akka.NET configuration automatically from App.config / Web.config. Removing this into its own separate library would be a major breaking change to today's API. Everyone's apps would still "run," but without their configuration - it's actually the worse kind of breaking change: the "fails at runtime" type.

As for the other stuff, I'm sure we could refactor our usage of ICloneable and I'm not sure if we even need those other two namespaces.

[rogeralsing]

System.Runtime.Serialization is used in our exception types, they have ctors using SerializationInfo
System.Runtime.Remoting is used in the async await task scheduler

ICloneable could probably be removed, only Address uses it

[nvivo]

.NET Core needs to be considered a new "target" for compilation, and this will require some changes. If you look into the CoreFx repo, there is a lot of "#ifdefs" to compile things differently for .NET Core vs .NET. It's a similar but different API.

• System.Configuration - won't be required as .NET Core can load hocon files directly with an "UseHoconConfig()" extension
• System.Runtime.Remoting - I doubt this will be a requirement from CallContext on .NET Core, it may simply not be a dependency there

Most things can be solved by "ifdefs". But .NET Core is probably a year away, and doing this at this time in the "dev" branch is very uncertain. They said they are still deciding if more libraries will be ported.

Someone could try on a personal branch to see what would take.

[adamhathcock]

Is there a feature branch started? I'd like to look at it and help as this is of interest to me as well.

[nvivo]

@adamhathcock

I don't think there is a branch for that yet, otherwise @Aaronontheweb would have mentioned it. Right now, the best thing for you is to fork and create your own experimental branch to see where it goes.

Once you have something, create a PR for analysis. Since this is a new target, I guess it will take time and lots of feedback before it gets merged. But it needs to start somewhere.

[adamhathcock]

I guess I was hoping @ehaskins had one or something. I wouldn't be sure what to do about the multi-project setup as VS2015 has xproj now for targetting .NET Core.

I just haven't done enough reading about best practices for all the next gen project setup. I got something attempting builds but it felt ugly.

[rogeralsing]

We discussed this yesterday and we in the core team is not going to involve ourselves in this_right now_, as this is not where our main user base is focused and the effort will distract us from finishing more important tasks.

That being said, if anyone is willing to give this a try, please do so

[Aaronontheweb]

@rogeralsing beat me to the punch!

One day in the future, this might make a lot of sense for our users - but that's not where they are today. Hell, judging from the volume of "do you support .NET 4.0?" questions we get we're still considered to be bleeding edge in some circles by being .NET 4.5-only.

That being said, I would love to see a prototype of this in someone's fork as I'm personally interested in using it myself.

[ehaskins]

@adamhathcock @adamhathcock All I've done so far, is convert the Akka project to a PCL to see how many compile errors I'd get. Feel free to take a look at it in the PCL branch of my fork. I hadn't decided if I'll have the time to tackle this.

[adamhathcock]

I've made my own branch and I got HelloAkka to work:
https://github.com/akkadotnet/akka.net/compare/dev...adamhathcock:coreclr?expand=1

.NET Core is still very much in flux but we're trying to use it anyway. I've used a pre-beta6 to get some more of the reflection classes in. VS 2015 RC defaults to beta4.

I'd like people just to glance at some of the things I had to do just to see if there might be something better or different. I think the most questionable thing is the removal of CallContext as I really didn't know what to do there besides try ThreadStatic.

[rogeralsing]

@adamhathcock awesome! :)

Regarding CallContext, that one is tricky, the current design of the Akka.NET API will not be able to do async await support inside actors w/o the call context, so that would have to be removed in the PCL version.

[adamhathcock]

Finally figured out how to execute unit tests. I'll think I'll leave it at there for now and wait for more beta milestones.

Hopefully, the CallContext thing is just not exposed yet. From my understanding, it's needed to move static state along with async/await and I don't know any other mechanism that would work.

[adamhathcock]

By happenstance, I literally found in the answer just after typing my last comment. AsyncLocal in DNX replaces CallContext. Just updated the branch.

Okay, really trying not to overwhelm the discussion here :)