是否有 HTTP 的替代方案来处理同一台计算机上的通信？答案

【问题标题】：Is there an alternative to HTTP for process to process communication on the same computer?是否有 HTTP 的替代方案来处理同一台计算机上的通信？
【发布时间】：2021-05-18 07:10:11
【问题描述】：

我们有一个 C# .NET Core 3.1 应用程序需要调用旧版 .NET Framework 32 位 DLL（我们没有源代码）。

我能想到的唯一方法是强制我们的整个应用程序仅针对 32 位，或者制作一个 Web 服务/微服务来包装第三方功能以使其通过 HTTP 可用。

但是我只是想知道对于这样的事情是否有任何 HTTP 替代方案，因为调用将是应用程序的本地调用，并且进程将始终位于同一台机器上。我假设没有办法“包装”32 位 DLL 并直接引用它，所以我猜两个进程通信是唯一的解决方案，但这必须是 HTTP 还是有其他方法？

编辑：

我要避免的主要事情是必须为这个 DLL 拥有一个单独的项目和 Web 主机带来的不便。

【问题讨论】：

也许这可以帮助你：stackoverflow.com/questions/359331/access-x86-com-from-x64-net
还有很多其他方法。数据库。文件系统。队列。插座。等等参见stackoverflow.com/questions/58549763/…。
@mjwills 是的，我查看了命名管道、套接字等，但我研究得越多，我认为如果没有办法只是“包装”DLL 以使其与 64 位兼容，那么 HTTP实际上比旧的/遗留方法更容易。
“当前”的解决方案是 gRPC 服务。它们基于 http/2，但不需要 iis。 Microsoft 在 .NET Core 中删除了远程处理（这是 .NET 的“原始”进程间通信方式）。 Microsoft 也从 .NET Core 中删除了 WCF。有一个 github 用 .NET 核心替代 WCF，但他们说它还没有生产就绪
一种可能的方法是让主应用程序启动主机应用程序并通过其标准与它通信IO 管道（stdin/stdout/stderr）。

标签： c# .net communication

【解决方案1】：

如果我理解正确，您希望在同一台机器上运行两个应该相互通信的进程。

第一个进程是你的 x64 进程，它是正常的，第二个 x86 迷你应用程序应该托管你的 3rd 方库并提供一些接口来访问这个库的方法。

恕我直言（今天）最简单的方法是设置一个运行 asp.core 并提供 REST API 的小控制台应用程序。但这只是真的，如果您的第 3 方主机应该是无状态的，在每次调用中获取所有需要的参数并且可以立即回答您的请求。

如果您需要在主机应用程序中配置一些本地状态（通过一些调用）和/或请求需要更多时间来回答（因为库只需要几分钟来计算结果），您也可以设计所有这些东西也与 REST。例如，长时间运行的请求会立即返回一个操作 ID，然后通过第二次 REST 调用，您可以请求处理的当前状态。

但这可能不再是真正的 REST。在那种情况下，named pipes 可能是一个更好的候选者，因为它是一个真正的双向通信。但请注意，您更接近金属，您必须注意沟通中断、消息不完整等。

【讨论】：