16

Environment: Visual Studio 10, CLR/CLI Class Library project, built with Platform Toolset v100, targeting framework version v3.5.

I am aware that this question was already asked here, but I did not find an answer that solved the problem for my case, so bringing this up again.

While building a CLR/CLI Class Library (DLL) project the linker is failing with the following errors:

MSVCMRT.lib(managdeh.obj) : error LNK2022: metadata operation failed (80131195) : Custom attributes are not consistent: (0x0c0000f7).
MSVCMRT.lib(managdeh.obj) : error LNK2022: metadata operation failed (80131195) : Custom attributes are not consistent: (0x0c0000fb).
MSVCMRT.lib(msilexit.obj) : error LNK2022: metadata operation failed (80131195) : Custom attributes are not consistent: (0x0c000128).
MSVCMRT.lib(msilexit.obj) : error LNK2022: metadata operation failed (80131195) : Custom attributes are not consistent: (0x0c00012c).
MSVCMRT.lib(puremsilcode.obj) : error LNK2022: metadata operation failed (80131195) : Custom attributes are not consistent: (0x0c0000ee).
MSVCMRT.lib(puremsilcode.obj) : error LNK2022: metadata operation failed (80131195) : Custom attributes are not consistent: (0x0c0000f1).
LINK : fatal error LNK1255: link failed because of metadata errors
Deduplicator
  • 44,692
  • 7
  • 66
  • 118
PazO
  • 1,314
  • 1
  • 11
  • 30
  • Have you set the CLR flag properly? http://social.msdn.microsoft.com/Forums/vstudio/en-US/047d168c-e759-47a7-8e1d-bfbed12d35d0/error-lnk2022-metadata-operation-failed-custom-attributes-are-not-consistent – doctorlove Sep 02 '13 at 11:02
  • Yes: Set `/clr` in both places... – PazO Sep 08 '13 at 06:55
  • Duplication of class name due to including same file twice can also cause this warning. Check if you have not included a header in pch.h and then again in some other file that refers that pch [microsoft documentation](https://learn.microsoft.com/en-us/cpp/error-messages/tool-errors/linker-tools-error-lnk2022?view=vs-2019) – Shantanu Methikar Sep 28 '20 at 09:59

4 Answers4

40

Another thing I learned on the way is that you cannot mix values of Platform Toolset and Target Framework Version.

The possible combinations I found where:

.NET 3.5 or less:

  • Platform Toolset: v90, which will use Visual Studio 2008 runtime binaries,
  • TargetFrameworkVersion: v3.5 (or less),
  • In the preprocessor you can have _WIN32_WINNT defined (e.g. _WIN32_WINNT=0x0500)

.NET 4.0 or higher:

  • Platform Toolset: v100, which will use Visual Studio 2010 runtime binaries,
  • TargetFrameworkVersion: v4.0 (or higher),
  • In the preprocessor you must not have the '_WIN32_WINNT=0x0500' defined

How to define these values:

  1. Platform Toolset – find it under: Project settings | General,
  2. TargetFrameworkVersion - Unload the project, right-click on the unloaded project and select 'Edit'. Once the '*.*proj' file is open, modify the following line: <TargetFrameworkVersion>v3.5<TargetFrameworkVersion/>
PazO
  • 1,314
  • 1
  • 11
  • 30
2

Remove the _WIN32_WINNT=0x0500 definition from the C/C++ Preprocessor

Apparently for some reason the above preprocessor definition did not agree with the linker, causing the linker errors. I assume this is some internal Microsoft bug (?), but not sure. Anyway, after removing this preprocessor definition all built and linked correctly.

Hope this information is useful.

Community
  • 1
  • 1
PazO
  • 1,314
  • 1
  • 11
  • 30
0

I had some header files in some of the compilation units that set the Windows version:

#define _WIN32_WINNT 0x0501

The problem was with the other compilation units (c++ files) that didn't set that variable, so the error LNK2022 is complaining that the same struct is compiled in different ways in multiple compilation units (different cpp files).

So I can't just unset the _WIN32_WINNT definition, so my solution was quite the opposite of what was suggested before.

I just set it for the whole project, so all the compilation units compile the same way.
project properties -> C/C++ -> Preprocessor -> Preprocessor Definitions 

_WIN32_WINNT=0x0501;
Yochai Timmer
  • 48,127
  • 24
  • 147
  • 185
0

I'm a C# dev but I had to wrap native C++ code and ended up with this same error.

Turns out I had to use make_public to expose the native type publicly to the C++/CLI assembly:

#include "SomeHeader.h"
#pragma make_public(SomeNamespace::NativeClass)

As I understand this is usually used when the header file cannot be edited.

Shahin Dohan
  • 6,149
  • 3
  • 41
  • 58