110,538
社区成员
发帖
与我相关
我的任务
分享关于跨机器的访问？？app-->dll
一个本地的exe如何调用另外一台机器上存在的dll;
这个在com+非常容易，现在在.net中反而不知道如何做了？
这个在com+非常容易，现在在.net中反而不知道如何做了？
...全文
请发表友善的回复…
发表回复
phonlee 2003-03-06
- 打赏
- 举报
http://www.zdnet.com.cn/developer/code/story/0,2000081534,39099482,00.htm
phonlee 2003-03-06
- 打赏
- 举报
.NET 框架开发者指南
可远程处理的对象请参见
ContextBoundObject | 不可远程处理的对象
可远程处理的对象是能在大范围的分布环境中正常运行的对象。有两种主要的可远程处理的对象：
按值封送对象，它们被复制并传出应用程序域。
按引用封送对象，将为其创建代理，而该代理由客户端用于远程访问对象。
按值封送对象
按值封送 (MBV) 对象声明它们的序列化规则（通过实现 ISerializable 来实现其自身的序列化，或者通过用 SerializableAttribute 修饰，该属性通知系统自动序列化该对象），但是不扩展 MarshalByRefObject。远程处理系统创建这些对象的完整副本并将副本传递到进行调用的应用程序域。一旦副本到达调用方的应用程序域内，对它的调用就是对该副本的直接调用。而且，当 MBV 对象作为参数传递时，也是通过值传递的。除声明 SerializableAttribute 或实现 ISerializable 之外，无需做其他任何事情就可以将类的实例跨应用程序或上下文边界通过值传递。
当由于性能或处理原因，将对象的完整状态和任何可执行功能移动到目标应用程序域有意义时，应当使用 MBV 对象。在许多方案中，这减少了跨网络、进程和应用程序域边界的冗长而耗费资源的往返行程。MBV 对象还可以从对象的原始应用程序域内直接使用。在这种情况下，由于不进行任何封送处理，因此不创建任何副本而且访问非常高效。
另一方面，如果发布的对象非常大，那么在繁忙的网络上传递整个副本对于应用程序来说可能不是最佳的选择。此外，永远不会将对复制对象的状态所做的更改传回到起始应用程序域中的原始对象。在抽象级别上，这种方案类似于客户端浏览器所请求的静态 HTML 页的方案。服务器复制文件，将其写入到流中，发送出去，然后忘掉它。所有后续的请求都只是对其他副本的其他请求。
远程处理系统广泛使用可序列化的对象。对其他应用程序域中的对象的引用（由 ObjRef 类在远程处理系统中表示）本身是可序列化的；必须能够将它精确地复制并将副本发送给请求。同样，对于实现 IMessage 的消息对象也是如此，这是因为它们是调用信息和所有其他所需对象引用的一般容器。另外，仅传输数据的对象通常是 MBV 对象。例如，DataSet 扩展实现 ISerializable 的 MarshalByValueComponent。
按引用封送的对象
按引用封送 (MBR) 的对象是至少扩展 System.MarshalByRefObject 的可远程处理的对象。根据已声明的激活类型，当客户端在自己的应用程序域中创建 MBR 对象的实例时，.NET 远程处理基础结构在调用方的应用程序域中创建表示该 MBR 对象的代理对象，并向调用方返回对此代理的引用。然后客户端将在该代理上进行调用；远程处理封送这些调用，将它们发送回起始应用程序域，并在实际对象上调用该调用。
注意 如果客户端位于与 MBR 对象相同的应用程序域中，基础结构将向客户端返回对该 MBR 对象的直接引用，从而避免封送处理的系统开销。
如果 MarshalByRefObject 作为参数传入，当调用到达时，它变成另一个应用程序域中的代理。MBR 返回值，并且 out 参数以相同的方式工作。
当对象的状态和任何可执行的功能应处在创建它的应用程序域中时，应当使用 MBR 对象。例如，具有内部字段且该内部字段是操作系统句柄的对象应扩展 MarshalByRefObject，这是因为操作系统句柄在其他进程中或其他计算机上的其他应用程序域中是无意义的。有时对象可能大得难以想象；对于功能强大的服务器还行，但通过网络发送到 33.6 kbps 的调制解调器就不行了。
上下文绑定对象
上下文绑定对象是从 System.ContextBoundObject（它本身从 System.MarshalByRefObject 继承）继承的 MBR 对象。可以将上下文当作应用程序域的子部分，它在执行期间为驻留在其中的对象提供某种资源充足的环境（例如保证对象不会被多个线程同时访问）。每个应用程序域都具有默认的上下文，大多数托管代码使用应用程序域的默认上下文创建对象并直接从同一应用程序域内部调用成员，而不会产生与上下文有关的问题。所有从 ContextBoundObject 继承的类型都作为代理向其他上下文公开，无论它们是否在同一应用程序域中。
例如，假定有一个某类型上的方法，该类型是事务的一部分因而受到特定于在其中创建它的上下文的规则的约束。应当使该类型从 ContextBoundObject 继承，这样就可以从对象本身的上下文访问该对象，而且系统可以强制实施有关与对象及其方法关联的事务的规则。如果从同一应用程序域内部的另一上下文中调用 ContextBoundObject，则将为调用方创建代理，但是上下文间的通讯不通过信道系统，从而在此情况下提高了调用效率。
考虑要远程处理哪种类别的类型时，请决定需要通过哪些边界。特定于某个特定上下文的对象只能从该上下文中直接访问。对于特定于某个特定应用程序域的对象也是如此。若要远程处理这两者中的任一种对象，在从服务器对象所特定于的边界内调用该服务器对象之前，远程处理系统必须成功通过上下文边界、应用程序边界或是成功通过这两种边界。由于通过每一边界都要花费处理时间，因而为了决定服务器应当是何种类型的可远程处理对象，就需要确定对象必须通过哪些边界。如果无需上下文检查就调用对象，则不应让远程类型扩展 ContextBoundObject（MarshalByRefObject 将执行得更好）。如果确实需要上下文检查，则应当扩展 ContextBoundObject，但是需要明白：在对象上进行调用之前，必须通过附加的边界。
请参见
ContextBoundObject | 不可远程处理的对象
--------------------------------------------------------------------------------
将文档反馈发送给 Microsoft
© 2002 Microsoft Corporation。保留所有权利。
可远程处理的对象请参见
ContextBoundObject | 不可远程处理的对象
可远程处理的对象是能在大范围的分布环境中正常运行的对象。有两种主要的可远程处理的对象：
按值封送对象，它们被复制并传出应用程序域。
按引用封送对象，将为其创建代理，而该代理由客户端用于远程访问对象。
按值封送对象
按值封送 (MBV) 对象声明它们的序列化规则（通过实现 ISerializable 来实现其自身的序列化，或者通过用 SerializableAttribute 修饰，该属性通知系统自动序列化该对象），但是不扩展 MarshalByRefObject。远程处理系统创建这些对象的完整副本并将副本传递到进行调用的应用程序域。一旦副本到达调用方的应用程序域内，对它的调用就是对该副本的直接调用。而且，当 MBV 对象作为参数传递时，也是通过值传递的。除声明 SerializableAttribute 或实现 ISerializable 之外，无需做其他任何事情就可以将类的实例跨应用程序或上下文边界通过值传递。
当由于性能或处理原因，将对象的完整状态和任何可执行功能移动到目标应用程序域有意义时，应当使用 MBV 对象。在许多方案中，这减少了跨网络、进程和应用程序域边界的冗长而耗费资源的往返行程。MBV 对象还可以从对象的原始应用程序域内直接使用。在这种情况下，由于不进行任何封送处理，因此不创建任何副本而且访问非常高效。
另一方面，如果发布的对象非常大，那么在繁忙的网络上传递整个副本对于应用程序来说可能不是最佳的选择。此外，永远不会将对复制对象的状态所做的更改传回到起始应用程序域中的原始对象。在抽象级别上，这种方案类似于客户端浏览器所请求的静态 HTML 页的方案。服务器复制文件，将其写入到流中，发送出去，然后忘掉它。所有后续的请求都只是对其他副本的其他请求。
远程处理系统广泛使用可序列化的对象。对其他应用程序域中的对象的引用（由 ObjRef 类在远程处理系统中表示）本身是可序列化的；必须能够将它精确地复制并将副本发送给请求。同样，对于实现 IMessage 的消息对象也是如此，这是因为它们是调用信息和所有其他所需对象引用的一般容器。另外，仅传输数据的对象通常是 MBV 对象。例如，DataSet 扩展实现 ISerializable 的 MarshalByValueComponent。
按引用封送的对象
按引用封送 (MBR) 的对象是至少扩展 System.MarshalByRefObject 的可远程处理的对象。根据已声明的激活类型，当客户端在自己的应用程序域中创建 MBR 对象的实例时，.NET 远程处理基础结构在调用方的应用程序域中创建表示该 MBR 对象的代理对象，并向调用方返回对此代理的引用。然后客户端将在该代理上进行调用；远程处理封送这些调用，将它们发送回起始应用程序域，并在实际对象上调用该调用。
注意 如果客户端位于与 MBR 对象相同的应用程序域中，基础结构将向客户端返回对该 MBR 对象的直接引用，从而避免封送处理的系统开销。
如果 MarshalByRefObject 作为参数传入，当调用到达时，它变成另一个应用程序域中的代理。MBR 返回值，并且 out 参数以相同的方式工作。
当对象的状态和任何可执行的功能应处在创建它的应用程序域中时，应当使用 MBR 对象。例如，具有内部字段且该内部字段是操作系统句柄的对象应扩展 MarshalByRefObject，这是因为操作系统句柄在其他进程中或其他计算机上的其他应用程序域中是无意义的。有时对象可能大得难以想象；对于功能强大的服务器还行，但通过网络发送到 33.6 kbps 的调制解调器就不行了。
上下文绑定对象
上下文绑定对象是从 System.ContextBoundObject（它本身从 System.MarshalByRefObject 继承）继承的 MBR 对象。可以将上下文当作应用程序域的子部分，它在执行期间为驻留在其中的对象提供某种资源充足的环境（例如保证对象不会被多个线程同时访问）。每个应用程序域都具有默认的上下文，大多数托管代码使用应用程序域的默认上下文创建对象并直接从同一应用程序域内部调用成员，而不会产生与上下文有关的问题。所有从 ContextBoundObject 继承的类型都作为代理向其他上下文公开，无论它们是否在同一应用程序域中。
例如，假定有一个某类型上的方法，该类型是事务的一部分因而受到特定于在其中创建它的上下文的规则的约束。应当使该类型从 ContextBoundObject 继承，这样就可以从对象本身的上下文访问该对象，而且系统可以强制实施有关与对象及其方法关联的事务的规则。如果从同一应用程序域内部的另一上下文中调用 ContextBoundObject，则将为调用方创建代理，但是上下文间的通讯不通过信道系统，从而在此情况下提高了调用效率。
考虑要远程处理哪种类别的类型时，请决定需要通过哪些边界。特定于某个特定上下文的对象只能从该上下文中直接访问。对于特定于某个特定应用程序域的对象也是如此。若要远程处理这两者中的任一种对象，在从服务器对象所特定于的边界内调用该服务器对象之前，远程处理系统必须成功通过上下文边界、应用程序边界或是成功通过这两种边界。由于通过每一边界都要花费处理时间，因而为了决定服务器应当是何种类型的可远程处理对象，就需要确定对象必须通过哪些边界。如果无需上下文检查就调用对象，则不应让远程类型扩展 ContextBoundObject（MarshalByRefObject 将执行得更好）。如果确实需要上下文检查，则应当扩展 ContextBoundObject，但是需要明白：在对象上进行调用之前，必须通过附加的边界。
请参见
ContextBoundObject | 不可远程处理的对象
--------------------------------------------------------------------------------
将文档反馈发送给 Microsoft
© 2002 Microsoft Corporation。保留所有权利。
phonlee 2003-03-05
- 打赏
- 举报
具体如何做？？
bill老兄也该给一个例子呀
bill老兄也该给一个例子呀
yarshray 2003-03-05
- 打赏
- 举报
你说的就是分布式应用嘛
DCOM/COM+ 也可以在。NET中使用
但基本上。NET中有自己的方式
你可以参考如下：
ms-help://MS.VSCC/MS.MSDNVS.2052/vsintro7/html/vxconDevelopingApplicationsWithVisualStudio.htm
DCOM/COM+ 也可以在。NET中使用
但基本上。NET中有自己的方式
你可以参考如下：
ms-help://MS.VSCC/MS.MSDNVS.2052/vsintro7/html/vxconDevelopingApplicationsWithVisualStudio.htm
ketao_78 2003-03-05
- 打赏
- 举报
嘿嘿，就是就是，我耶没有做过
qimini 2003-03-05
- 打赏
- 举报
用Remoting来实现，具体怎么实现,^_^看一下MSDN啦!
