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

Question

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

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

1. 从 AppDomain 1 - 获取 DLL 路径
2. 从 AppDomain 1 - 将 dll 加载到新的应用程序域
3. 这是在 AppDomain 2 上 - 在加载程序集的入口类上，我将放置某些属性，然后通过反射（两个程序集之间必须通用的反射类）我将定位该类并实例化一个实例，在构造函数我将在特定地址打开 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

Remoting 也用于 .NET 4.5 中的 Microsoft 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] 之类的示例

是的。见以上文章

性能

我认为您也会发现，由于后者的开销，即使在命名管道上，单进程远程处理也会胜过 WCF。