一、Remoting的优缺点？
优点：
1、能让我们进行分布式开发
2、Tcp通道的Remoting速度非常快
3、虽然是远程的，但是非常接近于本地调用对象
4、可以做到保持对象的状态
5、没有应用程序限制，可以是控制台，winform，iis，Windows服务承载远程对象
缺点：
1、非标准的应用因此有平台限制
2、脱离iis的话需要有自己的安全机制
二、Remoting和Web服务的区别？
ASP.net Web 服务基础结构通过将 SOAP 消息映射到方法调用，为 Web 服务提供了简单的 API。通过提供一种非常简单的编程模型（基于将 SOAP 消息交换映射到方法调用），它实现了此机制。ASP.net Web 服务的客户端不需要了解用于创建它们的平台、对象模型或编程语言。而服务也不需要了解向它们发送消息的客户端。唯一的要求是：双方都要认可正在创建和使用的 SOAP 消息的格式，该格式是由使用 WSDL 和 XML 架构 (XSD) 表示的 Web 服务合约定义来定义的。
. NET Remoting 为分布式对象提供了一个基础结构。它使用既灵活又可扩展的管线向远程进程提供 .NET 的完全对象语义。ASP.NET Web 服务基于消息传递提供非常简单的编程模型，而 .NET Remoting 提供较为复杂的功能，包括支持通过值或引用传递对象、回调，以及多对象激活和生命周期管理策略等。要使用 .NET Remoting，客户端需要了解所有这些详细信息，简而言之，需要使用 .NET 建立客户端。.NET Remoting 管线还支持 SOAP 消息，但必须注意这并没有改变其对客户端的要求。如果 Remoting 端点提供 .NET 专用的对象语义，不管是否通过 SOAP，客户端必须理解它们。
三、最简单的Remoting的例子
1、远程对象：
建立类库项目：RemoteObject
Word-BREAK: break-all; PADDING-TOP: 4px; BORDER-BOTTOM: windowtext 0.5pt solid">
using System;
namespace RemoteObject
{
public class MyObject:MarshalByRefObject
{
public int Add(int a,int b)
{
return a+b;
}
}
}
2、服务端
建立控制台项目：RemoteServer
Word-BREAK: break-all; PADDING-TOP: 4px; BORDER-BOTTOM: windowtext 0.5pt solid">
using System;
using System.Runtime.Remoting;
namespace RemoteServer
{
class MyServer
{
[STAThread]
static void Main(string[] args)
{
RemotingConfiguration.Configure("RemoteServer.exe.config");
Console.ReadLine();
}
}
}
建立配置文件：app.config
<configuration>
<system.runtime.remoting>
<application name="RemoteServer">
<service>
<wellknown type="RemoteObject.MyObject,RemoteObject" objectUri="RemoteObject.MyObject"
mode="Singleton" />
</service>
<channels>
<channel ref="tcp" port="9999"/>
</channels>
</application>
</system.runtime.remoting>
</configuration>
3、客户端：
建立控制台项目：RemoteClient
using System;
namespace RemoteClient
{
class MyClient
{
[STAThread]
static void Main(string[] args)
{
RemoteObject.MyObject app = (RemoteObject.MyObject)Activator.GetObject(typeof(RemoteObject.MyObject),System.Configuration.ConfigurationSettings.AppSettings["ServiceURL"]);
Console.WriteLine(app.Add(1,2));
Console.ReadLine();
}
}
}
建立配置文件：app.config
<configuration>
<appSettings>
<add key="ServiceURL" value="tcp://localhost:9999/RemoteObject.MyObject"/>
</appSettings>
</configuration>
4、测试
在最后编译的时候会发现编译报错：
1、找不到app.Add()
2、找不到RemoteObject
这是因为客户端RemoteClient没有添加RemoteObject的引用，编译器并不知道远程对象存在哪些成员所以报错，添加引用以后VS.net会在客户端也保存一个dll，可能大家会问这样如果对远程对象的修改是不是会很麻烦？其实不麻烦，对项目编译一次VS.net会重新复制dll。
然后直接运行客户端会出现“目标主机拒绝”的异常，也说明了通道没有打开
运行服务端再运行客户端出现“找不到程序集RemoteObject”！回头想想可以发现我们并在服务端对RemoteObject添加引用，编译的时候通过是因为这个时候并没有用到远程对象，大家可能不理解运行服务端的时候也通过？这是因为没有这个时候还没有激活远程对象。理所当然，对服务端要添加引用远程对象，毕竟我们的对象是要靠远程承载的。
现在再先后运行服务端程序和客户端程序，客户端程序显示3，测试成功。
四、结束语
我们通过一个简单的例子实现了最简单的remoting，对其实质没有做任何介绍，我想通过例子入门才是最简单的。
优点：
1、能让我们进行分布式开发
2、Tcp通道的Remoting速度非常快
3、虽然是远程的，但是非常接近于本地调用对象
4、可以做到保持对象的状态
5、没有应用程序限制，可以是控制台，winform，iis，Windows服务承载远程对象
缺点：
1、非标准的应用因此有平台限制
2、脱离iis的话需要有自己的安全机制
二、Remoting和Web服务的区别？
ASP.net Web 服务基础结构通过将 SOAP 消息映射到方法调用，为 Web 服务提供了简单的 API。通过提供一种非常简单的编程模型（基于将 SOAP 消息交换映射到方法调用），它实现了此机制。ASP.net Web 服务的客户端不需要了解用于创建它们的平台、对象模型或编程语言。而服务也不需要了解向它们发送消息的客户端。唯一的要求是：双方都要认可正在创建和使用的 SOAP 消息的格式，该格式是由使用 WSDL 和 XML 架构 (XSD) 表示的 Web 服务合约定义来定义的。
. NET Remoting 为分布式对象提供了一个基础结构。它使用既灵活又可扩展的管线向远程进程提供 .NET 的完全对象语义。ASP.NET Web 服务基于消息传递提供非常简单的编程模型，而 .NET Remoting 提供较为复杂的功能，包括支持通过值或引用传递对象、回调，以及多对象激活和生命周期管理策略等。要使用 .NET Remoting，客户端需要了解所有这些详细信息，简而言之，需要使用 .NET 建立客户端。.NET Remoting 管线还支持 SOAP 消息，但必须注意这并没有改变其对客户端的要求。如果 Remoting 端点提供 .NET 专用的对象语义，不管是否通过 SOAP，客户端必须理解它们。
三、最简单的Remoting的例子
1、远程对象：
建立类库项目：RemoteObject
Word-BREAK: break-all; PADDING-TOP: 4px; BORDER-BOTTOM: windowtext 0.5pt solid">
using System;
namespace RemoteObject
{
public class MyObject:MarshalByRefObject
{
public int Add(int a,int b)
{
return a+b;
}
}
}
2、服务端
建立控制台项目：RemoteServer
Word-BREAK: break-all; PADDING-TOP: 4px; BORDER-BOTTOM: windowtext 0.5pt solid">
using System;
using System.Runtime.Remoting;
namespace RemoteServer
{
class MyServer
{
[STAThread]
static void Main(string[] args)
{
RemotingConfiguration.Configure("RemoteServer.exe.config");
Console.ReadLine();
}
}
}
建立配置文件：app.config
<configuration>
<system.runtime.remoting>
<application name="RemoteServer">
<service>
<wellknown type="RemoteObject.MyObject,RemoteObject" objectUri="RemoteObject.MyObject"
mode="Singleton" />
</service>
<channels>
<channel ref="tcp" port="9999"/>
</channels>
</application>
</system.runtime.remoting>
</configuration>
3、客户端：
建立控制台项目：RemoteClient
using System;
namespace RemoteClient
{
class MyClient
{
[STAThread]
static void Main(string[] args)
{
RemoteObject.MyObject app = (RemoteObject.MyObject)Activator.GetObject(typeof(RemoteObject.MyObject),System.Configuration.ConfigurationSettings.AppSettings["ServiceURL"]);
Console.WriteLine(app.Add(1,2));
Console.ReadLine();
}
}
}
建立配置文件：app.config
<configuration>
<appSettings>
<add key="ServiceURL" value="tcp://localhost:9999/RemoteObject.MyObject"/>
</appSettings>
</configuration>
4、测试
在最后编译的时候会发现编译报错：
1、找不到app.Add()
2、找不到RemoteObject
这是因为客户端RemoteClient没有添加RemoteObject的引用，编译器并不知道远程对象存在哪些成员所以报错，添加引用以后VS.net会在客户端也保存一个dll，可能大家会问这样如果对远程对象的修改是不是会很麻烦？其实不麻烦，对项目编译一次VS.net会重新复制dll。
然后直接运行客户端会出现“目标主机拒绝”的异常，也说明了通道没有打开
运行服务端再运行客户端出现“找不到程序集RemoteObject”！回头想想可以发现我们并在服务端对RemoteObject添加引用，编译的时候通过是因为这个时候并没有用到远程对象，大家可能不理解运行服务端的时候也通过？这是因为没有这个时候还没有激活远程对象。理所当然，对服务端要添加引用远程对象，毕竟我们的对象是要靠远程承载的。
现在再先后运行服务端程序和客户端程序，客户端程序显示3，测试成功。
四、结束语
我们通过一个简单的例子实现了最简单的remoting，对其实质没有做任何介绍，我想通过例子入门才是最简单的。