Beim Kompilieren meines InterOp-Projektes erhielt ich heute die Fehlermeldung „error LNK2022: metadata operation failed (80131195) : Die benutzerdefinierten Attribute sind nicht konsistent: (0x0c0003bd).“ – eine echt tolle Fehlermeldung, mit der man sofort etwas anfangen kann!

Die MSDN ist an dieser Stelle auch nicht wirklich hilfreich 🙁

Ich habe mal etwas rumgegoogelt nach dem Fehler und folgende Antwort gefunden:

„In the Whidbey release the linker will give better diagnostics.

For now the way to diagnose this is using ildasm to dump the metadata of the
..obj files to text and then search for the tokens (the hex numbers mentioned
in the error messages). Usually this is a source error where 2 translation
units define a type in a different way.

Ronald Laeremans
Visual C++ team“

Da schien mir wohl eher ein Scherz zu sein, denn ich setze bereits Whidbey, also Visual Studio 2005, ein. Trotzdem erhielt ich diese kryptische Fehlermeldung.

Um den Fehler zu lokalisieren, führte ich also folgende Schritte aus:

1. Dump des Object-Files mit dem ILDasm in eine Text-Dateiildasm Problem.obj /text /out=problem.txt(Hinweis: funktioniert NUR(!) auf Kommandozeilen-Ebene! Die GUI kann mit .OBJ-Dateien nix anfangen!)
2. Öffnen der problem.txt-Datei in einem Editor
3. Suchen nach der Adresse des Fehlers (bei mir: 0x0c0003bd), allerdings ohne „0x“ am Anfang: 0c0003bd. Bei mir bin ich nun in Zeile 28147:// CustomAttribute #1 (0c0003bd)
   // ——————————————————-
   // CustomAttribute Type: 0a000005
   // CustomAttributeName: System.CLSCompliantAttribute :: instance void .ctor(bool)
   // Length: 5
   // Value : 01 00 00 00 00 > <
   // ctor args: ( <can not decode> )
4. Wenn man nun etws höher scrollt, dann sieht man hinter dem Bezeichner TypDefName den Ursprung des Problems (also die Klasse oder der Typ oder die Struktur) und kann dieses dann im C++/CLI-Code beheben. Ursache bei mir war, dass ich mit meinem pragma-makro nicht alle refernzen erwischt hatte:
   #include „..problem.h“
   #pragma make_public(ProblemNamespace::Problem)

Damit war für mich das Problem gelöst. Echt schade, dass solche Probleme bei modernen Compilern noch auftreten und man keine vernünftigen Lösungsvorschläge bekommt.

Update:
Der Fehler kann ebenfalls auftreten, wenn man Interface-Klassen mit #pragma make_public einbindet. Diese sind scheinbar by-default public visible. Zumindest gab es bei mir diesen Linker-Fehler, wenn ich Interface-Klassen damit eingebunden hatte.