在 appdomain 隔离功能开始工作之前，它至少需要 7 个程序集并将我的 AddIn 的数据模型限制为远程处理可以处理的数据类型。太复杂了！System.AddIn 团队博客向我暗示他们正在尝试重新创建 COM 的心智模型，我一开始就不太了解这个模型，也没有为它的好处买单。（如果 COM 这么好，为什么它死了？-修辞问题。）如果我不需要镜像或与旧 COM 互操作（就像 VSTO 使用 System.AddIn 一样），是否可以只创建一些加载加载的类一个新的应用程序域？
我可以自己编写发现代码，我以前做过，而且天真的实现非常快，因为我不喜欢迭代 GAC 中的程序集！
所以我的具体问题是，我可以通过一些代码 Remoting 片段获得 AddIns 提供的 AppDomain 隔离吗？这些是什么？
我不完全确定您的问题的任何答案是否符合网站的条款 - 没有解决方案。
是的，远程处理更容易，因为它为您完成。但是，它是高度控制的，并且正如您所确定的，需要一些工作才能将它们全部组合在一起。由发现过程吐出的缓存文件也几乎不受欢迎。
System.AddIn 擅长隔离，实际上以一种健壮、灵活的方式从头开始组合起来有点笨拙。它支持跨进程托管和相当简单的用户 WPF 元素从一个域到另一个域的传递。
但是要记住的一件事是，MAF 的目标受众不是那些试图将两个应用程序连接在一起的人。它针对的是需要可插拔但安全系统的开发人员（跨进程托管保护根应用程序免受未处理的异常，appdomains 允许执行具有定义安全性的潜在外部代码）。从大多数通信中，直接将自己指向 System.Runtime.Remoting 或 WCF。
如果您想继续使用 System.AddIn，请考虑使用Visual Studio的管道构建器插件！
总之 - 您可以使用 Remoting 获得 System.AddIn 隔离，但要获得一个体面的系统，您将需要多个片段。我正在尝试自己复制它并在远程接口组件上绊倒 - System.AddIn 可以顺利完成。
在使用 System.Add 一段时间后，我确信它是作为 Microsoft 使用的一次性专用解决方案添加的。我很惊讶它被提升为 .NET 框架的核心部分。它似乎没有一般 .NET 框架组件所需的细化和润色。
我想找到一种替代方法来创建不需要太多努力的 .NET 托管加载项。