Visual Studio中的构建解决方案、重新构建解决方案和清洁解决方案之间的区别是什么?

什么时候使用这些工具比较合适?


当前回答

生成解决方案-生成已更改文件的任何程序集。如果程序集没有任何更改,则不会重新构建它。也不会删除任何中间文件。

最常用的。

重新构建解决方案——无论发生什么更改,都重新构建所有程序集,但保留中间文件。

当您注意到Visual Studio没有将您的更改合并到最新程序集中时使用。有时候Visual Studio也会犯错误。

清洁解决方案-删除所有中间文件。

当一切都失败,你需要清理一切,重新开始时使用。

其他回答

生成解决方案-生成已更改文件的任何程序集。如果程序集没有任何更改,则不会重新构建它。也不会删除任何中间文件。

最常用的。

重新构建解决方案——无论发生什么更改,都重新构建所有程序集,但保留中间文件。

当您注意到Visual Studio没有将您的更改合并到最新程序集中时使用。有时候Visual Studio也会犯错误。

清洁解决方案-删除所有中间文件。

当一切都失败,你需要清理一切,重新开始时使用。

构建解决方案将构建解决方案中已更改的任何项目。重建构建所有项目,清洁解决方案删除所有临时文件,确保下一次构建完成。

摘自此链接:

构建意味着只编译和链接已更改的源文件 从上次构建开始,而重新构建 意味着编译和链接所有源代码 文件,不管它们是否 改变与否。构建是常态 要做的事情,而且更快。有时 项目目标的版本 组件可能会不同步 重建是进行构建所必需的 成功的。在实践中,你永远不会 需要清洁。

问题分为两部分……但是所有的答案(除了Justin Niessner)都只关注第一部分:区别。第二部分是我觉得更有趣的:“什么时候使用这些东西的合适时间?”但让我先说说我是如何看待它们的:

构建:应该并且通常会:生成(构建)相对于源文件已经过时的每个中间文件和输出文件。

重建:一种变通方法(hack),允许您在构建命令由于过时的计算错误而失败时进行构建。

Clean:删除生成的(中间文件和输出文件)文件,以便后续构建可以工作的一种hack实现。黑客,因为它经常删除不够。VS设计器将所有中间文件和输出文件放在单独的目录中。为什么不删除这些目录?但是,我跑题了。

没有明确的方法知道什么时候使用一个命令,什么时候使用另一个命令。知道它们的功能,并不能真正告诉我使用它们的适当情况。

这更多的是关于个性而不是科学。乐观主义者大部分时间都使用Build,但如果Build失败了,他们就会求助于Rebuild,他们认为问题出在Visual Studio的不稳定行为上。如果重建失败,他们就会进行清洁和重建。当这行不通时,他们就开始谷歌……

更悲观的人总是使用Rebuild,因为它更可靠,尽管每次使用都需要更长的时间。最悲观的人总是先清理再重建。他们忘记了有一个构建命令。他们还系着腰带和背带裤。

有些人可能认为这是愤世嫉俗。但是,我不这么认为。我认为Visual Studio的用户体验很糟糕,用户和行业已经习惯了它。更糟糕的是,由于VS无处不在,许多其他工具采用了相同的UX。

依我看,微软应该:修复Build,修复Clean,消除Rebuild

编译解决方案:编译已更改的代码文件(DLL和EXE)。

重建:删除所有编译过的文件,并重新编译它们,不管代码是否更改。

清洁解决方案:删除所有编译过的文件(DLL和EXE文件)。

你可以在YouTube上看到这个视频(Visual Studio Build vs. Rebuild vs. Clean (c#面试问题及答案)),我已经演示了其中的差异,下面是可视化表示,它将帮助你更详细地分析相同的内容。

重建和(清洁+构建)之间的区别,因为这似乎也有一些困惑:

不同之处在于每个项目的构建和清理序列发生的方式。假设您的解决方案有两个项目,“proj1”和“proj2”。如果你重新构建,它将使用“proj1”,清除(删除)“proj1”的编译文件并构建它。之后,它将获取第二个项目“proj2”,清理“proj2”的编译文件并编译“proj2”。

但是如果你做了“清理”和“构建”,它将首先删除“proj1”和“proj2”的所有编译文件,然后它将首先构建“proj1”,然后是“proj2”。