TypeLoadException misto C++/CLI Limitazione interna:troppi campi

Question

Nel tentativo di migrare alcune nuove interfacce utente in un ambiente gestito/C#, ho recentemente attivato il supporto Common Language Runtime (/clr) su un grande progetto legacy, che utilizza MFC in una DLL condivisa e si basa su circa una dozzina di altri progetti all'interno del nostro soluzione complessiva.Questo progetto è il nucleo della nostra applicazione e guiderebbe qualsiasi codice dell'interfaccia utente gestito prodotto (da qui la necessità di attivare il supporto clr per l'interoperabilità).

Dopo aver corretto un sacco di piccoli errori e avvisi fastidiosi, sono finalmente riuscito a compilare l'applicazione.Tuttavia, l'esecuzione dell'applicazione provoca un'EETypeLoadException e non mi consente di eseguire il debug...

Facendo qualche ricerca, ho scoperto che la causa era "System.TypeLoadException:Limitazione interna:troppi campi." che si verifica proprio alla fine della compilazione.Ho poi trovato questo link che suggerisce di suddividere l'assembly in due o più dll.Tuttavia, questo non è possibile nel mio caso, poiché una mia limitazione è che il codice legacy rimane sostanzialmente intatto.

Qualcuno può suggerire altre possibili soluzioni?Sono davvero a un punto morto qui.

Answer 1

Assicurati che Abilita il pool di stringhe l'opzione in Generazione codice C/C++ è attivata.

Questo di solito risolve questo problema, che è uno di quei "eh?" Limitazioni di MS come il limite 64K sui fogli di calcolo Excel.Solo questo influisce sul numero di simboli che possono apparire in un assieme.

Answer 2

È necessario attivare /clr per l'intero progetto?Potresti invece attivarlo solo per un numero limitato di file selezionati e fare molta attenzione a come includi il codice gestito?Lavoro con un'applicazione C++/MFC di grandi dimensioni e abbiamo trovato molto difficile utilizzare il C++ gestito.Adoro C# e .NET, ma il C++ gestito non è stato altro che un mal di testa.La maggior parte dei nostri problemi si sono verificati con .NET 1.0/1.1...forse le cose adesso vanno meglio.

Answer 3

L'ho fatto tre volte (3x) con applicazioni in modalità mista (C#/C++) di grandi dimensioni e, una volta implementata la correzione di cui sopra, non ho più visto l'errore.

E no, semmai ciò dovrebbe comportare un'esecuzione di runtime leggermente più veloce (niente che potresti mai misurare, comunque).

Ma sono d'accordo che sia una sorta di palliativo.Il limite interno sui simboli non era un problema o, se lo era, quel limite era molto più alto.Quindi MS ha modificato parte del codice del caricatore.Sono entrato su MSDN e mi sono lamentato e mi è stato detto senza mezzi termini: "solo un idiota metterebbe così tanti simboli in un unico assieme".

(Che è uno dei motivi per cui non partecipo più a MSDN.)

Bene, dimmi che sono stupido, ma non penso che dovrei cambiare la struttura fisica della mia applicazione, suddividendo le cose in DLL satellite, semplicemente per aggirare il fatto che il caricatore ha deciso che 10.001 simboli sono 1 di troppo.

E come hai sottolineato, spesso non abbiamo il controllo sulla struttura degli assembly/DLL satellitari e sul tipo di dipendenze che contengono.

Ma non credo che vedrai più questo errore, in ogni caso.