2

我使用 Visual Studio 2010 在 .net 框架 4.0 上开发和构建。我还将托管可扩展性框架用于基本插件系统。

我有 2 个解决方案：

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

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

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

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

所以要解决的问题是：

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

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

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

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

1 回答 1

0

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

  • 将 Main.sln 中的必要项目添加到Extension.sln. 您可以通过从解决方案的上下文菜单中选择“添加现有项目”来执行此操作。
  • 将扩展项目的引用更新到添加的项目，而不是它们的输出 dll。Visual Studio 将负责定位输出 dll 并决定何时需要构建您的项目。
  • 您甚至可以添加一个solution folder命名的“依赖项”或类似的东西，并将所有项目从Main.sln. 通过这种方式，您可以分辨出哪些项目是“客人”。

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

也就是说，我会选择一个包含所有 8 个项目的单一解决方案，这是直截了当的。只有当解决方案变得庞大（约 100 个项目）时，我才会这样做。

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

另外，如果我将其提交给 SVN，“现有项目”是否也会提交给新的存储库？

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

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

于 2013-02-26T10:28:14.157 回答