New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Akka on .Net Core/PCL #992

Closed
ehaskins opened this Issue May 19, 2015 · 38 comments

Comments

Projects
None yet
@ehaskins

ehaskins commented May 19, 2015

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

This comment has been minimized.

Show comment
Hide comment
@Aaronontheweb

Aaronontheweb May 19, 2015

Member

@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.

Member

Aaronontheweb commented May 19, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@rogeralsing

rogeralsing May 19, 2015

Contributor

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

Contributor

rogeralsing commented May 19, 2015

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

This comment has been minimized.

Show comment
Hide comment
@nvivo

nvivo May 20, 2015

Contributor

.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.

Contributor

nvivo commented May 20, 2015

.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

This comment has been minimized.

Show comment
Hide comment
@adamhathcock

adamhathcock May 20, 2015

Contributor

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

Contributor

adamhathcock commented May 20, 2015

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

This comment has been minimized.

Show comment
Hide comment
@nvivo

nvivo May 21, 2015

Contributor

@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.

Contributor

nvivo commented May 21, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@adamhathcock

adamhathcock May 21, 2015

Contributor

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.

Contributor

adamhathcock commented May 21, 2015

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

This comment has been minimized.

Show comment
Hide comment
@rogeralsing

rogeralsing May 21, 2015

Contributor

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

Contributor

rogeralsing commented May 21, 2015

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

This comment has been minimized.

Show comment
Hide comment
@Aaronontheweb

Aaronontheweb May 21, 2015

Member

@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.

Member

Aaronontheweb commented May 21, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@ehaskins

ehaskins May 21, 2015

@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.

ehaskins commented May 21, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@adamhathcock

adamhathcock Jun 12, 2015

Contributor

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.

Contributor

adamhathcock commented Jun 12, 2015

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

This comment has been minimized.

Show comment
Hide comment
@rogeralsing

rogeralsing Jun 12, 2015

Contributor

@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.

Contributor

rogeralsing commented Jun 12, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@adamhathcock

adamhathcock Jun 12, 2015

Contributor

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.

Contributor

adamhathcock commented Jun 12, 2015

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

This comment has been minimized.

Show comment
Hide comment
@adamhathcock

adamhathcock Jun 12, 2015

Contributor

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 :)

Contributor

adamhathcock commented Jun 12, 2015

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 :)

@nvivo

This comment has been minimized.

Show comment
Hide comment
@nvivo

nvivo Jun 12, 2015

Contributor

Funny that AsyncLocal seems to be available from .net 4.5 (at least msdn says so) , and I didn't see it before.

I didn't look into it yet, but I wonder why @StephenCleary didn't mention it when we asked him about options to flow context. Is this new or is this also being deprecated? If this is available in plain old .NET, maybe it's an option for the current flow issues.

Contributor

nvivo commented Jun 12, 2015

Funny that AsyncLocal seems to be available from .net 4.5 (at least msdn says so) , and I didn't see it before.

I didn't look into it yet, but I wonder why @StephenCleary didn't mention it when we asked him about options to flow context. Is this new or is this also being deprecated? If this is available in plain old .NET, maybe it's an option for the current flow issues.

@StephenCleary

This comment has been minimized.

Show comment
Hide comment
@StephenCleary

StephenCleary Jun 12, 2015

