LNK2022 and LNK2034 linker errors with version 10.0 of the CRT

Question

Sorry to bother anyone with this question, but I\'ve been researching this for hours, with no resolution yet:

I am porting a rather massive application to the 10.0 C

Answer 1

I recently migrated a VS2008 project to VS2012 that included a C++/cli project and experienced these errors. I'm pretty anal retentive when it comes to my project/build files so I setup some custom .props msbuild files that the projects all import from (to avoid all the repeated and Condition riddled elements in the msbuild XML).

So pretend the project was Example.vcxproj. and near the start I had this:

<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
<PropertyGroup Label="Configuration">
  <ConfigurationType>DynamicLibrary</ConfigurationType>
  <PlatformToolset>v110_xp</PlatformToolset>
  <CharacterSet>Unicode</CharacterSet>
  <CLRSupport>true</CLRSupport>
  <-- Including this here fixed my linker problems -->
  <!--<TargetFrameworkVersion>v3.5</TargetFrameworkVersion>-->
</PropertyGroup>
...
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" />
...
<Import Project="$(SolutionDir)..\shared\config\msbuild\FileWithCommonSettings.props" />

I had my FileWithCommonSettings.props file (where I have -TargetFrameworkVersion- defined) being included -after- Microsoft.Cpp.props. I instead opted to try setting -TargetFrameworkVersion- before Cpp.props, as you can see in the commented out XML. Doing this fixed all the linker issues I was getting. My guess is that Cpp.Default.props defaults to v4.0 in VS2010 and later.

Hope this helps

edit: Refering to this social.msdn thread, it would appear you need to use VS2010 (ie, toolset v100) in order to actually target v3.5. I didn't realize I was silently targeting 4.0 still with vc110...but it was only after I added that -TargetFrameworkVersion- element did I get rid of the linker errors. After switching to vc100 toolset the linker errors came back.

Answer 2

Although my solution to this issue does not address why it happens, I'm noting my observations in case anyone else comes across my same scenario.

I too received similar errors compiling my clr project. My goal was to upgrade my version to 11.0, but retain .NET framework 2.0 as the target. In my case, I saw Lnk2034 and lnk2020 errors (different from the lnk2022 noted above).

1>MSVCMRTD.lib(locale0_implib.obj) : error LNK2034: metadata inconsistent with COFF symbol table: symbol '?_Facet_Register_m@std@@$$FYAXPAV_Facet_base@1@@Z' (06000068) has inconsistent metadata with (0A000C23) in DirectSystemAccessProxy.obj
1>LINK : error LNK2034: metadata inconsistent with COFF symbol table: symbol '??3@$$FYAXPAX@Z' (060003CB) has inconsistent metadata with (0A00009D) in MSVCMRTD.lib(locale0_implib.obj)
...
1>myProject.obj : error LNK2020: unresolved token (0A000C23) "void __cdecl std::_Facet_Register_m(class std::_Facet_base *)" (?_Facet_Register_m@std@@$$FYAXPAV_Facet_base@1@@Z)
1>MSVCMRTD.lib(locale0_implib.obj) : error LNK2020: unresolved token (0A0000C4) "extern "C" void __cdecl free(void *)" (?free@@$$J0YAXPAX@Z)
...

Initially, I was following Hans Passat's advice by correcting the use of the native containers in this project. I commented out all instances of those containers to verify that they were indeed the cause of failure.

During the investigation, I discovered that the following line caused my error:

std::wstringstream wstream;
wstream << " Failed to to do something \'" << var << "\'.";

The moment I corrected it to the following, those errors went away.

std::wstringstream wstream;
wstream << L" Failed to to do something \'" << var << L"\'."; // Added wide string literal.

No idea why such a line would cause this behaviour, but it did.

Side Note:

• Targeting a higher .NET framework (4.0) also worked, but I wanted to stick to target the original .NET framework of 2.0.
• My project did not have the preprecossor definition: _HAS_ITERATOR_DEBUGGING = 0. To my understanding, compiling _HAS_ITERATOR_DEBUGGING in /clr is no longer supported (See link in Hans Passat's answer)

Answer 3

In my case what helped was changing the TargetFramework in the .VCXPROJ to :

<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>

But as you've mentioned you need to compile against 3.5 I am not sure what you can do in that case.

Answer 4

This is a hard to diagnose problem, the linker errors stink and are poorly documented. There's a post from Stephan Lavavej, the STL maintainer at Microsoft about it in this thread, bottom of the page. I have to say I don't see much of any advice in it, beyond trying to disable iterator debugging in your project settings (_HAS_ITERATOR_DEBUGGING = 0 in the preprocessor definitons).

You do need to consider a code review. It sure looks like you are compiling STL code into managed code. That works in general (minus the linker hassle) but it is really the wrong thing to do. Leave the STL collection classes to your native code, use the BCL collection classes (List<> etc) in your managed code.

Answer 5

for anyone like me that this answer did not ring helpful, a second option is to go to: Project Properties->Configuration Properties->General->Project Defaults->.NET Target Framework Version and set it to v4.0

https://connect.microsoft.com/VisualStudio/feedbackdetail/view/806238/unwarranted-linker-errors-using-stl-filestream-class-in-managed-classes-in-c-11-cli has an obscure answer from Microsoft team that fixed my issue.