Mixed C++/CLI TypeLoadException Internal limitation: too many fields

Question

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.

Answer 1

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.

Answer 2

Do you need to turn /clr on for the entire project? Could you instead turn it on only for a small select number of files and be very careful how you include managed code? I work with a large C++/MFC application and we have found it very difficult to use managed C++. I love C# and .NET but managed C++ has been nothing but a headache. Most of our problems happened with .NET 1.0/1.1 ... maybe things are better now.

Answer 3

I have done this with very large mixed-mode (C#/C++) applications three times (3x) and once putting the above fix into place have never seen the error again.

And no, if anything this should result in slightly faster run-time execution (nothing you could ever measure, however.)

But I agree it's somewhat of a stopgap. The internal limit on symbols didn't use to be an issue, or if it was, that limit was much higher. Then MS changed some of the loader code. I got onto MSDN and ranted about it and was told in no uncertain terms, "only an idiot would put that many symbols in a single assembly".

(Which is one of the reasons I no longer participate on MSDN.)

Well, color me stupid, but I don't think I should have to change the physical structure of my application, breaking things out into satellite DLLs, merely to get around the fact that the loader has decided 10,001 symbols is 1 too many.

And as you pointed out, we often don't have control over how assemblies/satellite DLLs are structure, and the sort of dependencies they contain.

But I don't think you'll see this error again, in any case.