{"id":142,"date":"2007-02-08T14:35:06","date_gmt":"2007-02-08T13:35:06","guid":{"rendered":"http:\/\/minibrain.wordpress.com\/2007\/02\/08\/linker-error-lnk2022-metadata-operation-failed-80131195\/"},"modified":"2007-02-08T14:35:06","modified_gmt":"2007-02-08T13:35:06","slug":"linker-error-lnk2022-metadata-operation-failed-80131195","status":"publish","type":"post","link":"https:\/\/abramowitsch.de\/blog\/?p=142","title":{"rendered":"Visual Studio 2005: Linker Error LNK2022: metadata operation failed (80131195)"},"content":{"rendered":"

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

Die MSDN <\/a>ist an dieser Stelle auch nicht wirklich hilfreich \ud83d\ude41<\/p>\n

Ich habe mal etwas rumgegoogelt nach dem Fehler und folgende Antwort gefunden:<\/p>\n

„In the Whidbey release the linker will give better diagnostics.<\/p>\n

For now the way to diagnose this is using ildasm to dump the metadata<\/span> of the
\n..obj files to text and then search for the tokens (the hex numbers mentioned
\nin the error<\/span> messages). Usually this is a source error<\/span> where 2 translation
\nunits define a type in a different way.<\/p>\n

Ronald Laeremans
\nVisual C++ team“<\/p>\n

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.<\/p>\n

Um den Fehler zu lokalisieren, f\u00fchrte ich also folgende Schritte aus:<\/p>\n

    \n
  1. Dump des Object-Files mit dem ILDasm in eine Text-Datei<\/strong>ildasm Problem.obj \/text \/out=problem.txt(Hinweis: funktioniert NUR(!) auf Kommandozeilen-Ebene! Die GUI kann mit .OBJ-Dateien nix anfangen!)<\/li>\n
  2. \u00d6ffnen der problem.txt-Datei<\/strong> in einem Editor<\/li>\n
  3. Suchen nach der Adresse des Fehlers<\/strong> (bei mir: 0x0c0003bd), allerdings ohne „0x“ am Anfang: 0c0003bd. Bei mir bin ich nun in Zeile 28147:\/\/ CustomAttribute #1 (0c0003bd)
    \n\/\/ ——————————————————-
    \n\/\/ CustomAttribute Type: 0a000005
    \n\/\/ CustomAttributeName: System.CLSCompliantAttribute :: instance void .ctor(bool)
    \n\/\/ Length: 5
    \n\/\/ Value : 01 00 00 00 00 > <
    \n\/\/ ctor args: ( <can not decode> )<\/li>\n
  4. Wenn man nun etws h\u00f6her scrollt<\/strong>, dann sieht man hinter dem Bezeichner TypDefName <\/strong>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:
    \n#include „..problem.h“
    \n#pragma make_public(ProblemNamespace::Problem)<\/li>\n<\/ol>\n

    Damit war f\u00fcr mich das Problem gel\u00f6st. Echt schade, dass solche Probleme bei modernen Compilern noch auftreten und man keine vern\u00fcnftigen L\u00f6sungsvorschl\u00e4ge bekommt.<\/p>\n

    Update:<\/strong>
    \nDer 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.<\/p>\n","protected":false},"excerpt":{"rendered":"

    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 \ud83d\ude41<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[3,20],"tags":[],"class_list":["post-142","post","type-post","status-publish","format-standard","hentry","category-net","category-visual-studio-net"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p3Ug90-2i","_links":{"self":[{"href":"https:\/\/abramowitsch.de\/blog\/index.php?rest_route=\/wp\/v2\/posts\/142","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/abramowitsch.de\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/abramowitsch.de\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/abramowitsch.de\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/abramowitsch.de\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=142"}],"version-history":[{"count":0,"href":"https:\/\/abramowitsch.de\/blog\/index.php?rest_route=\/wp\/v2\/posts\/142\/revisions"}],"wp:attachment":[{"href":"https:\/\/abramowitsch.de\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=142"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/abramowitsch.de\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=142"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/abramowitsch.de\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=142"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}