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！ 簡單的鏈接器問題。

問題解決了，就這么簡單。