AsyncLocal is coming in 4.6 (it's not in 4.5). It's essentially a wrapper around the logical call context.

StephenCleary commented Jun 12, 2015

AsyncLocal is coming in 4.6 (it's not in 4.5). It's essentially a wrapper around the logical call context.

@nvivo

This comment has been minimized.

Show comment
Hide comment
@nvivo

nvivo Jun 12, 2015

Contributor

Thanks for the clarification @StephenCleary.

Right, at MSDN (https://msdn.microsoft.com/en-us/library/dn906268(v=vs.110).aspx), the top of the page says both 4.5 and 4.6, but at the bottom it says only 4.6. That's why I was confused, only looked at the top.

Contributor

nvivo commented Jun 12, 2015

Thanks for the clarification @StephenCleary.

Right, at MSDN (https://msdn.microsoft.com/en-us/library/dn906268(v=vs.110).aspx), the top of the page says both 4.5 and 4.6, but at the bottom it says only 4.6. That's why I was confused, only looked at the top.

@adamhathcock

This comment has been minimized.

Show comment
Hide comment
@adamhathcock

adamhathcock Aug 15, 2015

Contributor

I've updated the DNX usage to beta6. I haven't attempted anything hard like Remote.

Targets are now .NET 4.5, DNX .NET 4.5.1 and DNX .NET CORE 5.0. Tests pass and the HelloWorld and FaultTolerance samples work.

Contributor

adamhathcock commented Aug 15, 2015

I've updated the DNX usage to beta6. I haven't attempted anything hard like Remote.

Targets are now .NET 4.5, DNX .NET 4.5.1 and DNX .NET CORE 5.0. Tests pass and the HelloWorld and FaultTolerance samples work.

@rogeralsing

This comment has been minimized.

Show comment
Hide comment
@rogeralsing

rogeralsing Aug 15, 2015

Contributor

Awesome! 👍

Contributor

rogeralsing commented Aug 15, 2015

Awesome! 👍

@adamhathcock

This comment has been minimized.

Show comment
Hide comment
@adamhathcock

adamhathcock Aug 15, 2015

Contributor

I'd like to keep this up. Have you guys considered moving to xproj? You can still target net 4.5 as well as dnx. The downsides are the you can't reference a xproj from a csproj (this will be fixed) nor build a non-dnx executable. Just DLLs.

I guess those are two big downsides currently :)

Contributor

adamhathcock commented Aug 15, 2015

I'd like to keep this up. Have you guys considered moving to xproj? You can still target net 4.5 as well as dnx. The downsides are the you can't reference a xproj from a csproj (this will be fixed) nor build a non-dnx executable. Just DLLs.

I guess those are two big downsides currently :)

@adamhathcock

This comment has been minimized.

Show comment
Hide comment
@adamhathcock

adamhathcock Sep 22, 2015

Contributor

Updated again to beta 7.

Need to get a Net Core version of Wire and Helios to really dive deeper.

Contributor

adamhathcock commented Sep 22, 2015

Updated again to beta 7.

Need to get a Net Core version of Wire and Helios to really dive deeper.

@adamhathcock

This comment has been minimized.

Show comment
Hide comment
@adamhathcock

adamhathcock Oct 7, 2015

Contributor

Another issue: Type.GetType() (e.g. used for loading a logging actor) only works for the current executing assembly. Need to redo this.

Hopefully #1263 is still on the cards (soon :) )

Contributor

adamhathcock commented Oct 7, 2015

Another issue: Type.GetType() (e.g. used for loading a logging actor) only works for the current executing assembly. Need to redo this.

Hopefully #1263 is still on the cards (soon :) )

@rogeralsing

This comment has been minimized.

Show comment
Hide comment
@rogeralsing

rogeralsing Oct 7, 2015

Contributor

@adamhathcock huh, Type.GetType does not accept fully qualified type names (that are not yet loaded)?

Contributor

rogeralsing commented Oct 7, 2015

@adamhathcock huh, Type.GetType does not accept fully qualified type names (that are not yet loaded)?

@adamhathcock

This comment has been minimized.

Show comment
Hide comment
@adamhathcock

adamhathcock Oct 7, 2015

Contributor

Under DNX, there aren't necessarily Assemblies and no AppDomains. From my understanding, the static Assembly methods only really works for the current project. Certain Assembly methods just don't work either. I'm guessing Type.GetType(string) under DNX only will find types in the current (or maybe just the entry) project.

To find all loaded types, usage of ILibraryManager (https://github.com/aspnet/dnx/blob/master/src/Microsoft.Dnx.Runtime.Abstractions/ILibraryManager.cs) is how you do it. Looks like they've abstracted the concept of Assemblies and Projects behind the Library object.

You can get it either dependency injected or statically use CallContextServiceLocator to get the IServiceProvider and get it.

Contributor

adamhathcock commented Oct 7, 2015

Under DNX, there aren't necessarily Assemblies and no AppDomains. From my understanding, the static Assembly methods only really works for the current project. Certain Assembly methods just don't work either. I'm guessing Type.GetType(string) under DNX only will find types in the current (or maybe just the entry) project.

To find all loaded types, usage of ILibraryManager (https://github.com/aspnet/dnx/blob/master/src/Microsoft.Dnx.Runtime.Abstractions/ILibraryManager.cs) is how you do it. Looks like they've abstracted the concept of Assemblies and Projects behind the Library object.

You can get it either dependency injected or statically use CallContextServiceLocator to get the IServiceProvider and get it.

@nvivo

This comment has been minimized.

Show comment
Hide comment
@nvivo

nvivo Oct 7, 2015

Contributor

2 cents here...

I remember seeing some explanation on a community standup about this. It seems the task of locating assemblies was moved out of the runtime into DNX, because it may need to locate a package in another folder or compile from source. In the end, assemblies still exist at runtime, but the runtime acts more as "read only". Type.GetType probably sees whatever was passed by DNX, but doesn't cause anything to load if it isn't.

If needed, it seems there is a way to load assemblies later, but as a explicit call, so in theory the behavior could be replicated. I couldn't figure out if this is the expected way to do it or how exactly to call it. Maybe stackoverflow or an issue on their repo could answer the proper way to do this.

Contributor

nvivo commented Oct 7, 2015

2 cents here...

I remember seeing some explanation on a community standup about this. It seems the task of locating assemblies was moved out of the runtime into DNX, because it may need to locate a package in another folder or compile from source. In the end, assemblies still exist at runtime, but the runtime acts more as "read only". Type.GetType probably sees whatever was passed by DNX, but doesn't cause anything to load if it isn't.

If needed, it seems there is a way to load assemblies later, but as a explicit call, so in theory the behavior could be replicated. I couldn't figure out if this is the expected way to do it or how exactly to call it. Maybe stackoverflow or an issue on their repo could answer the proper way to do this.

@adamhathcock

This comment has been minimized.

Show comment
Hide comment
@adamhathcock

adamhathcock Oct 7, 2015

Contributor

The logger I tested definitely was in an assembly that was used. It just wasn't in the entry assembly. Type.GetType didn't work for anything in that assembly (in my watch window) but it did for the entry assembly. I stopped there knowing several of the Assembly.Get* methods (Entry, Executing) don't work but GetCurrent does work.

I guess I need to test it further. In my own code, I don't load types or assemblies except from ILibraryManager because of things I've run into. Maybe it will be more clear when they start documenting :)

Contributor

adamhathcock commented Oct 7, 2015

The logger I tested definitely was in an assembly that was used. It just wasn't in the entry assembly. Type.GetType didn't work for anything in that assembly (in my watch window) but it did for the entry assembly. I stopped there knowing several of the Assembly.Get* methods (Entry, Executing) don't work but GetCurrent does work.

I guess I need to test it further. In my own code, I don't load types or assemblies except from ILibraryManager because of things I've run into. Maybe it will be more clear when they start documenting :)

@nvivo

This comment has been minimized.

Show comment
Hide comment
@nvivo

nvivo Oct 7, 2015

Contributor

If you're adding a logger as usual, putting the assembly side by side in the same folder, it won't be loaded automatically by .NET. Only explicit dependencies are loaded, that is, the ones the compiler adds to the IL manifest. If I'm not mistaken (may be wrong here), even today, csc filters out from the manifest references you have but don't actually use.

So, DNX won't load them automatically just because they're in the same folder.

See if this custom loader helps: aspnet/dnx#1412

Contributor

nvivo commented Oct 7, 2015

If you're adding a logger as usual, putting the assembly side by side in the same folder, it won't be loaded automatically by .NET. Only explicit dependencies are loaded, that is, the ones the compiler adds to the IL manifest. If I'm not mistaken (may be wrong here), even today, csc filters out from the manifest references you have but don't actually use.

So, DNX won't load them automatically just because they're in the same folder.

See if this custom loader helps: aspnet/dnx#1412

@adamhathcock

This comment has been minimized.

Show comment
Hide comment
@adamhathcock

adamhathcock Oct 7, 2015

Contributor

This is an explicit dependency. The second assembly has code being used by the entry assembly. It ought to show in ILibraryManager but Type.GetType didn't work.

I'll do some more explicit testing tomorrow my time and get back to you.

Contributor

adamhathcock commented Oct 7, 2015

This is an explicit dependency. The second assembly has code being used by the entry assembly. It ought to show in ILibraryManager but Type.GetType didn't work.

I'll do some more explicit testing tomorrow my time and get back to you.

@adamhathcock

This comment has been minimized.

Show comment
Hide comment
@adamhathcock

adamhathcock Oct 8, 2015

Contributor

I did a test repo: https://github.com/adamhathcock/dnx-test/blob/master/src/ConsoleApp1/Program.cs

Type.GetType doesn't work. If I get the Assembly object, Assembly.GetType doesn't work. If I do Assembly.GetTypes then the type is in the list.

Contributor

adamhathcock commented Oct 8, 2015

I did a test repo: https://github.com/adamhathcock/dnx-test/blob/master/src/ConsoleApp1/Program.cs

Type.GetType doesn't work. If I get the Assembly object, Assembly.GetType doesn't work. If I do Assembly.GetTypes then the type is in the list.

@adamhathcock

This comment has been minimized.

Show comment
Hide comment
@adamhathcock

adamhathcock Oct 8, 2015

Contributor

Just realized I did something dumb. Assembly.GetType(string) does work. Type.GetType(string) doesn't

Contributor

adamhathcock commented Oct 8, 2015

Just realized I did something dumb. Assembly.GetType(string) does work. Type.GetType(string) doesn't

@ronnyek

This comment has been minimized.

Show comment
Hide comment
@ronnyek

ronnyek Nov 25, 2015

Now that api's are stabilizing with recent rc1 release, has anyone played with this any more? I'm very interested to see how much of akka is gonna run on core clr. I can run monoruntime for now, but I'd really be interested in real coreclr support.

ronnyek commented Nov 25, 2015

Now that api's are stabilizing with recent rc1 release, has anyone played with this any more? I'm very interested to see how much of akka is gonna run on core clr. I can run monoruntime for now, but I'd really be interested in real coreclr support.

@Aaronontheweb

This comment has been minimized.

Show comment
Hide comment
@Aaronontheweb

Aaronontheweb Nov 25, 2015

Member

Since there's still a lot of healthy discussion on here, going to re-open this up as part of an ongoing conversation

Member

Aaronontheweb commented Nov 25, 2015

Since there's still a lot of healthy discussion on here, going to re-open this up as part of an ongoing conversation

@Aaronontheweb Aaronontheweb reopened this Nov 25, 2015

@adamhathcock

This comment has been minimized.

Show comment
Hide comment
@adamhathcock

adamhathcock Nov 25, 2015

Contributor

Just updated my branch again to RC1 and latest Dev: https://github.com/akkadotnet/akka.net/compare/dev...adamhathcock:coreclr?expand=1

Everything seems fine. I haven't addressed the logging thing but I know Type.GetType() works now. I'd like to use Wire but that's not NETCore'd yet. I haven't attempted to target any of the "standard" targets introduced in RC1 (and will change names in RC2)

Just a screenshot to show what I've ported. I'd like to contribute to an official branch.

image

Contributor

adamhathcock commented Nov 25, 2015

Just updated my branch again to RC1 and latest Dev: https://github.com/akkadotnet/akka.net/compare/dev...adamhathcock:coreclr?expand=1

Everything seems fine. I haven't addressed the logging thing but I know Type.GetType() works now. I'd like to use Wire but that's not NETCore'd yet. I haven't attempted to target any of the "standard" targets introduced in RC1 (and will change names in RC2)

Just a screenshot to show what I've ported. I'd like to contribute to an official branch.

image

@adamhathcock

This comment has been minimized.

Show comment
Hide comment
@adamhathcock

adamhathcock Jan 9, 2016

Contributor

Now just updating against master: https://github.com/akkadotnet/akka.net/compare/master...adamhathcock:coreclr?expand=1

I want to do Akka.Remote but it will involve understanding Google.ProtocolBuffers and the new version Google.Protobuf (which is 3.0 beta and supports NET Core) but that seems daunting to me at the moment.

Contributor

adamhathcock commented Jan 9, 2016

Now just updating against master: https://github.com/akkadotnet/akka.net/compare/master...adamhathcock:coreclr?expand=1

I want to do Akka.Remote but it will involve understanding Google.ProtocolBuffers and the new version Google.Protobuf (which is 3.0 beta and supports NET Core) but that seems daunting to me at the moment.

@goodisontoffee

This comment has been minimized.

Show comment
Hide comment
@goodisontoffee

goodisontoffee Feb 16, 2016

I would also be extremely interested in this being a possibility.

goodisontoffee commented Feb 16, 2016

I would also be extremely interested in this being a possibility.

@adamhathcock

This comment has been minimized.

Show comment
Hide comment
@adamhathcock

adamhathcock Mar 8, 2016

Contributor

Updated my branch to 1.0.6 with some minor fixes.

Working on building this internal to my company to use on .NET Core on some projects we've got.

Contributor

adamhathcock commented Mar 8, 2016

Updated my branch to 1.0.6 with some minor fixes.

Working on building this internal to my company to use on .NET Core on some projects we've got.

@Neftedollar

This comment has been minimized.

Show comment
Hide comment
@Neftedollar

Neftedollar commented Mar 8, 2016

@adamhathcock thank you, Adam.

@lnaie

This comment has been minimized.

Show comment
Hide comment
@lnaie

lnaie Apr 24, 2016

Actually it would be great to have something as akka fully or partially ready when dotnet core goes live.

lnaie commented Apr 24, 2016

Actually it would be great to have something as akka fully or partially ready when dotnet core goes live.

@marcpiechura

This comment has been minimized.

Show comment
Hide comment
@marcpiechura

marcpiechura Jul 18, 2016

Contributor

Working on it, see #2153

Contributor

marcpiechura commented Jul 18, 2016

Working on it, see #2153

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment