.NET远程处理（Remoting）与WCF的功能性对比

写作动机与本文范围

研究.NET远程处理和WCF，是因为我的项目需要.net应用程序在局域网内通信。于是有了.NET远程处理和WCF两种选择。网上有很多的.net remoting vs WCF的文章，但都不合我意。

我要编写的客户端和服务端都是.net 4.0应用程序，不需要WCF什么“强大灵活的”SOA功能。我的客户端和服务器在同一局域网内，不需要WCF强大的互联网穿透能力。为了通信效率，我要用TCP信道。我需要一个答案：在这种情况下，WCF对.NET远程处理仍具有优势吗？本文提供些信息，帮助我回答此问题。

正文

请在明确本文应用场景的情况下阅读正文。

	.NET远程处理	WCF
暂停客户端进程，服务端访问客户端	无限期等待	TimeoutException
以管理员权限运行	不必	netTcpBinding不必
服务器回调客户端接口，需要载入客户端实现的程序集	是，除非加入中间类	不需要

第一项测试是，运行服务端，运行客户端，客户端订阅服务器事件。然后通过进程管理器暂停(suspend)客户端进程，然后引发服务端事件。在这种情况下，用.NET远程处理，无论客户端的事件处理函数是不是OneWay，都会陷入无限期等待。解决方法是

 asyncResult = del.BeginInvoke(...);
if(asyncResult.WaitOne(2000))
{
    //操作完成
}
else
{
    //操作未完成，可能客户端已经掉线
}

然而用WCF，在经过指定的超时时间后，会抛出TimeoutException。

暂停进程我想是引起超时问题最强硬的引发方法。.NET远程处理如果用TCP信道，则不支持超时时间的设置（尽管MSDN上说是支持的）；用HTTP信道是支持的。

第二项测试，如果WCF用了HTTP信道，则服务端必须以管理员权限运行。这在某些情况下是不易接受的，比如运行一个游戏。.NET远程处理用HTTP或TCP都不需要管理员权限。

第三项测试与第一项测试有关。第一项测试中，服务端回调客户端，尽管我已经定义了服务端和客户端的接口，但是服务端仍需要载入客户端实现类的程序集！解决方法是加入一个包装类。