VS.NET：项目参考与程序集参考

Question

关于从其他项目引用我们的通用代码库哪个更好：按项目还是按程序集，存在一些争论。我赞成引用该项目，特别是因为我们有自动化的单元测试来证明通用代码可以满足它的需要。

另一个阵营的想法是锁定这些项目，每月只发布一次程序集或其他什么。然后强制所有项目引用程序集。他们认为这将保护他们免于部署未经测试的代码。他们“太忙”了，无法编写自动化单元测试并配置他们的项目以进行持续集成，我对此没有影响，所以请不要关注这方面。

以下是我能想到的为什么项目引用是更好的解决方案的原因。我也在寻找其他意见。

优点：

• 引用项目可确保您使用的是最新代码。您无需等待任何事情。
• 减少重复。如果没有最新的代码，则更有可能重新发明轮子。
• 如果开发人员需要某些东西并且无法将其添加到它所属的程序集中，它将在任何可以工作的位置创建，从而产生许多不一致和代码重复。
• 开发更容易，因为您可以轻松查看/调试引用代码中发生的情况。
• 我们常见的东西不会经常改变，但当它改变时，它通常是有用的。为什么要增加维护和程序集发布管理的额外负担。

缺点：

• 加载时间可能更长。
• 将项目添加到新解决方案然后添加程序集引用可能需要稍长的时间。

Answer 1

这里有几个你错过的专业人士

• 实时更新：当您更改 API 时，智能感知等功能将在项目引用之间自动更新
• GoTo 定义：如果您有程序集引用，GoTo 定义会将您带到实际的代码定义。使用程序集引用，它将带您到生成的元数据签名。
• 查找所有引用：将处理项目引用中的所有代码以使用引用。对于程序集参考，您只会在元数据中看到使用情况
• 快速搜索（仅限 2010 年）：类似于查找所有参考文献，只是在 P2P 参考文献中效果更好

回应你的缺点

• 是：加载项目通常比加载参考要慢。项目数量合理，但时间差并不显着，不会影响您的日常开发流程
• 是：将项目添加到解决方案中通常比添加引用要慢。但是，差异以秒为单位，并且是一次性成本。我认为将其视为标准的一部分是错误的。

Answer 2

好吧，如果您使用任何类型的源代码控制，您都可以满足这两个阵营。使用分支或标签（取决于您的源代码管理）。

基本上，如果您有一个控制您的公共代码的团队，他们可以分支/标记一个稳定版本。然后您的项目将使用稳定版本。这可以防止您为其他项目部署不稳定的代码，同时让您能够测试、调试和查看所有源代码。

每当您的公共控制团队创建新的稳定版本时，您都可以更新源引用以从新分支中提取。

这种情况的另一面是，您可以在公共代码上打一个补丁，以免干扰当前正在进行的开发工作。当然，这确实增加了额外的管理负担，需要在多个地方更新公共代码。

Answer 3

引用策略将始终是一个常见问题

我知道这是一个非常古老的问题，但它始终是一个具有相关答案的相关问题，我记得几年前有同样的问题以及两种选择的影响（项目与装配 参考资料）只是在过去两年中我才开始意识到，当时我正在全职为一个系统的构建器工作，该系统有 800 多个项目和 300 多个解决方案，用于单个 WPF 应用程序。

项目参考是视觉工作室的理想选择

项目引用是理想的，因为您可以让 IDE 更深入地了解代码的细节，因为您明确告诉 Visual Studio 引用的项目及其所有代码在哪里。如果您在一个项目模块少于 200 个的系统上工作，并且可以负担得起只有几个解决方案（项目分组），请查看项目参考资料，因为 Visual Studio 可以在设计时使用这些额外信息为您做更多事情，例如向您展示代码而不是反映引用的程序集。

汇编参考可以更好地扩展

如果您的系统远大于 200 个项目，您的构建可能会变得非常缓慢。我已经看到每个构建 20 分钟，这真的很糟糕。因此，如果您可以引用一个不会更改的 DLL，那么您就是在告诉 Visual Studio“不”来构建它，这显然会对构建时间产生一些影响。

汇编引用会产生解耦系统的错觉

项目引用为您提供了一个更智能的 IDE，该 IDE 始终知道使用类型的位置和位置、可以找到代码的位置以及其他一些有用的统计信息，因为所有项目都是直接引用的。当您无意中尝试创建循环引用时，它也会向您发出警告。

程序集参考的优点：

1. 通过将某些项目视为外部依赖项，您可以创建更小的解决方案和更小的相关项目分组，因为不相关的项目被视为外部程序集
2. 让 Visual Studio 能够很好地处理非常大的模块化系统。
3. 强制您在构建过程中制定 dll/程序集分段策略。

程序集引用的缺点：

• 循环引用成为可能，经验不足的开发人员最初不会注意到这些引用。

  您可以通过将您的一个程序集视为已签入的第三方程序集、将其转移到下一个版本并最后构建它来解决循环引用的挑战。当使用此排除程序集的项目构建失败时，您可以决定重新构建该指定项目，并经常消除循环依赖关系。 （不推荐，但有可能）

• 向上框架引用也成为可能，因为您添加了对针对更高 .net 框架编译的 dll 的引用，并且 Visual Studio 不会在发生这种情况时为您提供明确的根本原因消息，因此您将尝试许多方法来修复在弄清楚修复框架版本之前出现问题并失败了很多次。

  新项目默认使用最新版本的 .net 框架，不考虑当前解决方案中的所有项目仍处于早期版本的 .net 中这一事实，因此当您使用程序集引用添加对该项目的引用时，您经常会遇到一个不太容易弄清楚的奇怪错误。

• 跨分支引用也成为可能，因为您可能同时在多个分支中工作，有时在添加引用时会感到困惑。

  您单击“添加引用”，向上移动几个目录，向下移动几个目录，选择 dll 并单击添加，但没有意识到 dll 实际上在您正在处理的另一个分支中上下太远了。当构建服务器尝试解析该程序集并失败时，这个问题才会变得明显。以及错误“未知命名空间，您是否缺少程序集引用？”完全不会帮助您浪费整个团队的时间。