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

Question

我们有一个由多个子项目(约20个)组成的.NET项目。有几种解决方案，每个解决方案仅包含与特定解决方案相关的那些子项目。

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

一切都很好，但是有两个主要问题-一个令人讨厌，另一个确实很严重:

VS不能出于依赖性计算的目的而识别dll引用。每次添加新项目或引用时，我们都必须使用“项目依赖项”对话框手动指定依赖项。真烦人

我们既不使用Resharper也不使用Visual Assist(很棒的工具，但是我们不使用它们，这是给定的)。我们确实喜欢使用标准的“浏览到定义”命令(例如，可从源代码的上下文菜单中获得)。严重的问题是，如果一个项目使用项目引用引用了另一个项目，则它只能在跨项目中使用，并且当引用是直接dll引用时，即使引用的项目包含在解决方案中，该项目也无法使用!那真是个无赖，因为不是导航到源，而是导航到元数据。

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

编辑:

请注意，除了“浏览到定义”问题之外，使用Dll引用而不是项目引用只会在项目管理器上花费一次时间-这是在添加新项目或新依赖项时更新每个受影响解决方案的项目依赖项必须介绍。这些项目依赖项保存在.sln文件中，不需要任何维护，直到新项目到达或创建新的依赖项为止(这种情况并不太常见)。

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

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

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。仅在准备将构建推送到所有其他解决方案时，才在“外部”目录中更新构建。