Lnk2022 Metadata Operation: Inconsistent Layout Information in Duplicated Types

LNK2022 metadata operation: Inconsistent layout information in duplicated types

Alright, so I solved it! There was another SO question that was actually a big help. It ended up linking to this article, which had a bit more detail about the problem. Basically it's some issue with the standard library strings getting compiled in both managed and unmanaged code. The solution was to only enable the CLR on files which required it. In detail, here's what I did:

  1. Removed the /clr switch which applied to the whole project
  2. Selected the two .cpp files that actually required the CLR, and manually selected /clr under C/C++ -> General -> Common Language RunTime Support.
  3. Switched the whole project to Program Database /Zi from Program Database for Edit and Continue /ZI. This got rid of warnings, because I think /clr support appeared to disable incremental linking, and then my native code was throwing warnings because it was trying to use Edit and Continue.
  4. I then got some ExtensionAttribute warnings, which I fixed by adding the following switches to my /clr-enabled files: /clr:nostdlib /AI"%ProgramFiles%\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0"
  5. In Debug builds, I had to disable a bunch of debug options on the /clr-enabled files. Specifically, under C/C++ -> Code Generation, I set Enable Minimal Rebuild to No (/RM-), and Basic Runtime Checks to Default. This got rid of a bunch of warnings also.
  6. In Debug and Release builds, set Enable C++ Exceptions to No on the clr-enabled files.

Hope this helps!

Inconsistent method declarations in duplicated types

to fix the problem I just deleted the debug folder and restarted my application. It had something to do with changing the name of the object.

LNK 2022: Inconsistent layout information, after migrating to VS2010

I figured it out.

I had made a syntax change in one of the CMake files that I thought to be functionally identical to what was happening before (essentially I was using a CMake convenience variable). However, this of course had unintended consequences and the resulting project files were NOT the same.

Specifically, the Wrapper.DLL project was now linking to the 3rd party ITK libs that it did not need to link to at all (only the Native.DLL needs these).

After changing the CMake back and generating the project correctly, the dreaded LNK2022 went away. I only have myself to blame for all those hours wasted...

LNK2022 Error When Using /clr

I had this exact same problem today on one of my projects.
I solved it by rearranging my header files. Problem was I had moved a header file to the top of the cpp file, before the file that was including windows.h.
So, once I reverted the include order, and put windows.h back at the top of the cpp file, it fixed everything.

very wierd fix, but it worked for me.

LNK2022: metadata operation failed driving me insane

This problem is caused by the new Managed Incremental Build feature in Visual Studio 2008. As you spotted, the metadata did change, but not in a way that the managed incremental build feature considers signifcant. However, if you force a recompile of one of the cpp files, it grabs the new metadata, embeds it in the obj, and then the linker sees a conflict.

There are two ways to resolve this problem. A simple way that seems to work, from demoncodemonkey's answer below is to specify an explicit version number in the referenced assembly metadata to instruct the compiler that the referenced assembly is in fact at the same version:

Replace

[assembly:AssemblyVersionAttribute("1.0.*")];

with

[assembly:AssemblyVersionAttribute("1.0.0.1")];

in AssemblyInfo.cpp. This will ensure that the version does not
change between incremental builds.

The alternative way to avoid this problem is by disabling the feature. We may recompile some cpp files unnecessarily, but it's better than having the linker fail.

In the project properties, under Configuration Properties > General, set "Enable Managed Incremental Build" to No.



Related Topics



Leave a reply



Submit