10

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

项目或解决方案重建 而不是 在 Visual Studio中构建？

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

谢谢！

4

2 回答 2

7

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

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

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

    解决方案
      |__依赖项
      |__PROJ_1
         |__bin
         |__obj
         |__（代码）
      |__PROJ_2
         |__bin
         |__obj
         |__（代码）

如果我在 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 属于第二种情况...

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

于 2010-11-15T09:24:09.577 回答
1

有时事情会出错，构建不起作用。

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

那是我使用重建的时候。

于 2010-11-15T08:26:00.507 回答