混合C ++ / CLI TypeLoadException内部限制：字段太多 [英] Mixed C++/CLI TypeLoadException Internal limitation: too many fields

问题描述

在将一些新UI迁移到Managed / C＃领域的任务中，我最近在一个大型遗留项目上启用了公共语言运行时支持（/ clr），该项目在共享DLL中使用MFC，并依赖于大约十几个项目在我们的整体解决方案。这个项目是我们的应用程序的核心，并将驱动任何管理的UI代码生成（因此需要打开clr支持interop）。

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).

在修复了一些小小的错误和警告后，我终于设法让应用程序编译..
然而，运行应用程序会导致EETypeLoadException和让我无法调试...

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...

做一些挖掘，我发现原因是System.TypeLoadException：内部限制：字段太多。这发生在编译结束时。然后我找到此链接< a>建议将组件分解为两个或多个dll。但是，这在我的情况下是不可能的，因为我的一个限制是遗留代码基本上保持不变。

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.

推荐答案

确保启用字符串池选项。

这通常解决这个问题，这是其中的一个是吗？ MS限制，例如Excel电子表格上的64k限制。只有这一个影响可能出现在程序集中的符号数。

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.

这篇关于混合C ++ / CLI TypeLoadException内部限制：字段太多的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！