Gemengde C ++ / CLI TypeLoadException Interne beperking: te veel velde

Question

Op 'n soeke na 'n paar nuwe UI in Bestuurde / C # land migreer, het ek onlangs aangeskakel Common Language Runtime Support (/ CLR) op 'n groot nalatenskap projek, wat MFC gebruik in 'n gedeelde DLL en maak staat op oor 'n ander dosyn projekte binne ons algehele oplossing. Hierdie projek is die kern van ons aansoek, en sal enige beheer UI-kode wat geproduseer word (vandaar die behoefte aan CLR ondersteuning te draai vir interop) ry.

Na vasstelling van 'n ton van klein niggly foute en waarskuwings, uiteindelik daarin geslaag ek om die aansoek op te stel kry .. Maar loop die aansoek veroorsaak 'n EETypeLoadException en laat my nie in staat om debug ...

Doen n paar grawe, het ek gevind dat die oorsaak te wees "System.TypeLoadException: Interne beperking:. Te veel velde" wat plaasvind aan die einde van samestelling. Ek het toe gevind hierdie skakel wat daarop dui om die vergadering af te breek in twee of meer dlls. Dit is egter nie moontlik in my geval, as 'n beperking wat ek het is dat die nalatenskap kode basies bly onaangeraak.

Kan iemand raai enige ander moontlike oplossings? Ek is regtig by 'n doodloopstraat hier.

Answer 1

Maak seker dat die Aktiveer String Poel opsie onder C / C ++ kodegenerasie is aangeskakel.

Dit is vasgestel gewoonlik hierdie kwessie, wat is een van daardie "huh?" MS beperkings soos die 64k beperking op Excel-sigblaaie. Slegs hierdie een raak die aantal simbole wat mag voorkom in 'n vergadering.

Answer 2

Het jy behoefte aan / CLR draai op vir die hele projek? Kan jy plaas draai dit op net vir 'n klein beperkte aantal lêers en baie versigtig wees hoe jy sluit daarin geslaag kode? Ek werk met 'n groot C ++ / MFC aansoek en ons het dit baie moeilik gevind om te gebruik bestuur C ++. Ek is lief vir C # en NET maar het daarin geslaag C ++ het niks anders as 'n kopseer. Die meeste van ons probleme gebeur met NET 1.0 / 1.1 ... miskien dinge is nou beter.

Answer 3

Ek het dit gedoen met 'n baie groot gemengde-modus (C # / C ++) aansoeke drie keer (3x) en een keer om die bogenoemde fix in plek het die fout nooit weer gesien nie.

En nee, as daar iets dit moet lei tot effens vinniger te hardloop-time uitvoering (niks wat jy ooit kon meet egter.)

Maar ek stem saam dit is 'n bietjie van 'n stoplap. Die interne beperking op simbole nie gebruik om 'n probleem te wees nie, of as dit was, wat grens was veel hoër. Dan verander MS sommige van die loader kode. Ek het op MSDN en uitgevaar daaroor en is meegedeel in geen onsekere terme, "net 'n idioot sal in 'n enkele vergadering sit dat baie simbole".

(wat een van die redes waarom ek nie meer deel te neem aan MSDN.)

Wel, kleur my dom, maar ek dink nie ek moet hê om die fisiese struktuur van my aansoek te verander, breek dinge uit in satelliet DLLs, bloot om die feit dat die loader het besluit 10.001 simbole te kry is 1 te baie.

En as jy daarop gewys, ons dikwels nie beheer oor hoe gemeentes / satelliet DLLs is struktuur, en die soort van afhanklikhede hulle bevat het.

Maar ek dink nie jy sal hierdie fout weer sien, in elk geval.