.NET 中的 IPC API 库

Question

我有用 .NET C# 编写的桌面应用程序 A1.exe，我想创建类似 A1API.dll 的东西，其他第三方应用程序可以使用它来与我的应用程序 A1.exe 进行进程间双向通信。

我已经有了一些基于 IPC Remoting 的 A1API.dll 原型。在 dll 中有 Client.cs MarshalByRefObject 类，它包含自己的线程，通过每秒检查一次来保持与 Server.cs MarshalByRefObject 类实例的连接。这种结构允许我的 A1.exe 应用程序通过自动重新连接所有客户端重新启动，这些客户端也在服务器中注册以侦听 A1.exe 事件。此外，如果任何客户端应用程序意外关闭，服务器会将其从其客户端集合中删除，因为即使调用方法 Client.Equals 也会开始引发错误。这个问题我用 ClientWrapper.cs 类解决了。

这一切都很好！

假设库 A1API.dll 将作为 API 发布到我的 A1.exe 应用程序的互联网上。

现在，我遇到了一个问题。如果我将来需要更改 A1API.dll 并扩展某些公共 Server.cs 方法中使用的一些枚举，该怎么办？在这种情况下，我应该使用字符串类型吗？

在枚举的场景中，我将扩展我的 A1.exe 和 A1API.dll，发布它，然后如果只重新安装 A1.exe，所有依赖于 A1API.dll 的客户端都会中断。

什么是整个事情的最佳解决方案？

我也会感谢任何改进/更改我的 IPC 解决方案的想法。谢谢。

Answer 1

答案取决于您希望向后兼容的程度。

您可以发布强命名程序集（即已签名）并在每次 API 更改时更改程序集版本，因此新程序集根本无法与旧程序集一起使用。此外，可以将强命名程序集放在 GAC 中，所以无论如何这是个好主意。

您可以让程序集未签名和/或未版本化，而是使用新的或修改的方法添加新的客户端类。因此，您将拥有 Client100、Client101、Client203 类。也许你可以玩继承，但我个人建议不要这样做。

第一种方法允许您标记新版本/行为更改，即使方法签名未更改。第二种方法是在不破坏源代码级别兼容性的情况下添加新功能并允许针对新版本编译旧代码的唯一方法。

我会说两者兼而有之。 GAC 中的强命名程序集，每次更改都会增加版本，并为新方法添加新类。