我一直教导自己和其他人将 bin 文件夹视为暂时的。
也就是说，您应该能够删除它，下次重建时会重新创建它，并且任何引用都会毫无麻烦地复制到其中，而不是把鸡蛋都放在一个篮子里。或者在这种情况下，不要将所有必需的 dll 直接放入 bin 文件夹中。将它们放在其他地方并引用它们。
我见过有人在将 dll 直接放入 bin 文件夹并在那里引用它们时摔倒。因此，我尝试避免这种情况，并将所有需要的 dll 放在名为 Refs 的文件夹中，并在其中添加对 dll 的引用。无论如何，在编译时它们都会被复制到 bin 文件夹中。
我疯了吗？这也太小心了吧？常识？
这种情况下的最佳实践是什么？
更新：原来我没有生气
干杯，你们在我忘记提及的一些问题上得到了启发。
主要：
没错，您不想将引用的dll放在
bin所有引用的 dll 应包含在版本控制下，最好位于项目的
trunkbin我相信大多数人在查看您的来源时都会期望。
我们还在项目的根目录中包含一个
_READ_ME.txtnantperl不，这是完全有道理的，并且是我自己在个人项目中实施的实践。 bin 文件夹下的任何内容都应被视为 msbuild / Visual Studio 环境的属性。
虽然他们都非常小心地只删除他们知道的输出，但用户可能无法完全理解什么是构建输出并复制构建输出，从而在“干净”风格的操作期间将其删除。 其他工具也可能更积极地清除 DLL。 如果我认为构建过程正在查看过时的数据，我自己倾向于不时地破坏 bin 目录。
此外，拥有引用位置可以让您在一个地方更新解决方案中项目集合的引用。 对我来说，这是一个非常自然的结构。
我认为 bin 文件夹是暂时的，它是完整工作的已编译应用程序所在的位置。
我们将任何外部程序集放置在名为程序集的目录中。许多其他人使用名为 lib 的目录。这将编译应用程序所需的内容与已编译的应用程序本身分开。
我不知道你是否疯了，但我们在我上一个工作的地方遵循了同样的做法，并且我把它们带到了我自己的工作中。 /bin 和 /obj 文件夹不在版本控制范围内，我从未接触过。就我而言，在开发过程中它们基本上不存在。所有包含的 DLL 都位于另一个文件夹中并被引用。