Question

Dans le but de migrer une nouvelle interface utilisateur vers le pays géré/C#, j'ai récemment activé la prise en charge du Common Language Runtime (/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 au cœur de notre application et piloterait tout code d'interface utilisateur géré produit (d'où la nécessité d'activer la prise en charge de clr pour l'interopérabilité).

Après avoir corrigé une tonne de petites erreurs et d’avertissements gênants, j’ai finalement réussi à compiler l’application.Cependant, l'exécution de l'application provoque une EETypeLoadException et me laisse incapable de déboguer...

En creusant, j'ai trouvé que la cause était "System.TypeLoadException :Limitation interne :trop de champs." qui se produit juste à la fin de la compilation.J'ai alors trouvé ce lien ce qui suggère de diviser l’assemblage en deux ou plusieurs DLL.Cependant, cela n'est pas possible dans mon cas, car une limitation est que le code existant reste fondamentalement intact.

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

Était-ce utile?

La solution

Assurez-vous que le Activer le regroupement de chaînes L’option sous Génération de code C/C++ est activée.

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

Autres conseils

Devez-vous activer /clr pour l’ensemble du projet ?Pourriez-vous plutôt l'activer uniquement pour un petit nombre de fichiers sélectionnés et faire très attention à la manière dont vous incluez le code managé ?Je travaille avec une grande application C++/MFC et nous avons trouvé très difficile d'utiliser le C++ managé.J'adore C# et .NET, mais le C++ géré n'est 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.

Je l'ai fait trois fois (3x) avec de très grandes applications en mode mixte (C#/C++) et une fois le correctif ci-dessus mis en place, je n'ai plus jamais revu l'erreur.

Et non, cela devrait plutôt entraîner une exécution légèrement plus rapide (rien que vous puissiez jamais mesurer, cependant.)

Mais je suis d’accord, c’est en quelque sorte un pis-aller.La limite interne des symboles n’était pas un problème auparavant, ou si c’était le cas, cette limite était beaucoup plus élevée.Ensuite, MS a modifié une partie du code du chargeur.Je suis arrivé sur MSDN et j'en ai parlé et on m'a dit sans équivoque: "seul un idiot mettrait autant de symboles dans un seul assemblage".

(C'est l'une des raisons pour lesquelles je ne participe plus à MSDN.)

Eh bien, colorez-moi comme un idiot, mais je ne pense pas que je devrais avoir à changer la structure physique de mon application, en décomposant les éléments en DLL satellite, simplement pour contourner le fait que le chargeur a décidé que 10 001 symboles, c'est 1 de trop.

Et comme vous l'avez souligné, nous n'avons souvent aucun contrôle sur la structure des assemblys/DLL satellites et sur le type de dépendances qu'ils contiennent.

Mais je ne pense pas que vous reverrez cette erreur, de toute façon.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top