Cross-framework communication?

[bitwreckage]

Describe the bug

Our code base is evolving in a way where the part which acts as a client with regard to H.Ipc is built against .Net 8.0, while the part acting as server is on .Net Framework 4.8. This upgrade to .Net 8 on one side seems to affect the ability to send messages to the server, i.e. the client seems to go into a non-responsive state, and the server never seems to receive the message. The processes are able to connect (on the server side we get the ClientConnected event, but no messages. Any idea if this kind of "cross-framework" communication should be expected to work? Or what could be possible causes of this "lack of communication"?

Steps to reproduce the bug

1. Create a solution with three projects: Client, Protocol, and Server
2. Client should target .Net8.0, Protocol should target .NetStandard2.0, Server should target .Net Framework 4.8
3. Define message interface and implementations in Protocol project
4. Create Server code to handle messages in Server project
5. Create Client code to create and send messages in Client project
6. Run each of the Server and Client projects in separate terminal windows, and notice that Server never receives messages sent from Client.
7. Make Server project target .Net 8.0, build & run, and observe that messages are passed as expected.

Expected behavior

Ability to pass messages from a client targeting .Net 8 to a server targeting .Net Framework 4.8 - and vice versa.

Screenshots

No response

NuGet package version

H.Ipc 1.0.1

Platform

WPF, Console

IDE

Other

Additional context

No response

[HavenDV]

Yes, this problem has already arisen and I did not find a quick solution. Internally the library uses System.IO.Pipes.NamedPipeServerStream, and here different things are possible:

• .Net Framework and .Net 8 are binary incompatible and there is no way to fix it
• If we play with the settings, maybe we can make it compatible

But it requires time for testing/setting up the environment. If you can do it, I could implement it in the library. Or I am available on a paid basis on weekends with a rate of $50 (only for Open-Source projects)

Code: https://github.com/HavenDV/H.Pipes/blob/master/src/libs/H.Pipes/Factories/PipeServerFactory.cs https://github.com/HavenDV/H.Pipes/blob/master/src/libs/H.Pipes/Factories/PipeClientFactory.cs

[bitwreckage]

I looked a bit further into the pipes being set up for my client and server, respectively, as I noticed that there are some conditional formatter project/package references on the underlying H.Pipes project (depending on target framework). By default it seems that the pipe on my client (net8.0) uses MessagePackFormatter, while my server (net48) uses BinaryFormatter. I thought I would look into configuring the pipes to use the same type of formatter, if possible. But your response does not raise my hopes of success too much... 😄

[bitwreckage]

Update: In both client and server code I now supply an instance of MessagePackFormatter to the constructors of H.Pipes.PipeClient<T> and H.Pipes.PipeServer<T>, respectively. This seems to have fixed the issue. I can now send messages from client to server when client is .Net 8 and server is .Net Framework 4.8. Always a good thing for both sides of a conversation to use the same "language". 😄 It would probably be a usability improvement for the pipes to use the same formatter type across frameworks - but I of course also appreciate that there can be historical reasons for why this is not the case as of today.

[HavenDV]

Excellent! It's strange that I remembered that there was no solution here. Perhaps in that context they meant BinaryFormatter from both sides

[bitwreckage]

Yeah, I could easily imagine that a binary formatter could be incompatible across frameworks. Good thing that you made alternatives available here. 👍