I'm looking forward to use protobuf-net in conjunction with named pipes for communicating with legacy systems (WinXP 32-bit, NetFramework 4.0.3). Happily there is at least version 2.4.6 available for Net Framework 4.0. The readme.md in the latest version states that net20 / net35 can be targeted but is not supported greatly. Furthermore the info-page states that Net 4.6.1+ is required and in the project-configuration we find that at least netstandard2.0 must be targeted.
Is there any (painless) chance to compile later versions of protobuf-net for Net Framework 4.0 ? It seems there must be substitutions for "System.Buffers" and "System.Memory", which is likely to be a lot of work.
Furthermore from the source-code we can see that using protobuf-net with named pipes is still considered to be "experimental". Can there any statements be made how far this is from stable ? I would like to use protobuf-net in a productive environment like shown in IPC using Protobuf, which is quite elegant solution to me.
protobuf-net v2 includes down-level targets for net20 and net35; protobuf-net v3 does not. For an in-depth discussion of why, please see this blog post. Could v3 hypothetically build against v2? Possibly, with suitable amounts of effort. The blog post discusses that in much more detail, though.
The readme.md in the latest version states that net20 / net35 can be targeted
Please can you provide me with a link to that, so I can get that clarified. I've checked, and I can't see that statement.
Furthermore from the source-code we can see that using protobuf-net with named pipes is still considered to be "experimental". Can there any statements be made how far this is from stable ?
The experimental named pipe basic RPC layer is entirely that: experimental; it is not considered stable, and I'll probably kill it in favour of gRPC (see also: protobuf-net.Grpc) unless I have significant reasons to add more effort. In particular, Microsoft are investing some effort into making in-process gRPC work, so it may be more pragmatic to just combine with those efforts. However! That is likely to be limited to .NET 5 (or possibly later), which doesn't help you if you're targeting .NET Framework 2.0.
Ultimately: I hate to break this to you, but: the old versions of .NET Framework are long since retired. Most library authors - and especially authors of free libraries - are unlikely to invest the significant effort required to properly support them.