只是为了得到开箱即用的时刻,你有没有想过使用WCF与MSMQ?我不确定我是否完全理解你是体系结构,但听起来像API的客户端需要启动另一个承载API的进程。在启动API主机和客户端尝试拨打电话之间可能存在计时问题。微软最近弃用.NET Remoting(以及其他以前的通信技术,如ASMX Web服务)作为传统,并强烈建议开发人员转向WCF平台。
如果您在MSMQ中使用WCF,您应该没有时间问题。无论API主机是否正在运行,您的客户端应用程序都可以将消息放入持久队列中。 API主机可以在任何时候启动,并且会接收并处理队列中等待的任何消息。即使您仍然有客户端应用程序启动API主机,计时问题也不再是一个问题,因为您使用排队传输消息而不是.NET Remoting。 WCF围绕MSMQ提供了一个很好的,方便的,易于使用的包装,因此进入的门槛相对较低。
在.NET Remoting上使用WCF的另一个优点是,您可以轻松地将API主机移动到不同的物理服务器,而无需更改客户端应用程序。如果您愿意,您甚至可以移动到不同的排队平台(例如AMQP上的RabbitMQ),而无需更改客户端或API主机应用程序。 WCF为您处理所有这些交互操作,为您的客户端应用程序和API主机提供更加干净的解耦和更可靠的通信。
如果移动到WCF不是一个选项,您应该能够使用.NET Remoting显式设置端口。我不知道你如何配置你的API的主机,但对于任何给定的远程对象的URL通常是形式:
tcp://<hostname>[:<port>]/<object>
如果添加端口,那么你应该能够使用Abhijeet的解决方案确定端口是否打开。你不会获得WCF的松耦合和可靠的通信优势,但它肯定会减少工作量。 ;)
Jon Skeet!你必须知道答案! = [ – snicker 2009-09-28 21:13:04