c# - 将程序集加载到新的应用程序域并与 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 对于进程间或机器间通信可能“死了”，但它远未死于与同一进程.

这是 2013 年 8 月的一篇 MSDN 文章:

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

此外，Remoting 还用于 .NET 4.5 中 Microsoft 的 System.AddIn 命名空间(或 MAF)，它允许您在不同的环境中托管插件AppDomains。 - 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

...or should i use the samples like [AppDomain.CreateInstanceAndUnwrap]

是的。见以上文章

性能

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