VS.NET：项目参考与大会参考

Question

这里有一些争论，哪个更适合从其他项目引用我们的公共代码库：通过项目或汇编。我赞成引用该项目，特别是因为我们有自动化的单元测试，证明公共代码能够满足它的需要。

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

这就是我能想到为什么项目参考是更好的解决方案的原因。我也在寻找其他意见。

优点：

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

CONS：

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

Answer 1

以下是你错过的几个职业选手

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

回应你的缺点

• 是：加载项目通常比加载参考要慢。合理数量的项目，虽然这个时间差异不大，不应影响您的日常开发常规
• 是：添加项目到解决方案通常比添加引用更慢。但差异在几秒钟内，是一次性成本。我认为将此视为标准的一部分是错误的。

Answer 2

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

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

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

这种情况的另一个好处是你可以在公共代码上有一个补丁，以免混淆当前正在进行的开发工作。当然，这确实增加了在必要时在多个地方更新公共代码的额外管理负担。

Answer 3

参考策略将一直是常见问题

我知道这是一个非常古老的问题，但它始终是一个相关答案的相关问题，我记得几年前有同样的问题和两个选择的影响（项目与汇编

项目参考对于可视化工作室来说是理想的

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

组装参考可以更好地扩展

如果您的系统比200个项目大得多，那么您的构建可能会变得非常慢。我已经看到每个版本20分钟，这真的很糟糕。因此，如果你可以引用一个不会改变的DLL，你就会告诉Visual Studio＆＃34; NOT＆＃34;构建它，这显然会对构建时间产生一些影响。

组装参考创建一个错误的解耦系统

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

汇编参考文件的PROS：

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

汇编参考的缺点：

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

    

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

• 向上框架引用也成为可能，因为你添加了对更高.net框架编译的dll的引用，并且Visual Studio在发生这种情况时不会给你明确的根本原因消息所以你会尝试很多东西来在确定修复框架版本之前，修复问题并多次失败。

    

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

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

    

  你点击＆＃34;添加引用＆＃34;，进入几个目录，向下几个目录，选择dll并单击add而不会意识到dll实际上太远了上下你进入另一个分支你也正在努力。只有在构建服务器尝试解析该程序集并失败时，此问题才会显现。错误＆＃34;未知命名空间，您是否缺少程序集引用？＆＃34;不会浪费你整个团队的时间来帮助你。