Open thorgeirk11 opened 5 years ago
We never attempted to make unity work with the default SignalR client, especially not with IL2CPP. It's not on the list for .NET 6 and we're near the end. Unless it's a trivial fix, this won't be something that we work on for the upcoming release.
Finally I buy a plugin on asset store for call SignalR with Messagepack on IL2CPP. But you can use SignalR with Json without problem on IL2CPP.
@davidfowl we would highly appreciate you giving it a chance. @neuecc would you be willing to give them a hand?
This issue doesn't sound as a major effort. The heavy lifting has already been done the MessagePack Generator. Can you have someone investigate if this could be fixed in the coming release?
If there is a trivial fix, then someone could try it out by copying the MessagePackHubProtocol and worker, modify it with the fix, then try it out on the client.
class MyCustomHubProtocol : IHubProtocol
{
// modified from MessagePackHubProtocol
}
hubConnectionBuilder.Services.TryAddEnumerable(ServiceDescriptor.Singleton<IHubProtocol, MyCustomHubProtocol>());
We don't have any cycles during the last leg of .NET 6 to work on this.
We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.
We are also experiencing this issue as we try to build to Android in Unity IL2CPP
MessagePack hub protocol also fails for .NET 7 NativeAOT. Here I replaced the transport with named pipe which is covered by my xunit test. wegylexy/SignalRTunnel/.../src/Native/Native.cs#L100-L109 All managed test cases pass, and the native wrapper can start and stop the hub connection successfully. I haven't implemented invoke/send yet, but on fails. The event handler is never called back.
I guess the problem lies around here: dotnet/aspnetcore/.../src/Protocol/MessagePackHubProtocol.cs#L80-L113
I've got On()
to work.
Here I can copy raw bytes of encoded arguments to the On
handler: wegylexy/SignalRTunnel/.../src/Native/Protocol.cs#L65
Then here you can use your source-generated deserializers: wegylexy/SignalRTunnel/.../src/Native/Connection.cs#L103
In my case, I just pass it to native code and deserialize there with C++ macro-generated unpack functions. But I believe you can somehow invoke corresponding C# source-generated Deserialize<T>()
in managed code as well.
Next, I'll work on InvokeCoreAsync()
and SendCoreAsync()
.
After implementing native invoke and send, another issue appears: #37340
Boilerplate for quick fix:
switch
every custom type used in your project and invoke the generic variant with source generation.
Check out FlyByWireless.SignalRTunnel.Client.Native and wegylexy/SignalRTunnel/tree/native#nativeaot-usage.
Built-in types would work out-of-the-box. For custom types, you will need to configure your generated serializers.
Any update? MessagePack still not work on il2cpp
No update from my side
El El lun, 8 may 2023 a las 17:45, Lailore @.***> escribió:
Any update? MessagePack still not work on il2cpp
— Reply to this email directly, view it on GitHub https://github.com/dotnet/aspnetcore/issues/12102#issuecomment-1538615432, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMGSKOPZJ43AFYCWGMYKULXFEIJ7ANCNFSM4IBWGA4Q . You are receiving this because you were mentioned.Message ID: @.***>
for android : add this code to AndroidManifest.xml
<uses-permission android:name="android.permission.INTERNET" />
for ios : add this code to Info.plist
`
`
I am having a similar issue as #10080. I am using preview 6 of asp.net core SignalR client inside of unity and compiling with IL2CPP. I created a small git repo with the code I use to reproduce this issue
I am running into an exception when starting the connection:
The
connection.StartAsync
fails with the following exception:Unity's IL2CPP strips unused assemblies. It caused another issue but I fixed that by adding link.xml file. So the issue described here should not be affected by code stripping.
Here are the server and client traces.