LNK2019 error in VS6.0 -> VS2013 migrated MFC DLL project

Question

I get the following link error when attempting to build/port a LARGE VS6.0 DLL project to VS2013 where DLL modules are dependent on other DLL modules. The unique thing about the undefined function is that it takes CString arguments, but perhaps the problem is more obvious than that:

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)

Here is the dumpbin.exe for this module where the symbol is exported (from the *.exp file):

 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

Here is the dump from the *.lib file and I see __imp_ in the *.lib file.

     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

Of course I need to triple check again that I'm reading this exact .exp/ .lib which is what /Verbose tells me.

In this particular case, all the issue(s) I have are cases where DLL "x" references a function in DLL "y" which has a CTokenEx::Split() function which has CString arguments. I thought that the problem was the CSTring MFC vs ATL declaration (see links below), now I'm not so sure, so am going back to square one after posting this here. (ie is it a typo I missed? DOH?)

I've done the following to isolate the problem Build properties:

1. Verified all modules are using MBCS (Multi Byte Char Set) not Unicode
   
2. Verified all modules are building with "Using MFC in a DLL"
3. Run the linker with /Verbose and Verbose:lib to verify the linker was referencing the linked file I expected.
4. Used dumpbin.exe to examine the exported symbol decorations to see if they are getting exported. (I think they are, but I'm not a dumpbin expert).
5. Found these possibly related links:
   MSDN LNK2019 error and attempted to hardcode the dllimport of the CString type.
   link with respect to MFC and CRT CSTring definitions. Not 100% sure this is the issue. (could be something I'm missing in the arguments.)
   
6. included "afxstr.h", and forced -D"_MFC_DLL_BLD"

The CTokenEx portion of the DLL module I'm working with appears to be from here but I haven't confirmed it. At the moment, I'm not sure that is relevant.

I'm just looking for confirmation that my analysis of dumpbin.exe which tells me the symbols are exported correct is accurate. I thought it could be a link-order issue, and referenced the DLL a second time to the linker, but that didn't help. In a past life that worked in similar linker issues in SunOs (back in ancient times).

If I figure this one out, I will post an answer to this problem.

Answer 1

!DOH! After you have eliminated all other options. . Although using /Verbose and /Verbose:lib show you where the *.lib files are, and confirms they are found, you must pay attention! In my case, there were some VS6.0 STALE *.lib files in "." relative to the solution workspace and the linker found those first, and of course they likely didn't have the symbols properly decorated. If the linker tells you that it linked in:
mylib.lib instead of
path\\to\\Mylib.lib it's a major clue :).

Sooo... what I thought was a complex & strange linker problem. Was a !DOH! easy linker problem.

Problem solved, just that simple.