我一直教导自己和其他人将 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 目录。
此外,拥有引用位置可以让您在一个地方更新解决方案中项目集合的引用。 对我来说,这是一个非常自然的结构。
我认为 bin 文件夹是暂时的,它是完整工作的已编译应用程序所在的位置。
我们将任何外部程序集放置在名为程序集的目录中。许多其他人使用名为 lib 的目录。这将编译应用程序所需的内容与已编译的应用程序本身分开。
我不知道你是否疯了,但我们在我上一个工作的地方遵循了同样的做法,并且我把它们带到了我自己的工作中。 /bin 和 /obj 文件夹不在版本控制范围内,我从未接触过。就我而言,在开发过程中它们基本上不存在。所有包含的 DLL 都位于另一个文件夹中并被引用。