将程序集加载到新的应用程序域并与WCF通信

Question

这不是编码问题，而是理解问题
我需要将第三方DLL加载到我的进程中，但在一个新的应用程序域中（因为我以后必须能够卸载它）。

我在网上看到的大多数样本都是MarshalByRefObject，但据我所知，Remoting已经死了
所以我认为流程应该是这样的：

1. 从AppDomain 1-获取DLL路径
2. 从AppDomain 1-将dll加载到新的应用程序域
3. 这是在AppDomain 2上-在加载的程序集中的入口类上，我将放置某些属性，然后通过反射（两个程序集之间必须通用的反射类），我将定位该类并实例化一个实例。在构造函数中，我将在特定地址上打开WCF服务并侦听请求
4. 从AppDomain1-此时，我将在相同的地址上创建WCF客户端，并调用AppDomain-2类上的函数

这种情况有效吗？或者我应该使用这样的样品http://msdn.microsoft.com/en-us/library/3c4f1xde（v=vs.100）.aspx

谢谢！

Answer 1

不正确。虽然.NET远程处理对于进程间或机器间通信来说可能是"死的"，但对于与同一进程中不同AppDomain中运行的其他对象进行通信来说，它还远远没有死。

以下是2013年8月的MSDN文章：

• 托管第三方.NET插件的体系结构

此外，Remoting在.NET 4.5中的Microsoft的System.AddIn命名空间（或MAF）中使用，该命名空间允许您在不同的AppDomains中托管加载项。-加载项和可扩展性

我建议您查看System.AddIn，而不是自己滚动。

虽然现在已经老了，但如果你热衷于制作自己的插件系统，下面的文章是非常有用的。它适用于.NET2，但我发现它仍然相关——我知道我的插件系统仍然可以工作：

• 你相信它吗？探索使用.NET Framework 2.0安全托管不受信任的外接程序的技术

AppDomain.CreateInstanceAndUnwrap

。。。或者我应该使用像[AppDomain.CreateInstanceAndUnwrap]这样的示例

是的。参见以上文章

性能

我想你也会发现，由于命名管道的开销，单进程Remoting甚至会在命名管道上执行WCF。