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

Question

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

为了允许任意解决方案，我们的子项目从不通过项目引用相互引用，而是通过直接dll引用。 csproj文件几乎没有调整，要使HintPath包含$（Configuration），所以Debug构建引用Debug dlls和Release构建引用Release dlls。

一切都很好，但有两个主要问题 - 一个是烦人的，另一个是非常尖锐的：

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参考。

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

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。当您准备将构建推送到所有其他解决方案时，仅更新Externals目录中的构建。

Answer 2

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

Answer 3

对我而言，您遇到的问题就是错误地使用工具集的直接结果。当你不让它管理时，Visual Studio没有其他方法可以自动计算项目依赖性。

听起来你有两个选择。

1. 使用Visual Studio管理项目依赖关系
2. 使用其他构建系统（如NAnt）

听起来你已经排除了选项＃1，所以我不再解决这个问题了。所以只留下选项＃2。

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

1. 你必须管理所有买手（这听起来像你准备做）
2. Visual Studio对你来说就像现在一样破碎。

在缺点＃2下，Visual Studio将无法整体编译您的解决方案，因为该逻辑将从VS转移到外部构建脚本中。这可能会导致开发人员之间的混淆，并会阻碍调试过程。不是说那些事情是不可克服的......只是说这将是开发过程中那些额外的设置。