假设我们有一个具有以下结构的解决方案:
Project.DAL - 数据访问层,取决于较低级别的库,例如Oracle.DataAccess w/copy local = true
Project.BLL - 业务逻辑层,将Project.DAL引用为项目
Project.UI - UI层,编译为可执行文件,引用Project.BLL,默认项目
编译Project.UI时,VS非常聪明,可以将Project.DAL.dll复制到输出目录,但是它不够聪明,我想要将Oracle.DataAccess复制到输出目录以及分发给客户端.
任何人都可以解释为什么会这样吗?是因为它在GAC中看到Oracle.DataAccess并假设客户端也会在GAC中拥有它吗?
这并不是什么大不了的事,但每次添加新的程序集引用时都有点烦人,我必须记住将其设置为复制本地并添加项目以在我的构建脚本中复制它.
还有一件事.
如果您根本不在代码中使用引用的DLL,它将忽略CopyLocal并且不会将其复制到您的输出目录.
是的,Visual Studio将在以下两个条件中的任何一个条件下将DLL复制到输出路径:
使用CopyLocal = true显式引用DLL
DLL没有CopyLocal或通过其他一些引用的DLL隐式引用,并且不在GAC中
当文件在GAC中时,它不会复制本地的原因是,在解析程序集名称时,GAC具有最高优先级,即即使您有(不同的)本地副本,也将使用GAC中的版本.
我建议你设置一个库目录,在其中放置所引用的所有外部程序集.然后在没有Oracle文件gac的计算机(或VM)上设置自动MSBuild脚本(为此不安装Visual Studio).这样,文件将被复制到构建中,并且您将比使用VS时更多地控制所执行的操作.
我有一个奇怪的情况,即使程序集是一个项目引用,并在引用属性窗口中显示"复制本地"并显示为"True",DLL也没有被复制到输出目录.我在GAC中有一个早期版本的DLL,但我不明白为什么这会阻止DLL被复制.
我发现通过卸载项目并手动编辑项目引用XML,如下所示:
{11111111-1111-1111-1111-111111111111} Some Project Name True
DLL按预期复制到输出目录.我发现只是在属性窗口中将Copy Local设置为True意味着该
元素完全丢失,但是如果它被设置为false,则它的值为"False".