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