akka.net
akka.net copied to clipboard
Implement cross-platform json serializer and spec
NOTE:
- Only merge this when there are requests from users for net framework - net core cross platform support.
- The serializer would have lower performance than the regular one.
Hi, we are potentially looking at doing this as we have certain back end services which will take 6 to 12 months to convert to .Net Core.
One question: when you say lower performance on the serializer, do you have any feel for how much of a performance hit we would be talking? Are we talking 10-20% hit or 80-90% hit?
We are also interested in a hybrid architecture consisting of some legacy systems on full framework, and new development with .NET Core.
I copy this serializer and it work for me. (Client .net 4.7.1 -> Cluster .net Core 2.0)
I have to Add a specific Identifier and replace the Preprocess condition "#if CORECLR" by a runtime check if i'm runing in .net core or .net classic.
For now the only solution i found to check if i run in .net core is :
/// <summary>
/// Gets the net core version.
/// </summary>
public static string GetNetCoreVersion()
{
var assembly = typeof(System.Runtime.GCSettings).GetTypeInfo().Assembly;
var assemblyPath = assembly.CodeBase.Split(new[] { '/', '\\' }, StringSplitOptions.RemoveEmptyEntries);
int netCoreAppIndex = Array.IndexOf(assemblyPath, "Microsoft.NETCore.App");
if (netCoreAppIndex > 0 && netCoreAppIndex < assemblyPath.Length - 2)
return assemblyPath[netCoreAppIndex + 1];
return null;
}
@notour would you like to send an updated PR with that code change? Appreciate the info!
We're looking for this capability also.
I made a pull request :
https://github.com/Arkatufus/akka.net/pull/2
I have an implementation for Hyperion to work across .Net Core to .NET Full framework. Currently it supports collections that switch between mscorlib to System.Private.CorLib as well as ExpandoObjects going from System.Dynamic to System.Linq.
https://github.com/leo12chandu/akka.net/blob/dev/src/core/Akka/Serialization/HyperionByteHelper.cs
Hello,
What is the current state of this?
We are (unfortunately) still having to target .NET Framework as the WPF on .NET Core will not be ready for us in time and have just hit this issue.
Regards JC
@john-cullen we should probably implement @leo12chandu's changes
@Aaronontheweb - I would be happy to branch out from akka.net master, implement it and create a pull request for you to review if it helps merge so others can use it. I've performance tested it 6 months back with reasonable size payloads and its does not add more than 10-20 milliseconds for our objects with over a 1000 properties per object.
Usage defined at https://github.com/akkadotnet/akka.net/issues/3587
Any developments?
We have a situation of a legacy .net framework app, new actors in .net core core...
and I was pleasantly surprised today to find there is some level of interoperability out of the box (it formed a cluster, an actor in .net core taking strings from actor in .net framework worked fine) but quickly hit deserialization problems,this PR would fix, e.g. "Error [Error resolving type specified in JSON 'System.Collections.Generic.List`1[[Shared.Messages.MergeOneString, Shared]], System.Private.CoreLib'."
@awostenberg I went with modifying the serialised text for now. I've not had any problems with it (but my app is still in testing / pre-release)
https://gist.github.com/john-cullen/c39d56efcb15e60b66cd4d05149316ed
@john-cullen you saved me. It took me 3 days of banging my head against why our system is just not working. Long and behold once we connected our WPF .NET framework clients they don't communicate messages with arrays in them (with cryptic dissociation errors). Once I discovered this thread I was concerned that this is going to be a showstopper for our effort to port our WCF to akka.net (months of effort), since our WPF apps can't be converted to .net core anytime soon. It would be really nice, going forward, to integrate @leo12chandu solution for planed 1.5 release when akka.net switches to Hyperion. Thanks.
@Arkatufus I know you're OOF, but maybe we should just merge this in - I can think of several support customers who are going to run into this as they execute their migrations off of .NET Framework this year.
Probably need a feature toggle for this.