这只涉及“构建解决方案”选项。

我完全受够了Visual Studio无法真正清理解决方案，所以写了这个小工具来为你做这件事。

首先在VS中关闭你的解决方案，并将它的文件夹从Windows资源管理器拖到这个应用程序或它的图标中。根据窗口底部的设置，它还可以删除额外的东西，这将有助于你手动上传你的解决方案到GitHub或与他人共享:

简而言之，它会把所有的“调试”文件夹、智能感知和其他可以被VS重建的缓存放入回收站。

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

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

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

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

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

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

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

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

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

摘自此链接:

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

Clean将清除bin/Debug文件夹中的工件。删除bin/Debug文件夹中的所有文件。

Build检查bin/Debug文件夹中的构件，如果需要，然后创建构件(同时检查构建时错误)。

重建=清洁+一次构建。这将首先删除bin/Debug文件夹中的所有文件，然后在bin/Debug文件夹中再次创建工件。

您可以通过打开并观察bin/Debug(或Release)文件夹，然后清理、构建和重建项目来确认这些操作。

生成解决方案只生成解决方案中已更改的项目，而不影响未更改的程序集，

ReBuild首先清理解决方案中的所有程序集，然后构建整个解决方案，而不管所做的更改。

清洁，简单地清洗溶液。

**Build ,Rebuild, Clean Solution**

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

构建解决方案 :编译已更改的代码文件(dll和exe)。

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