Lee*_*one 17 .net c# compiler-construction building
我总是教自己和其他人把bin文件夹想象成瞬态的.
那就是你应该能够删除它,下次你重建时它会被重新创建并且任何引用都会被复制到它中而不会有任何麻烦而且不能将你的鸡蛋全部放在一个篮子里.或者在这种情况下,不要将所有必需的dll直接放入bin文件夹中.把它们放在别处,然后引用它们.
我看到人们在将dll直接放入bin文件夹并在那里引用它们时会掉下来.因此,我尝试避免这种情况,并将所有必需的dll放在名为Refs的文件夹中,并在那里添加对dll的引用.在编译时,无论如何它们都将被复制到bin文件夹中.
我疯了吗？这太小心了吗？常识？
这种情况下的最佳做法是什么？
干杯,
- 李
更新:结果我不生气
在你忘记提及的一些观点上,你已经找到了干杯.
主要是:
Gro*_*roo 19
这是正确的,你不希望把所引用的dll的bin文件夹中.如果您使用的是版本控制,则应始终完全排除bin和obj文件夹.
所有引用的dll都应该包含在版本控制之下,最好是在项目下的一个单独的子目录中trunk,这样每个人都有每个干净重建的所有必要的源和引用.bin必须从头开始重新创建文件夹.
那是,我相信大部分人都会的东西希望检查出你的源代码.
我们还包括一个_READ_ME.txt在该项目的根文件,注明的工具和材料的附加信息需要批量生成项目(nant,perl这等),所以有可能会不时一些具体差异,但从来没有惊喜类.
Jar*_*Par 16
这不是完全合理的,而是我自己在个人项目上实施的一种做法.bin文件夹下的任何内容都应被视为msbuild/Visual Studio环境的属性.
虽然他们都非常谨慎地只删除他们所知道的输出,但是用户可能无法完全理解构建输出是什么并复制到构建输出,因此在"清理"样式操作期间将其删除.在清理DLL时,其他工具也可能更具侵略性.如果我认为构建过程正在查看陈旧数据,我自己会不时地对bin目录进行核对.
此外,具有ref的位置为您提供了一个单独的位置来更新解决方案中的项目集合的引用.对我来说,这是一个非常自然的结构.
我认为bin文件夹是瞬态的,它是一个完整工作的编译应用程序的地方.
我们将任何外部程序集放在名为Assemblies的目录中.许多其他人使用名为lib的目录.这分离了从编译应用程序本身编译应用程序所需的东西的想法.