On a quest to migrate some new UI into Managed/C# land, I have recently turned on Common Language Runtime Support (/clr) on a large legacy project, which uses MFC in a Shared DLL and relies on about a dozen other projects within our overall solution. This project is the core of our application, and would drive any managed UI code that is produced (hence the need to turn on clr support for interop).
After fixing a ton of little niggly errors and warnings, I finally managed to get the application to compile.. However, running the application causes an EETypeLoadException and leaves me unable to debug…
Doing some digging, I found the cause to be ‘System.TypeLoadException: Internal limitation: too many fields.’ which occurs right at the end of compilation. I then found this link which suggests to break the assembly down into two or more dlls. However, this is not possible in my case, as a limitation I have is that the legacy code basically remains untouched.
Can anyone suggest any other possible solutions? I’m really at a dead end here.
Make sure the Enable String Pooling option under C/C++ Code Generation is turned on.
That usually fixes this issue, which is one of those ‘huh?’ MS limitations like the 64k limit on Excel spreadsheets. Only this one affects the number of symbols that may appear in an assembly.