Visual Studio中的构建解决方案、重新构建解决方案和清洁解决方案之间的区别是什么?
什么时候使用这些工具比较合适?
Visual Studio中的构建解决方案、重新构建解决方案和清洁解决方案之间的区别是什么?
什么时候使用这些工具比较合适?
当前回答
**Build ,Rebuild, Clean Solution**
清洁解决方案 :删除所有编译过的文件(所有dll和exe)。
构建解决方案 :编译已更改的代码文件(dll和exe)。
重建方案 :删除所有编译过的文件,并重新编译它们,不管代码是否已经更改。
其他回答
问题分为两部分……但是所有的答案(除了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”。
构建解决方案将构建解决方案中已更改的任何项目。重建构建所有项目,清洁解决方案删除所有临时文件,确保下一次构建完成。
这只涉及“构建解决方案”选项。
我完全受够了Visual Studio无法真正清理解决方案,所以写了这个小工具来为你做这件事。
首先在VS中关闭你的解决方案,并将它的文件夹从Windows资源管理器拖到这个应用程序或它的图标中。根据窗口底部的设置,它还可以删除额外的东西,这将有助于你手动上传你的解决方案到GitHub或与他人共享:
简而言之,它会把所有的“调试”文件夹、智能感知和其他可以被VS重建的缓存放入回收站。
生成解决方案-生成已更改文件的任何程序集。如果程序集没有任何更改,则不会重新构建它。也不会删除任何中间文件。
最常用的。
重新构建解决方案——无论发生什么更改,都重新构建所有程序集,但保留中间文件。
当您注意到Visual Studio没有将您的更改合并到最新程序集中时使用。有时候Visual Studio也会犯错误。
清洁解决方案-删除所有中间文件。
当一切都失败,你需要清理一切,重新开始时使用。