VS6.0中的LNK2019错误-> VS2013迁移的MFC DLL项目

Question

尝试将大型VS6.0 DLL项目构建/移植到VS2013时，出现以下链接错误，其中DLL模块依赖于其他DLL模块。 未定义函数的独特之处在于它带有CString参数，但问题可能比这更明显：

error LNK2019: unresolved external symbol "__declspec(dllimport) public: void __thiscall CTokenEx::Split(class ATL::CStringT<char,class StrTraitMFC_DLL<char,class ATL::ChTraitsCRT<char> > >,class ATL::CStringT<char,class StrTraitMFC_DLL<char,class ATL::ChTraitsCRT<char> > >,class CStringArray &,int)" (__imp_?Split@CTokenEx@@QAEXV?$CStringT@DV?$StrTraitMFC_DLL@DV?$ChTraitsCRT@D@ATL@@@@@ATL@@0AAVCStringArray@@H@Z) referenced in function "public: bool __thiscall OptionFlag::isTestEnableByFlag(class ATL::CStringT<char,class StrTraitMFC_DLL<char,class ATL::ChTraitsCRT<char> > >)" (?isTestEnableByFlag@OptionFlag@@QAE_NV?$CStringT@DV?$StrTraitMFC_DLL@DV?$ChTraitsCRT@D@ATL@@@@@ATL@@@Z)

这是此模块（从* .exp文件中）导出符号的模块的dumpbin.exe：

 00000148  DIR32NB                    00000000        20  $N00027
 00000094  DIR32NB                    00000000        4F  ?Split@CTokenEx@@QAEXV?$CStringT@DV?$StrTraitMFC_DLL@DV?$ChTraitsCRT@D@ATL@@@@@ATL@@0AAVCStringArray@@H@Z (public: void __thiscall CTokenEx::Split(class ATL::CStringT<char,class StrTraitMFC_DLL<char,class ATL::ChTraitsCRT<char> > >,class ATL::CStringT<char,class StrTraitMFC_DLL<char,class ATL::ChTraitsCRT<char> > >,class CStringArray &,int))
 0000014C  DIR32NB                    00000000        21  $N00028

这是* .lib文件的转储，我在* .lib文件中看到__imp_。

     3E30 ?Split@CTokenEx@@QAEXV?$CStringT@DV?$StrTraitMFC_DLL@DV?$ChTraitsCRT@D@ATL@@@@@ATL@@0AAVCStringArray@@H@Z
     3E30 __imp_?Split@CTokenEx@@QAEXV?$CStringT@DV?$StrTraitMFC_DLL@DV?$ChTraitsCRT@D@ATL@@@@@ATL@@0AAVCStringArray@@H@Z

当然，我需要再次三倍检查我读这个确切.EXP / .LIB这是什么功能/ verbose告诉我。

在此特定情况下，我遇到的所有问题都是DLL“ x”引用DLL“ y”中具有CTokenEx :: Split（）函数且具有CString参数的函数的情况。 我以为问题是CSTring MFC vs ATL声明（请参见下面的链接），现在我不太确定，因此在此发布后回到第一点。 （即我错过了错字吗？DOH？）

我已完成以下操作以隔离问题Build属性：

1. 验证所有模块都使用MBCS（多字节字符集）而不是Unicode
   
2. 验证所有模块是否都在使用“在DLL中使用MFC”构建
3. 使用/ Verbose和Verbose：lib运行链接器，以验证链接器正在引用我期望的链接文件。
4. 使用dumpbin.exe检查导出的符号装饰，以查看它们是否正在导出。 （我认为是的，但我不是垃圾桶专家）。
5. 找到了这些可能相关的链接：
   MSDN LNK2019错误，并尝试对CString类型的dllimport进行硬编码。
   有关 MFC和CRT CSTring定义的链接。 并非100％确定这是问题所在。 （可能是我在参数中缺少的东西。）
   
6. 包括“ afxstr.h”和强制-D“ _MFC_DLL_BLD”

我正在使用的DLL模块的CTokenEx部分似乎来自此处，但我尚未确认。 目前，我不确定是否相关。

我只是想确认我对dumpbin.exe的分析是否正确，该分析告诉我符号正确输出。 我认为这可能是链接顺序问题，并且第二次将DLL引用到链接器，但这没有帮助。 在过去的生活中，SunOs曾在类似的链接器问题中工作（追溯到远古）。

如果我解决了这个问题，我将发布此问题的答案。

Answer 1

！DOH！ 消除所有其他选项之后。 。 尽管使用/ Verbose和/ Verbose：lib会向您显示* .lib文件的位置，并确认已找到它们，但您必须注意！ 就我而言，“。”中有一些VS6.0 STALE * .lib文件。 相对于解决方案工作区，链接器首先找到了那些，当然，它们可能没有正确装饰符号。 如果链接器告诉您它已链接：
mylib.lib而不是
path \\ to \\ Mylib.lib这是一个主要线索:)。

太...我以为是一个复杂而奇怪的链接器问题。 是！DOH！ 简单的链接器问题。

问题解决了，就这么简单。