您不应该将 bin 文件夹视为暂时的吗？答案

【问题标题】：Shouldn't you treat the bin folder as being transient?您不应该将 bin 文件夹视为暂时的吗？
【发布时间】：2010-12-06 00:58:06
【问题描述】：

我一直教导自己和其他人将 bin 文件夹视为暂时的。

也就是说，您应该能够删除它，并且下次重建时会重新创建它，并且任何引用都会轻松复制到其中，而且不要将所有鸡蛋放在一个篮子里。或者在这种情况下，不要将所有需要的 dll 直接放入 bin 文件夹中。将它们放在别处并参考它们。

当人们将 dll 直接放入 bin 文件夹并在那里引用它们时，我已经看到人们摔倒了。所以我尽量避免这种情况，并将所有需要的 dll 放在一个名为 Refs 的文件夹中，并在其中添加对 dll 的引用。在编译时，它们无论如何都会被复制到 bin 文件夹中。

我疯了吗？这是不是太小心了？常识？

这种情况下的最佳做法是什么？

干杯，

--李

更新：原来我没有生气

大家好，我忘了提一些观点。

主要是：

【问题讨论】：

【解决方案1】：

没错，您不想将引用的 dll 放在 bin 文件夹中。如果您使用版本控制，则应始终完全排除 bin 和 obj 文件夹。

所有引用的 dll 都应包含在版本控制之下，最好是在项目的 trunk 下的单独子目录中，以便每个人都拥有每次干净重建所需的所有资源和引用。 bin 文件夹必须轻松地从头开始重新创建。

我相信大多数人在查看您的来源时会期待。

我们还在项目的根目录中包含一个_READ_ME.txt 文件，说明有关批量构建项目所需的工具和资料的附加信息（nant、perl 等），因此可能会有一些不时会有具体的差异，但绝不会出现这种意外。

【讨论】：

【解决方案2】：

不，这完全有道理，是我自己在个人项目中实施的一种做法。 bin 文件夹下的任何内容都应视为 msbuild / Visual Studio 环境的属性。

虽然他们都非常注意只删除他们知道的输出，但用户可能不完全了解什么是构建输出并复制构建输出，因此在“清理”样式操作期间将其删除.其他工具也可能在清理 DLL 时更加积极。如果我认为构建过程正在查看陈旧数据，我自己倾向于不时对 bin 目录进行核对。

此外，拥有一个引用的位置为您提供了一个单一的位置来更新解决方案中项目集合的引用。对我来说，这是一个非常自然的结构。

【讨论】：

【解决方案3】：

我认为 bin 文件夹是临时的，它是完整工作的已编译应用程序所在的位置。

我们将任何外部程序集放在一个名为 Assemblies 的目录中。许多其他人使用名为 lib 的目录。这将编译应用程序所需的东西与编译后的应用程序本身分开。

【讨论】：

【解决方案4】：

我不知道你是不是疯了，但我们在我工作的最后一个地方遵循了相同的做法，我已经把它们带到了我自己的工作中。 /bin 和 /obj 文件夹不在版本控制范围内，我从未接触过。就我在开发过程中所关心的而言，它们基本上不存在。所有包含的 DLL 都位于另一个文件夹中并被引用。

【讨论】：