我一直教导自己和其他人将 bin 文件夹视为临时文件夹。
也就是说，您应该能够删除它，并且下次重建它时会重新创建它，并且任何引用都会毫不费力地复制到其中，而且不要将所有鸡蛋放在一个篮子里。或者在这种情况下，不要将所有需要的 dll 直接放入 bin 文件夹中。将它们放在别处并参考它们。
我见过人们在将 dll 直接放入 bin 文件夹并在那里引用它们时摔倒了。所以我尽量避免这种情况，并将所有需要的 dll 放在一个名为 Refs 的文件夹中，并在其中添加对 dll 的引用。在编译时，它们无论如何都会被复制到 bin 文件夹中。
我疯了吗？这是不是太小心了？常识？
在这种情况下，最佳做法是什么？
干杯，
——李
更新：原来我没有生气
干杯家伙，你已经拿起了一些我忘了提到的观点。
主要是：
没错，您不想将引用的 dll 放在bin文件夹中。如果您使用版本控制，则应始终完全排除 bin 和 obj 文件夹。
所有引用的 dll 都应包含在版本控制下，最好是在项目的trunk. bin文件夹必须很容易地从头开始重新创建。
这是我相信大多数人在查看您的来源时会期望的。
我们还在_READ_ME.txt项目的根目录中包含一个文件，说明有关批量构建项目所需的工具和东西的附加信息（nant、perl等），因此有时可能会有一些特定的差异，但绝不会让人感到意外种类。
不，这完全有道理，是我自己在个人项目中实施的一种做法。bin 文件夹下的任何内容都应视为 msbuild / Visual Studio 环境的属性。
虽然他们都非常注意只删除他们知道的输出，但用户可能不完全理解什么是构建输出并复制构建输出，因此在“清理”样式操作期间将其删除。其他工具也可能在清理 DLL 时更加积极。如果我认为构建过程正在查看陈旧数据，我自己倾向于不时对 bin 目录进行核对。
此外，拥有 ref 的位置为您提供了一个单一位置来更新解决方案中项目集合的引用。对我来说，这是一个非常自然的构造。
我认为 bin 文件夹是临时的，它是完整工作编译应用程序的地方。
我们将任何外部程序集放在一个名为 Assemblies 的目录中。许多其他人使用名为 lib 的目录。这将编译应用程序所需的东西与已编译的应用程序本身分开。
我不知道你是不是疯了，但我们在我工作的最后一个地方遵循了同样的做法，我已经把它们带到了我自己的工作中。/bin 和 /obj 文件夹不在版本控制范围内，我从未接触过。就我在开发过程中所关心的而言，它们基本上不存在。所有包含的 DLL 都位于另一个文件夹中并被引用。