.net 在不依赖SDK的情况下与Visual Studio交互？ 我有一些工作流基础4活动设计器，我想与VisualStudio IDE进行交互（事实上它们是WF4与问题无关）。

这些设计器是在程序集中定义的，我们将其称为herpaderp.dll。最终，这个dll将被传送到服务器，在那里它的活动和其他代码将永远快乐地生活

但是，在此之前，我希望我的设计人员能够检查当前的解决方案，以便为使用herpaderp.dll中定义的活动的人员提供更好的设计时体验。类似于“让我们使用存储在解决方案中的示例数据测试此活动配置；以下是我在一个方便的组合框中找到的示例数据--请选择一个”

现在，这很简单。以下是NAIVE实现：

var dteo = Microsoft.VisualStudio.Shell.Package.GetGlobalService(typeof(DTE));
var dte = dteo as DTE;
if(dte == null) return; // not in Visual Studio or other wierdness, bail
var samples = dte.GetSampleDatum(); // super awesome extension method

嘿，那太好了！但是有一个小问题herpaderp.dll现在必须引用以下程序集：

• Microsoft.VisualStudio.Shell.10.0.dll
• envdte.dll

这些程序集是SDK的一部分。对我来说，必须将它们打包并交付给服务器是毫无意义的。这就像给我的大肠添加了另一个阑尾

如何打破这些依赖关系，同时保留从设计师内部与Visual Studio交互的能力？

在我看来，我有三个可能的答案，没有一个是我特别满意的

在运行时使用IoC绑定到将为我执行交互的程序集。程序集可以引用SDK程序集，同时隐藏在herpaderp中定义的简单接口后面。不幸的是，这增加了一个不同的依赖项，它只在设计时起作用，在服务器上是无用的

在运行时使用依赖项的程序集限定名称加载依赖项，并隐藏在

dynamic

后面。这违反了我的类型安全繁殖。另外，我不确定我是否能百分之百地逃脱惩罚

在运行时通过某种服务位置与VisualStudio包交互。我的解决方案提供了一个VisualStudio扩展，所以我不必担心编写它或强迫人们使用它。但为了与它互动，我不得不使用一些蹩脚的服务定位器BS模式垃圾，我非常鄙视这些垃圾。服务定位器。菲。此外，它还需要某种类型的跨进程（或至少在同一进程中跨AppDomain）通信

---

我相信选择3是我最好的选择。我还缺少另一个解决方案吗？我恨我的三个答案中的一个是错的吗

我的选择是使用WCF创建一个进程范围（通过命名约定）命名管道，以进行来回通信

这很有效。我可以在活动程序集中的内部定义服务和客户端，并在包端实现服务。唯一需要注意的是，默认情况下，服务实现将处理UI线程上的调用，因此在从设计图面/客户端进行调用时，我无法阻止UI线程。使用一些明智的扩展方法向导，我可以轻松地将客户机调用卸载到线程池中，通过当前SynchronizationContext将结果和异常编组回线程池

---

我能够不费吹灰之力地实现这一点。不幸的是，我最近意识到，真正的问题是我应该做的是在不同的程序集中交付我的设计器，而这只能通过设计器安装程序交付。然后，这些活动将被交付到生产服务器，从而打破了任何依赖性担忧。这需要一些我不知道的惯例和过程的内部知识。这详细说明了我希望在问这个问题之前就知道的情况。

是的，这完全值得一票否决。屁股受伤了，你很坚强。耶！！！向上投票，因为我完全不知道如何回答，但我很好奇