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

Question

这不是编码问题，而是隐藏问题。

我需要加载一个第三方DLL到我的进程，但在一个新的应用程序域(因为我必须有能力卸载它以后)。

我在网上看到的大多数示例都是使用MarshalByRefObject的，但据我所知，远程处理已经死了。

所以我认为应该是这样的：

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

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

谢谢!

Answer 1

不正确。虽然.NET Remoting对于进程间或机器间通信来说可能是“死”的，但是对于在相同进程中与运行在不同AppDomains中的其他对象通信来说，它还远远不是死的。

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

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

此外，微软的System.AddIn名称空间(或MAF)在.NET 4.5中使用远程处理，它允许您在不同的AppDomains中托管加载项。- 外接程序和扩展性

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

虽然现在变老了，但如果您热衷于自己的外接程序系统，那么下面这篇文章是非常有用的。它适用于.NET 2，但我发现它仍然是相关的--我知道我的插件系统仍然有效：

• 你相信吗？发现使用.NET框架2.0安全托管不受信任的外接程序的技术

AppDomain.CreateInstanceAndUnwrap

...or我应该使用像AppDomain.CreateInstanceAndUnwrap这样的示例吗？

是。见上面的文章

性能

我认为您也会发现，单进程远程处理甚至在命名管道上的性能都会超过WCF，这是因为后者的开销。