通过 dll 引用而不是 VS 中的项目引用来管理 .NET 程序集依赖项

Question

我们有一个由多个子项目（大约 20 个）组成的 .NET 项目。有多个解决方案，每个解决方案仅包含与特定解决方案相关的子项目。

为了允许任意解决方案，我们的子项目从不通过项目引用相互引用，而是通过直接 dll 引用。对 csproj 文件进行少量调整，使 HintPath 包含 $(Configuration)，因此 Debug 构建引用 Debug dll，Release 构建引用 Release dll。

一切都很好，但有两个主要问题 - 一个很烦人，另一个非常严重：

1. VS 无法识别 dll 引用来进行依赖关系计算。每次添加新项目或引用时，我们都必须使用“项目依赖项”对话框手动指定依赖项。这很烦人。
2. 我们既不使用 Resharper，也不使用 Visual Assist（很棒的工具，但我们不使用它们，这是给定的）。我们确实喜欢使用标准的“浏览到定义”命令（例如，可以从源代码的上下文菜单中使用）。严重的问题是，如果一个项目使用项目引用引用另一个项目，则它只能跨项目工作，并且当引用是直接 dll 引用时，它不起作用，即使引用的项目包含在解决方案中！这真是令人沮丧，因为它不是导航到源，而是导航到元数据。

我正在寻求那些像我们一样使用 dll 引用并以某种方式克服了这两个问题的人的建议。 谢谢。

编辑：

请注意，除了“浏览到定义”问题之外，使用 Dll 引用而不是项目引用只会给项目经理带来一次时间成本 - 即在以下情况下更新每个受影响解决方案的项目依赖项：添加新项目或必须引入新的依赖项。这些项目依赖项保留在 .sln 文件中，并且不需要任何维护，直到新项目到达或创建新依赖项（这种情况并不经常发生）。

我们使用 msbuild 在 CI 服务器上构建我们的项目，它使用与 VS 相同的 .sln 文件。有一个主 .sln 文件，其中包括所有子项目。

我想强调更严重的问题 - 无法浏览到另一个项目中的定义，尽管两个项目都在同一个解决方案中，只是因为引用是 dll 引用。这很烦人，很麻烦，VS 没有理由坚持使用项目引用来启用该功能。其他工具，如 Resharper 或 Visual Assist 则没有此限制。可惜的是，我们没有这些工具，而且在可预见的未来也不太可能拥有这些工具。

Answer 1

您的构建配置问题如下：假设您有 3 个项目和 2 个解决方案。

Solution1
- Project1
- Project2
Solution2
- Project1
- Project3

突然间，构建 Solution2 会构建 Solution1 的部分代码，使其处于无效状态（最新的二进制文件要么不兼容，要么不需要构建）。

每个项目都应该包含在一个解决方案中。其他解决方案可以依赖，但不应主动更改这些项目的代码。通过这种方式，他们可以引用构建的 DLL，因为没有理由重建外部依赖项。

总而言之，您应该花一些时间重组您的解决方案以满足以下条件：

• 每个项目都包含在一个解决方案中。
• 如果一个项目依赖于同一解决方案中的另一个项目，请将其作为项目引用。
• 如果一个项目依赖于不同解决方案中的另一个项目，请将其设为 DLL 引用。

除了上述内容之外，我建议创建一个“Externals”目录，以便在其他解决方案引用它们时放置构建。假设您重组为以下内容：

Solution1
- Project1
- Project2 -> reference project Project1
Solution2
- Project3 -> reference Project1.dll

在这种情况下，您将 Project1.dll 和 Project1.pdb 的副本放置在 Externals\Project1\Debug 和 Externals\Project1\Release 中，并在 Project3 中引用 External\Project1\$(Configuration)\Project1.dll。仅当您准备好将构建推送到所有其他解决方案时，才更新外部目录中的构建。

Answer 2

您是否有任何理由想要允许任意解决方案？创建一个解决方案并将所有项目放入该解决方案中似乎会更容易。我尽量避免使用多种解决方案。

Answer 3

在我看来，您遇到的问题是不正确使用工具集的直接结果。当您不让 Visual Studio 管理项目依赖项时，它没有其他方法可以自动计算项目依赖项。

听起来你有两个选择。

1. 使用 Visual Studio 管理项目依赖项
2. 使用另一个构建系统（如 NAnt）

听起来您已经排除了选项 #1，所以我不会再讨论这个问题。这样就只剩下选项#2了。

您可以使用 NAnt 构建您的个人 CSproj 项目，并使用 NAnt 构建脚本来定义项目之间的依赖关系。这样做有两个缺点。

1. 你必须管理这一切（听起来你已经准备好这样做），
2. Visual Studio 对你来说会像现在一样崩溃。

缺点#2 是，Visual Studio 无法将您的解决方案作为一个整体进行编译，因为该逻辑已从 VS 转移到外部构建脚本中。这可能会导致开发人员感到困惑，并阻碍调试过程。并不是说这些事情无法克服……只是说开发过程的这些步骤需要额外的设置。