VS.NET：项目引用与程序集引用

Question

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

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

以下是我能想到的项目参考是更好解决方案的原因。我也在寻找其他意见。

优点：

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

缺点：

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

Answer 1

以下是您错过的实时更新的一些优点

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

针对您的缺点

• 是：加载项目通常比加载引用慢。对于合理数量的项目，虽然这个时间差异并不显着，并且不会影响您的日常开发例程
• 是：向解决方案添加项目通常比添加引用慢。但差异以秒为单位，并且是一次性成本。我认为将此视为标准的一部分是错误的。

Answer 2

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

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

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

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

Answer 3

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

我知道这是一个非常古老的问题，但它始终是一个具有相关答案的相关问题，我记得几年前也遇到过同样的问题以及该问题的影响两种选择（项目与程序集参考）只是在过去两年里我才变得明显起来，当时我正在全职开发一个系统的构建器，该系统包含 800 多个项目，单个 WPF 应用程序有 300 多个解决方案。

项目引用对于 VISUAL STUDIO 来说是理想的

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

汇编引用可以更好地扩展

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

汇编引用创建了一个解耦系统的幻象

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

程序集引用的优点：

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

程序集引用的缺点：

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

  <块引用>

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

  循环引用

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

  <块引用>

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

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

  <块引用>

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