什么时候你应该选择重建而不是构建？

Question

为了让我更清楚，我想问一下你们的

项目或解决方案重建而不是构建< 的正确条件/strong> 在 Visual Studio 中？

如果我换个说法：为什么 MS 需要在 Visual Studio 中创建“重新构建所有”选项？他们这样做的主要动机是什么？

谢谢！

Answer 1

DRY ：依次为每个项目重新构建 = 清理 + 构建。

构建不会删除以前的构建输出。
重建会删除它们并再次构建（如果您处于解决方案中，则一次一个项目：删除 proj1\bin\Debug、构建 proj1、删除 proj2\bin\Debug ...）。

我进行重建（或干净构建）时的主要情况是我需要更新解决方案的第三个依赖项。让我们看看下面的文件夹树：

    SOLUTION
      |__Dependencies
      |__PROJ_1
         |__bin
         |__obj
         |__(code)
      |__PROJ_2
         |__bin
         |__obj
         |__(code)

如果我更改依赖项中的 dll 并且不进行重建，VS（和 MsBuild）仍将使用 PROJ_N\bin\Debug（或 bin\Release）中的先前 dll 版本，由于依赖项查找顺序（请参阅 http://www.beefycode .com/post/Resolving-Binary-References-in-MSBuild.aspx) ：

1. 当前项目中的文件 - 由 {CandidateAssemblyFiles}
2. $(ReferencePath) 指示- 引用路径属性，来自 .USER 文件。
3. 引用项本身的提示路径，由 {HintPathFromItem} 指示。
   ...

bin 文件夹中的 dll 出现在第一个查找情况中， Dependency 文件夹中的 dll 出现在第二种情况中...

在这种情况下，我会执行清理（调试）、清理（发布），然后构建根除 bin 文件夹中的所有先前版本。我可能有点矫枉过正，重建可能就足够了，但我不确定，因为 dll 位于调试和发布文件夹中......

Answer 2

有时会出现问题，构建无法正常工作。

例如，当我没有正确更新依赖库，而这些依赖库没有正确复制到构建的 bin 路径时，就会发生这种情况。还有其他例子，但没有想到。

这就是我使用重建的时候。