All geek questions in one place

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

In search of a transition to a new user interface in Managed / C #, I recently included Common Language Runtime Support (/ clr) support in a large project that uses MFC in a common DLL and uses about a dozen other projects as part of our common solution. This project is the core of our application and will manage any managed user interface code that is created (therefore, you must enable clr support for interaction).

After fixing a ton of small errors and warnings, I was finally able to get the compilation application. However, running the application throws an EETypeLoadException and prevents me from debugging ...

After doing some copying, I found that the reason is "System.TypeLoadException: Internal constraint: too many fields." which happens right at the end of the compilation. Then I found this link , which suggests breaking the assembly into two or more DLLs. However, this is not possible in my case, as I have a limitation that the legacy code basically remains untouched.

Can anyone suggest any other possible solutions? I'm really stumped here.

+4
source share
3 answers

Make sure the Enable String Pooling option is enabled in the C / C ++ Code Generation section.

Does this usually fix this problem, which is one of those "yes"? MS restrictions, such as the 64k limit for Excel spreadsheets. Only this affects the number of characters that can be displayed in the assembly.

+7
source

Do you need to enable / clr for the whole project? Could you include it only for a small number of selected files and be very careful how you include managed code? I work with a large C ++ / MFC application, and it was very difficult for us to use managed C ++. I love C # and .NET, but managed C ++ was just a headache. Most of our problems happened with .NET 1.0 / 1.1 ... maybe now everything will be better.

+3
source

I did this with very large mixed modes (C # / C ++) three times (3 times), and after installing the above fix, I never saw the error again.

And no, if anything, this should lead to a slightly faster execution at runtime (however, you could not measure anything).

But I agree with this for a few minutes. The internal limit for characters was not used to be a problem, or if it was, this limit was much higher. Then MS changed part of the bootloader code. I got to MSDN and talked about it, and they told me unequivocally: "only an idiot would put so many characters in one assembly."

(This is one of the reasons I no longer participate in MSDN.)

Well, color me stupidly, but I don’t think I would have to change the physical structure of my application by sorting things into satellite DLLs, just to get around the fact that the loader decided that 10,001 characters are also 1 many.

And, as you pointed out, we often do not control the assembly structure / satellite DLLs and the types of dependencies that they contain.

But I don’t think you will see this error again, anyway.

+2
source

Source: https://habr.com/ru/post/1276360/

More articles:


All Articles