Gemischte C++/CLI TypeLoadException Interne Einschränkung:zu viele Felder

Question

Auf der Suche nach der Migration einer neuen Benutzeroberfläche in Managed/C#-Land habe ich kürzlich die Common Language Runtime-Unterstützung (/clr) für ein großes Legacy-Projekt aktiviert, das MFC in einer gemeinsam genutzten DLL verwendet und auf etwa einem Dutzend anderer Projekte in unserem Projekt basiert Gesamtlösung.Dieses Projekt ist der Kern unserer Anwendung und würde jeden erstellten verwalteten UI-Code steuern (daher muss die Clr-Unterstützung für Interop aktiviert werden).

Nachdem ich eine Menge kleiner, lästiger Fehler und Warnungen behoben hatte, gelang es mir schließlich, die Anwendung zum Kompilieren zu bringen.Das Ausführen der Anwendung führt jedoch zu einer EETypeLoadException und ich kann kein Debugging ausführen ...

Beim Recherchieren habe ich herausgefunden, dass die Ursache „System.TypeLoadException:“ ist.Interne Begrenzung:zu viele Felder", was direkt am Ende der Kompilierung auftritt.Ich habe es dann gefunden dieser Link was darauf hindeutet, die Assembly in zwei oder mehr DLLs aufzuteilen.Dies ist in meinem Fall jedoch nicht möglich, da meine Einschränkung darin besteht, dass der Legacy-Code grundsätzlich unangetastet bleibt.

Kann jemand andere mögliche Lösungen vorschlagen?Ich bin hier wirklich in einer Sackgasse.

Answer 1

Stellen Sie sicher, dass Aktivieren Sie String-Pooling Option unter C/C++-Codegenerierung ist aktiviert.

Das behebt dieses Problem normalerweise, was eines dieser "Huh?" MS -Einschränkungen wie die 64K -Grenze für Excel -Tabellenkalkulationen.Nur dieses beeinflusst die Anzahl der Symbole, die in einer Baugruppe erscheinen dürfen.

Answer 2

Müssen Sie /clr für das gesamte Projekt aktivieren?Könnten Sie es stattdessen nur für eine kleine ausgewählte Anzahl von Dateien aktivieren und sehr vorsichtig sein, wie Sie verwalteten Code einbinden?Ich arbeite mit einer großen C++/MFC-Anwendung und wir fanden es sehr schwierig, verwaltetes C++ zu verwenden.Ich liebe C# und .NET, aber verwaltetes C++ bereitet mir nur Kopfzerbrechen.Die meisten unserer Probleme traten mit .NET 1.0/1.1 auf ...Vielleicht ist es jetzt besser.

Answer 3

Ich habe dies dreimal (3x) mit sehr großen Mixed-Mode-Anwendungen (C#/C++) durchgeführt, und nachdem ich den oben genannten Fix durchgeführt habe, ist der Fehler nie wieder aufgetreten.

Und nein, wenn überhaupt, sollte dies zu einer etwas schnelleren Laufzeitausführung führen (was Sie jedoch nie messen könnten).

Aber ich stimme zu, dass es eine Art Notlösung ist.Die interne Beschränkung der Symbole stellte früher kein Problem dar, oder wenn doch, war diese Beschränkung viel höher.Dann hat MS einen Teil des Ladecodes geändert.Ich bin auf MSDN gestoßen und habe darüber geschimpft und mir wurde unmissverständlich gesagt: „Nur ein Idiot würde so viele Symbole in einer einzigen Assembly unterbringen.“

(Das ist einer der Gründe, warum ich nicht mehr an MSDN teilnehme.)

Nun, ich halte mich für dumm, aber ich glaube nicht, dass ich die physische Struktur meiner Anwendung ändern und die Dinge in Satelliten-DLLs aufteilen müsste, nur um die Tatsache zu umgehen, dass der Loader entschieden hat, dass 10.001 Symbole 1 zu viel sind.

Und wie Sie bereits betont haben, haben wir oft keine Kontrolle über die Struktur von Assemblys/Satelliten-DLLs und die Art der Abhängigkeiten, die sie enthalten.

Ich glaube jedoch nicht, dass dieser Fehler noch einmal auftritt.