C++/CLI TypeLoadException Limitation interne: trop de champs

Question

Lors d'une tentative de migration d'une nouvelle interface utilisateur vers Managed/C#, j'ai récemment activé Common Language Runtime Support (/ clr) sur un grand projet hérité, qui utilise MFC dans une DLL partagée et s'appuie sur une douzaine d'autres projets au sein de notre solution globale. Ce projet est le noyau de notre application, et conduirait tout code d'interface utilisateur géré qui est produit (d'où la nécessité d'activer le support clr pour interop).

Après la fixation d'une tonne de petites erreurs niggly et mises en garde, j'ai finalement réussi à obtenir l'application de compiler .. Toutefois, l'exécution de l'application provoque une EETypeLoadException et me laisse incapable de debug ...

Faire des creuser, j'ai trouvé la cause d'être "System.TypeLoadException: limitation interne: trop de champs." qui se produit juste à la fin de la compilation. J'ai ensuite trouvé this link qui suggère de décomposer l'assemblage en deux DLL ou plus. Cependant, ce n'est pas possible dans mon cas, car une limitation que j'ai est que le code hérité fondamentalement reste intact.

Quelqu'un peut-il suggérer d'autres solutions possibles? Je suis vraiment dans une impasse ici.

Answer 1

Assurez-vous que l'option Enable String Pooling sous Génération de code C/C++ est activée.

Cela résout généralement ce problème, qui est l'un de ces "huh?" Limitations MS comme la limite de 64 Ko sur les feuilles de calcul Excel. Seul celui-ci affecte le nombre de symboles qui peuvent apparaître dans un assemblage.

Answer 2

Je l'ai fait avec de très grandes applications en mode mixte (C#/C++) trois fois (3x) et une fois la mise en place ci-dessus n'a jamais vu l'erreur à nouveau.

Et non, si tout cela devrait aboutir à la gestion du temps un peu plus rapide exécution (rien que vous ne pourriez jamais mesurer, cependant.)

Mais je suis d'accord, il est un peu d'un pis-aller. La limite interne sur les symboles n'a pas été un problème, ou si c'était le cas, cette limite était beaucoup plus élevée. Puis MS a changé une partie du code du chargeur. Je suis monté sur MSDN et je me suis égaré à ce sujet et on m'a dit en termes non équivoques: «Seul un idiot mettrait autant de symboles dans une seule assemblée».

(ce qui est l'une des raisons pour lesquelles je ne participerait plus sur MSDN.)

Eh bien, moi la couleur stupide, mais je ne pense pas que je devrais changer la structure physique de ma demande, brisant les choses dans les DLL satellites, simplement pour contourner le fait que le chargeur a décidé que 10 001 symboles sont trop nombreux. Et comme vous l'avez souligné, nous n'avons souvent aucun contrôle sur la structure des assemblys/DLLs et sur le type de dépendances qu'elles contiennent.

Mais je ne pense pas que vous verriez cette erreur à nouveau, dans tous les cas.

Answer 3

Avez-vous besoin d'activer/de fermer pour l'ensemble du projet? Pourriez-vous plutôt l'activer uniquement pour un petit nombre de fichiers et faire très attention à la façon dont vous incluez le code managé? Je travaille avec une grande application C++/MFC et nous avons trouvé très difficile d'utiliser C++ géré. J'aime C# et .NET mais le C++ géré n'a été qu'un casse-tête. La plupart de nos problèmes sont survenus avec .NET 1.0/1.1 ... peut-être que les choses vont mieux maintenant.