我正在开发一个应用程序，我需要使用供应商库与外部硬件进行通信。该库面向 .NET Framework 3.5。该库的 .NET 标准 2.0 版本已计划推出，但我认为它不会很快推出。不过，我想在现代 .NET 版本（如 7 或即将推出的 8）中开发我的应用程序。显然，我无法直接从 .NET 7/8 访问 .NET Framework 库。所以我的想法是创建一个单独的 .NET Framework 进程并使用某种形式的 IPC 与其进行通信。两个程序集将在同一台机器上运行。
我的第一个想法是使用 gRPC，但我不确定 gRPC 是否可以在 .NET Framework 中用作服务器。 .NET Framework 方面的事情需要被调用，但也需要在收到来自外部硬件的消息时回调。这就是为什么我认为我需要 .NET Framework 中的 gRPC 服务器功能。另外，对于 gRPC，我需要将库抽象为简单的函数调用。
我的第二个想法是为 .NET Framework 库对象提供包装器，并让 .NET 应用程序使用存根访问此包装器。这就像 SOAP 协议。但我从来不需要在 .NET 中做这样的事情。在寻找解决方案时，偶然发现了 .NET Remoting 和 WCF。据我了解，WCF 优于 .NET Remoting，因此 WCF 可能是最佳选择。 WCF 的 CoreWCF 实现允许 .NET Core 和较新的 .NET 应用程序使用 WCF。但是我听说这不应该在新项目中使用。
我的问题的要点是如何以最无缝的方式在 .NET 7/8 中使用 .NET Framework 库？我真的需要求助于 IPC 还是有其他我缺少的方法？如果确实需要 IPC，那么在我的情况下我应该使用什么？任何通过命名管道之类的通信都会很有趣，但如果我实际上能够包装库对象并通过 .NET 7/8 进程中的存根使它们可用，那就完美了。
除此之外，我还有什么选择来实际产生第二个进程？我发现有一种叫做应用程序域的东西，但我认为这在我的情况下是不可能的。正常的 CreateProcess API 存在，但我想知道是否有更好的方法，因为另一个进程本质上是我的应用程序的一部分并且仅由它使用。
我希望我没有在这里问不可能的事情。
第一步就是尝试使用它。只要 .Net 框架库不使用任何已删除的功能，加载它们就可以工作。但没有任何保证。
我的下一步是尝试 gRPC。主要库针对 .net standard 2.0，因此在 .net Framework 4.6.1+ 中应该可以正常工作。并且 .net Framework 4.x 可以可能加载您的 3.5 库。我可能还建议尝试 MQTT，它并不是真正为点对点使用而设计的，但我发现它相当容易上手，并且可能会工作得很好。
我的理解是，.Net Remoting 类不再受支持，因此您可能希望避免这种情况。我认为 WCF 也在 .net core 中被删除，但有一个“CoreWCF”社区项目，所以这可能会起作用。
但是支持 .net 3.5 的维护库很少，因此无论您选择哪种特定协议和库，您都可能希望使用 .net Framework 4.5+。并且有大量协议和库可供选择。