I am working on an application where I need to use a vendor library for communication with external hardware. This library targets .NET Framework 3.5. A .NET standard 2.0 version of the library is planned but I don't think it will be coming any time soon. However I would like to develop my app in modern .NET versions like 7 or soon 8. Obviously I can't access a .NET Framework library from .NET 7/8 directly. So my idea was to create a separate .NET Framework process and communicate with it using some form of IPC. Both Assemblies would run on the same machine.
My first thought was to use gRPC but I am not sure if gRPC is available in .NET Framework as a server. The .NET Framework side of things would need to be called but also would need to call back when a message from the external Hardware was received. This is why I think I would need gRPC server capabilities in .NET Framework. Additionally with gRPC I would need to abstract the library to simple function calls.
My second idea was to provide wrappers for the .NET Framework library objects and let the .NET app access this wrapper using a stub. This would be like the SOAP protocol. But I never had to do anything like this in .NET. While looking for a solution a stumbled upon .NET Remoting and WCF. From what I understand WCF is superior to .NET Remoting so WCF might be the way to go. There is the CoreWCF implementation of WCF to allow .NET Core and newer .NET apps use WCF. However I heard that this should not be used in new projects.
The gist of my question is how do I use the .NET Framework library in .NET 7/8 in the most seamless way possible? Do I really need to resort to IPC or is there another way that I am missing? If IPC is indeed necessary what should I use in my situation? Any communication over something like named pipes would be interesting but if I would actually be able to wrap the library objects and make them available via stubs in the .NET 7/8 Process would be perfect.
Other than that what are my options to actually spawn the second process? I have found there was something called app domains but I think this is not possible in my situation. The normal CreateProcess API exists but I wonder if there is any better way given that the other process would essentially be a part of my application and only used by it.
I hope I am not asking the impossible here.
The first step would be to just try to use it. Loading .Net framework libraries can work as long as they are not using any removed features. There are no guarantees however.
My guess is that your library is a fairly thin wrapper around a native library, so chances are good that it have no significant .net dependencies to worry about.
My next step would be to attempt gRPC. The main libraries target .net standard 2.0, so should work just fine in .net framework 4.6.1+. And .net framework 4.x can probably load your 3.5 library. I might also suggest trying MQTT, it is not really designed for point-to-point usage, but I found it fairly easy to get started, and will probably work well enough.
My understanding is that the classing .Net Remoting is no longer supported, so you probably want to avoid that. I think WCF was also removed in .net core, but there is a "CoreWCF" community project, so that could probably work.
But there are few maintained libraries with .net 3.5 support, so you will likely want to use .net framework 4.5+ regardless of the specific protocol and library you pick. And there is plenty of protocols and libraries to chose from.