CLR/CLI linker fails with error LNK2022 - Custom attributes are not consistent

Question

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

Answer 1

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/>

Answer 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.

Answer 3

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;

Answer 4

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.