您不应该将bin文件夹视为瞬态文件吗？

Question

我总是教自己和其他人把bin文件夹想象成瞬态的。

那就是你应该能够删除它，下次你重建时它会被重新创建并且任何引用都会被复制到它中而不会有任何麻烦而且不能将你的鸡蛋全部放在一个篮子里。或者在这种情况下，不要将所有必需的dll直接放入bin文件夹中。把它们放在别处，然后引用它们。

我看到有人在将dll直接放入bin文件夹并在那里引用时会掉下来。因此，我尝试避免这种情况，并将所有必需的dll放在名为Refs的文件夹中，并在那里添加对dll的引用。在编译时，无论如何它们都将被复制到bin文件夹中。

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

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

干杯，

- 李

更新：原来我不是疯了

在你忘记提及的一些观点上，你已经找到了干杯。

主要是：

• 未将bin文件夹检入源代码管理

Answer 1

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

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

我认为大多数人在检查您的来源时期望。

我们还在项目的根目录中包含一个_READ_ME.txt文件，说明批量构建项目所需的工具和内容的其他信息（nant，perl等） ，因此可能会不时出现一些具体的差异，但这种情况从未出现意外。

Answer 2

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

虽然他们都非常谨慎地只删除他们所知道的输出，但是用户可能无法完全理解构建输出是什么并复制到构建输出，因此在“清理”样式操作期间将其删除。在清理DLL时，其他工具也可能更具侵略性。如果我认为构建过程正在查看陈旧数据，我自己会不时地对bin目录进行核对。

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

Answer 3

我认为bin文件夹是瞬态的，它是完整工作的编译应用程序的地方。

我们将任何外部程序集放在名为Assemblies的目录中。许多其他人使用名为lib的目录。这分离了从编译应用程序本身编译应用程序所需的东西的想法。

Answer 4

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