未解決の外部シンボルVC9コンパイラのシンボル名の不一致が原因 をリンクしようとしたとき、私は次のエラーメッセージを見ている

Question

同じソリューション内の別のに対して、一つのプロジェクトでライブラリ：「DUMPBIN /シンボルを使用して

CPTemplate.obj : error LNK2019: unresolved external symbol "public: long __thiscall MPADOFieldList::GetField(wchar_t *,struct Field * *)" (?GetField@MPADOFieldList@@QAEJPA_WPAPAUField@@@Z) referenced in function "public: virtual long __stdcall CCPTemplate::GetRootStorage(struct IMPRootStore * *)" (?GetRootStorage@CCPTemplate@@UAGJPAPAUIMPRootStore@@@Z) 

GetFieldの「私は反対 をリンクしています静的ライブラリには、のために異なるシンボルを明らかにする 『：ADOField『『対』フィールド』メソッドを

?GetField@MPADOFieldList@@QAEJPA_WPAPAUADOField@@@Z (public: long __thiscall MPADOFieldList::GetField(wchar_t *,struct ADOField * *)) 

明らかに違いがあります』。 「フィールドは、」参照ヘッダ内 定義される：

typedef interface ADOField Field; 

次のように「GetFieldの」メソッドの宣言がある：

HRESULT GetField(BSTR bstrFieldName, Field** rpField); 

Answer 1

これはダウンの2つのいずれかにほぼ確実であり、eithertheのtypedef条件付きであり、libの場合は1つの分岐をとり、メインプロジェクトではもう一方の分岐をとります。しかし、タイプがメインプロジェクトのFieldを解決するので、私はもっと説得力のある理論を持っています。 GetField宣言を含むヘッダーにはFieldの前方宣言がありますが、typedefはこのTUではまったく見られませんので、他の場所で定義される型（最初のリンクを引き起こす）とみなされます。しかし、ライブラリではtypedefが見られ、正しく解決されてADOFieldになり、不一致が発生します。解決方法は、CCPTemplate::GetRootStorageの定義を含むTU内にtypedefがあることを確認することです。