我一直教导自己和其他人将bin文件夹视为瞬态文件。不应该将bin文件夹视为瞬态文件吗？
这就是你应该能够删除它，下次你重建它会得到重新创建和任何引用复制到它没有任何麻烦而不是把你的鸡蛋都放在一个篮子里。或者在这种情况下，不要将所有必需的dll直接放到bin文件夹中。有他们在其他地方，只是参考他们。
我见过有人在将dll直接放入bin文件夹并在那里引用时掉下来。所以我尽量避免这种情况，并将所有我需要的dll放在名为Refs的文件夹中，并在其中添加对dll的引用。在编译时，它们将被复制到bin文件夹中。
我疯了吗？这是否过于谨慎？常识？
这种情况下的最佳做法是什么？
干杯，
- 李
更新：原来我是不是疯了你拿起一些问题上我忘了提
干杯家伙。
主要是：
没错，你不要想把参考dll放在bin文件夹中。如果您使用版本控制，则应始终完全排除bin和obj文件夹。
所有引用的dll都应该包含在版本控制之下，最好在项目的trunk下的单独子目录中，以便每个人都有每个干净重建所需的所有源和引用。 bin文件夹必须轻松从头开始重新创建。
这是我相信大多数人会检查您的来源期望。
我们还包括一个_READ_ME.txt文件中项目的根，注明需要批量生成项目（nant，perl等）工具和东西的附加信息，所以有可能是从时间到一些特定的差异时间，但从来没有这种惊喜。
'bin和obj文件夹应始终完全排除在外+1'。 – 2009-10-12 16:58:14
没有这使得完整意义上的，是我自己在个人项目实施的做法。 bin文件夹下的任何内容都应该视为msbuild/Visual Studio环境的属性。
虽然他们都非常小心只删除他们知道的输出，但用户可能无法完全理解构建输出是什么并复制到构建输出上，并因此在“Clean”样式期间将其删除操作。在清理DLL的时候，其他工具也可能会更积极。如果我认为构建过程正在查看陈旧的数据，我自己往往会不时刻造bin目录。
此外，有一个ref的位置给你一个地方来更新解决方案中的项目集合的引用。对我来说这是一个非常自然的构造。
我不知道你是否疯了，但我们在最后的工作地点遵循了相同的做法，并且把它们带到了我自己的工作中。/bin和/ obj文件夹在版本控制之外，并且我从来没有碰过。就发展过程而言，它们基本上不存在。所有包含的DLL坐在另一个文件夹中并被引用。
我认为bin文件夹是暂时的，它是完整工作编译应用程序去的地方。
我们将所有外部装配放在名为装配的目录中。许多其他人使用一个名为lib的目录。这将编译应用程序本身所需的某些东西分离出来。
我觉得同样的方式，总是把我的DLL直接放在项目文件夹中。 Visual Studio使用项目根作为刷新路径，所以如果我更新我的DLL，引用不会中断。 – 2009-10-12 16:16:19