I have successfully upgraded an MFC application which was compiled with an old version of Developer Studio to Visual Studio 2008. A very small number of changes were needed because of some breaking changes in MFC. Now that everything works, I’d like to take the next step and compile the solution with /clr.
To do so, I have found useful information on the MSDN web site:
Here are the steps I have taken:
- Set the Runtime Library to Multi-threaded Debug DLL (/MDd).
- Set the Use of MFC to Use MFC in a Shared DLL.
However, doing so prevents me from linking the project:
-
The reference to
afxDatacan no longer be resolved; somehow,afxDatais only visible when linking statically against MFC. In my code, I have the following declaration:extern AFX_DATA AUX_DATA afxData;which works fine with the statically linked MFC version.
-
The references to
_afxThreadStateand_afxWinStatecannot be resolved either.
Here are the full error messages :
error LNK2001: unresolved external symbol "struct AUX_DATA afxData" (?afxData@@3UAUX_DATA@@A)
error LNK2001: unresolved external symbol "class CThreadLocal<class _AFX_THREAD_STATE> _afxThreadState" (?_afxThreadState@@3V?$CThreadLocal@V_AFX_THREAD_STATE@@@@A)
error LNK2001: unresolved external symbol "class CProcessLocal<class _AFX_WIN_STATE> _afxWinState" (?_afxWinState@@3V?$CProcessLocal@V_AFX_WIN_STATE@@@@A)
in case this might be related to the name mangling…
So, what can I do in order to dynamically link against MFC, but still reference afxData, _afxThreadState and _afxWinState?
When using MFC in a shared DLL, AUX_DATA must be
dllimported.For thread state, rather than using template classes, use one of these
Depending on the state information you require. For example, see here for some members that were moved to module state to fix a bug. Note that AfxGetModuleThreadState exists but is undocumented and could be changed in a future version.
Win state does not ring a bell, how is it used? There is probably a new way to accomplish it.