在构建多解决方案MEF应用程序时复制DLL-s

Question

我使用visual studio 2010开发和构建.net框架4.0。我还使用Managed Extensibility Framework作为基本插件系统。

我有2个解决方案：

主要解决方案有6个项目，一个是可执行的，另外五个是类库。它们互相引用，它们内置在解决方案级别的bin文件夹中（bin文件夹位于项目文件夹旁边）。这样所有构建的bin文件都在同一个文件夹中，MEF可以在一个简单的DirectoryCatalog中收集所有的DLL。

这很好（除了1件事，启动应用程序不会重建所有其他项目，因为它们不是依赖项，但这不是这个问题的内容）。

另一个（扩展）解决方案有2个项目，它们都是类库，应该以某种方式添加到MEF用来构建它的目录的目录中。

有几种方法可以做到这一点，我只是找不到最干净的方法。

所以要解决的问题是：

1. 扩展解决方案的项目引用了第一个解决方案中的项目，因此我在添加参考屏幕上导航到主解决方案的bin文件夹，并添加了所有必需的引用。引用是否会更新构建主要解决方案，或者我是否需要以某种方式手动复制DLL？

   • intellisense应该识别这个变化，因此在更改和构建主要解决方案之后应该被识别，并且intellisense应该在编辑扩展解决方案时更新。
   • 主要解决方案可以自行构建，并且对扩展解决方案一无所知。让我们保持这种方式。我不会将构建任务写入将dll复制到另一个解决方案文件夹的主解决方案。
   • 解决方案托管在SVN服务器上。如果在新计算机上使用ankhsvn获得解决方案并构建这两种解决方案将无需进一步配置，那将是一个很好的补充。

2. 在构建扩展解决方案的项目时，应将DLL-s复制到MEF用于其目录的目录（主解决方案的bin目录）。如果它也能从svn中获得新鲜效果，那将是一件好事。这可以通过构建任务来完成，但这是引用其他解决方案文件夹的最佳方式吗？

   • 我认为如果解决方案目录必须彼此相邻（并且具有默认名称）才能工作，那将不是一个很好的妥协（这样我可以使用其他级别的../来引用它）。这是一个不错的解决方案？我不知道有什么缺点吗？

Answer 1

还有另一种处理问题1的方法：

• 将必要的项目从Main.sln添加到Extension.sln。您可以通过从解决方案的上下文菜单中选择“添加现有项目”来完成此操作。
• 将扩展项目的引用更新为添加的项目，而不是其输出dll。 Visual Studio将负责定位输出dll以及决定何时需要构建项目。
• 您甚至可以添加一个名为“依赖关系”的solution folder或类似内容，然后从Main.sln移动所有项目。通过这种方式，您可以了解哪些项目是“来宾”。

这将解决问题1的所有项目符号，但您需要小心，因为从Extension.sln您可以修改相关项目。另一个优点是，您还可以以更直接的方式调试代码，这种方式可以在新的开发机器中运行而无需任何额外的工作。

那就是说，我会选择所有8个项目的单一解决方案。只有解决方案变得越来越大（约100个项目），我才会这样做。

关于您对不同存储库的评论：

  

此外，如果我将此提交给SVN，“现有项目”也将如此   提交到新的存储库？

我不这么认为。如果你把它们放在同一个SVN存储库中（我看不出任何理由），那就好了。您可以在同一个存储库中添加许多解决方案。只要它们是相关的，这是正确的做法。

另一个有价值的测试是从存储库中获取一个新副本并尝试构建它。这可以在构建服务器上每天完成，并将帮助您尽早找到问题。这样做的步骤越少越好。