通常,项目依赖是为了解决编译顺序问题,以便于底层代码更改后,上层代码可以自动被编译,从而减少代码不一致导致的错误.
VS2010的项目依赖,在.Net的模块中,自动跟"框架和引用"画上了等号.因此,我设置了项目依赖,底层的DLL就自动被添加到了项目引用中,从项目引用中删除了对应的DLL,则项目依赖也自动删除了.
问题是:为了发布方便,debug和release的输出目录不是同一个目录,因此,VS2010就老出 "LNK2022： 元数据操作失败 （80131187）"错误,我猜测就是vs2010总是搞混淆debug和release目录的dll导致的.这个LNK2022非常的恶心的,哪怕修改.cpp一个空格,再编译都可能出,而且,一旦出了,就只有rebuild
all才能解决.
不烦其扰后,去掉了项目依赖,得,好!
#using "dll"
又不识别dll存在修改了.我只好手工一个一个的编译.
最要命的是,就算存在项目依赖,存在正确的DLL的引用,其代码还是偶尔不能反映源文件的修改,还是需要程序员的黑魔法----rebuild all才能解决.这个问题不仅仅存在C++/CLI中,貌似也扩散到了纯C++的项目中.
LNK2022： 元数据操作失败 （80131187）貌似在VS2005就频繁发生了.到现在MS也没有刻意要解决的样子
LNK2022补充:我是在被这个东西干扰得不行了,在MS的网站寻摸了半天,无果----无非都是很客气的公式化的回答.然后又上google寻摸半天,找到一个比较靠普点的答案:禁用增量编译.测试中,不知道结果如何