您是否使用源代码管理?
这条评论听起来像你没有:
归档时,这些是不需要的兆字节。
(“存档”听起来有点像定期将整个项目文件夹复制到backup_yyyymmdd之类的东西)
如果您不使用源代码管理,则应明确考虑开始使用它。
除了一般优势(例如,具有日期和 cmets 的更改历史......)之外,它还为您的 obj 文件夹问题提供了一个开箱即用的解决方案:
所有优秀的源代码控制软件都支持忽略您可以定义的某些文件或文件夹(忽略意味着:它们永远无法提交到源存储库,您甚至不会在更改的文件列表中看到它们,甚至当它们被改变时)。
例如,在Mercurial(我使用)中,忽略设置保存在主文件夹中名为.hgignore 的文件中(Git 也一样,只是称为.gitignore)。
我所有 Visual Studio 项目的默认 .hgignore 文件如下所示:
syntax: glob
bin
obj
*.suo
*.user
第一行属于 Mercurial 的忽略语法,其余为忽略的设置。
可以看到bin 和obj 文件夹被忽略了……无论在哪个子文件夹中都被忽略了!
所以我不必关心 obj 文件夹的实际位置,也不必在每次构建解决方案时手动删除它们。它们在我的源代码管理历史中根本不存在。
另外,关于将所有内容放在一个输出文件夹中,我对 Fuji 的回答有所不同:
我也喜欢这样做,但我更喜欢在 Visual Studio 的项目设置中更改输出文件夹,而不是使用构建后事件。
默认输出文件夹为:
我把它们改成:
..\build\Debug\
..\build\Release\
这会将所有内容编译到 build 文件夹的子文件夹中,该文件夹与 .sln 文件处于同一级别(这意味着:解决方案中的所有项目都直接编译到同一文件夹中)。
它还减少了编译时间,因为 Visual Studio 不必在编译后复制所有依赖项(因为所有内容都已经在在同一个文件夹中)。
(我这样做主要是因为编译时间,因为如上所述我忽略了 Mercurial 中的 bin 和 obj 文件夹,所以我不在乎它们实际上在哪里)