你什么时候应该更喜欢ReBuild而不是Build？

Question

为了让我更清楚，我想问你们有没有正确的条件

在Visual Studio中

项目或解决方案重建 而不是 构建？

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

谢谢！

Answer 1

DRY：Rebuild = Clean + Build依次为每个项目。

Build不会删除以前的构建输出。 重建会删除它们并再次构建（如果你在一个解决方案中，一次一个项目：删除proj1 \ bin \ Debug，build proj1，delete proj2 \ bin \ Debug ...）。

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

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

如果我在Dependencies中更改我的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进入第一个查找案例，Dependencies文件夹中的dll出现在第二个案例中......

在这种情况下，我会做一个干净的（Debug），清理（Release），然后构建一个版本来根除bin文件夹中的所有先前版本。我可能有点矫枉过正，重建可能就够了，但我不确定因为dll在Debug和Release文件夹中......

Answer 2

有时出现问题，构建不起作用。

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

那是我使用重建的时候。