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

Question

Bei der Migration einiger neuer UI 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 verwendet in einer gemeinsamen DLL und stützt sich auf ungefähr ein Dutzend andere Projekte innerhalb unserer Gesamtlösung. Dieses Projekt ist der Kern unserer Anwendung und würde jeden verwalteten UI-Code steuern, der erzeugt wird (daher die Notwendigkeit, die clr-Unterstützung für Interop einzuschalten).

Nach einer Tonne wenig niggly Fehler und Warnungen Festsetzung ich es endlich geschafft, die Anwendung zu kompilieren .. jedoch die Anwendung läuft eine EETypeLoadException verursacht und lässt mich zum Debuggen nicht in der Lage ...

einige tun Graben, fand ich die Ursache zu "System.TypeLoadException: Interne Einschränkung: zu viele Felder." was genau am Ende der Kompilierung passiert. Ich fand dann this link, die vorschlägt, die Versammlung in zwei oder mehr dlls zu brechen. Dies ist jedoch in meinem Fall nicht möglich, da ich eine Einschränkung habe, dass der Legacy-Code grundsätzlich unberührt bleibt.

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

Answer 1

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

Das behebt normalerweise dieses Problem, das eines dieser "huh?" MS-Einschränkungen wie die 64 KB-Grenze für Excel-Tabellen. Nur dieser beeinflusst die Anzahl der Symbole in einer Baugruppe.

Answer 2

Ich habe dies mit sehr großen Mixed-Mode-Anwendungen (C#/C++) dreimal (3x) getan und sobald die oben genannten Fix an Ort und Stelle gesetzt haben den Fehler nie wieder gesehen.

Und nein, wenn etwas sollte dies zur Folge etwas schneller Laufzeit-Ausführung (nichts, was man jemals messen konnte, aber.)

Aber ich stimme es so etwas wie eine Notlösung ist. Die interne Grenze für Symbole war kein Problem, oder wenn es war, war diese Grenze viel höher. Dann änderte MS einen Teil des Ladeprogramms. Ich bin auf MSDN gestoßen und habe darüber gejammert und mir wurde unmissverständlich gesagt, "nur ein Idiot würde so viele Symbole in eine einzige Baugruppe stecken".

(Welche der Gründe, warum ich nicht mehr auf MSDN teilnehmen.)

Nun, färben sie mich dumm, aber ich glaube nicht, dass ich die physikalische Struktur meiner Anwendung ändern müssen, Ausbrechen Dinge in Satelliten-DLLs, nur um die Tatsache zu umgehen, dass der Lader 10.001 Symbole entschieden hat, ist 1 zu viel.

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

Aber ich denke nicht, dass Sie diesen Fehler auf jeden Fall wieder sehen werden.

Answer 3

Müssen Sie/clr für das gesamte Projekt einschalten? Können Sie es stattdessen nur für eine kleine Auswahl von Dateien aktivieren und sehr vorsichtig sein, wie Sie verwalteten Code einbeziehen? Ich arbeite mit einer großen C++/MFC-Anwendung und wir fanden es sehr schwierig, verwaltete C++ zu verwenden. Ich liebe C# und .NET, aber verwaltet C++ war nichts als Kopfschmerzen. Die meisten unserer Probleme sind mit .NET 1.0/1.1 aufgetreten ... vielleicht sind die Dinge jetzt besser.