Limitación interna mixta de C++/CLI TypeLoadException:demasiados campos

Question

En una búsqueda para migrar una nueva interfaz de usuario a Managed/C#, recientemente activé el soporte de Common Language Runtime (/clr) en un gran proyecto heredado, que usa MFC en una DLL compartida y se basa en aproximadamente una docena de otros proyectos dentro de nuestro solución global.Este proyecto es el núcleo de nuestra aplicación e impulsaría cualquier código de interfaz de usuario administrado que se produzca (de ahí la necesidad de activar la compatibilidad con clr para la interoperabilidad).

Después de corregir un montón de pequeños errores y advertencias, finalmente logré que la aplicación se compilara.Sin embargo, ejecutar la aplicación provoca una EETypeLoadException y no me permite depurar...

Investigando un poco, encontré que la causa es "System.TypeLoadException:Limitación interna:demasiados campos." que ocurre justo al final de la compilación.entonces encontré este enlace lo que sugiere dividir el ensamblaje en dos o más DLL.Sin embargo, esto no es posible en mi caso, ya que una limitación que tengo es que el código heredado básicamente permanece intacto.

¿Alguien puede sugerir otras posibles soluciones?Realmente estoy en un callejón sin salida.

Answer 1

Asegúrate que Habilitar la agrupación de cadenas La opción en Generación de código C/C++ está activada.

Eso generalmente soluciona este problema, que es uno de esos "¿eh?" Limitaciones de MS como el límite de 64k en las hojas de cálculo de Excel.Sólo éste afecta la cantidad de símbolos que pueden aparecer en un ensamblaje.

Answer 2

¿Necesita activar /clr para todo el proyecto?¿Podrías, en cambio, activarlo solo para una pequeña cantidad selecta de archivos y tener mucho cuidado al incluir el código administrado?Trabajo con una aplicación C++/MFC de gran tamaño y nos ha resultado muy difícil utilizar C++ administrado.Me encanta C# y .NET, pero administrar C++ no ha sido más que un dolor de cabeza.La mayoría de nuestros problemas ocurrieron con .NET 1.0/1.1...tal vez las cosas estén mejor ahora.

Answer 3

He hecho esto con aplicaciones muy grandes de modo mixto (C#/C++) tres veces (3x) y una vez que implementé la solución anterior nunca volví a ver el error.

Y no, en todo caso, esto debería resultar en una ejecución en tiempo de ejecución ligeramente más rápida (sin embargo, nada que puedas medir).

Pero estoy de acuerdo en que es una especie de recurso provisional.El límite interno de símbolos no solía ser un problema, o si lo era, ese límite era mucho mayor.Luego MS cambió parte del código del cargador.Entré en MSDN y despotricé sobre ello y me dijeron en términos muy claros: "sólo un idiota pondría tantos símbolos en un solo ensamblaje".

(Que es una de las razones por las que ya no participo en MSDN).

Bueno, créame estúpido, pero no creo que deba cambiar la estructura física de mi aplicación, dividiendo las cosas en DLL satélites, simplemente para evitar el hecho de que el cargador ha decidido que 10,001 símbolos son demasiados.

Y como usted señaló, a menudo no tenemos control sobre cómo se estructuran los ensamblados/DLL satélites y el tipo de dependencias que contienen.

Pero no creo que vuelvas a ver este error, en ningún caso.