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

Question

这不是编码问题 - 而是一个明智的问题 我需要将第三方DLL加载到我的Process中，但是在一个新的App域中（因为我必须能够在以后卸载它）。

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

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

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

这样的样本

谢谢！

Answer 1

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

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

• Architecture for Hosting Third-Party .NET Plug-Ins

远程处理用于Microsoft .NET 4.5 中的 System.AddIn 命名空间（或MAF），它允许您在不同的地方托管插件的应用程序域即可。 - Add-ins and Extensibility

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

虽然现在变老，但如果您热衷于制作自己的插件系统，以下文章非常有用。它适用于.NET 2，但我发现它仍然相关 - 我知道我的插件系统仍然有效：

• Do You Trust It? Discover Techniques for Safely Hosting Untrusted Add-Ins with the .NET Framework 2.0

AppDomain.CreateInstanceAndUnwrap

  

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

是。见上文

效果

我认为你也会发现，由于后者的开销，单进程Remoting甚至会超过命名管道的WCF。