混合 C++/CLI TypeLoadException 内部限制：字段太多
为了将一些新的 UI 迁移到托管/C# 领域，我最近在一个大型旧项目上启用了公共语言运行时支持 (/clr)，该项目在共享 DLL 中使用 MFC，并依赖于我们的大约十几个其他项目。整体解决方案。 该项目是我们应用程序的核心，并将驱动生成的任何托管 UI 代码（因此需要打开 clr 对互操作的支持）。
在修复了大量的小错误和警告之后，我终于成功地编译了应用程序。 但是，运行应用程序会导致 EETypeLoadException 并使我无法调试...
经过一番挖掘，我发现原因是“System.TypeLoadException：内部限制：字段太多”。 这发生在编译结束时。 然后我找到了此链接 这建议将程序集分解为两个或多个 dll。 然而，这对我来说是不可能的，因为我的限制是遗留代码基本上保持不变。
谁能建议任何其他可能的解决方案？ 我真的陷入了死胡同。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
确保 C/C++ 代码生成下的启用字符串池选项已打开在。
这通常可以解决这个问题，这是“嗯？”之一。 MS 的限制，例如 Excel 电子表格的 64k 限制。 只有这一项会影响装配体中可能出现的符号数量。
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.
我已经对非常大的混合模式 (C#/C++) 应用程序执行了此操作三次 (3x)，并且一旦将上述修复到位，就再也没有看到该错误。
不，如果有什么不同的话，这应该会导致运行时执行速度稍微加快（但是，这是你无法测量的。）
但我同意这在某种程度上是一种权宜之计。 符号的内部限制曾经不是一个问题，或者如果是的话，这个限制要高得多。 然后微软改变了一些加载器代码。 我在 MSDN 上对此进行了咆哮，并被毫不含糊地告知，“只有白痴才会在一个程序集中放置那么多符号”。
（这是我不再参与 MSDN 的原因之一。）
好吧，让我觉得自己很愚蠢，但我认为我不应该改变应用程序的物理结构，将东西分解成卫星 DLL，只是为了解决这个问题事实上，加载程序已经决定了 10,001 个符号，这实在是太多了。
正如您所指出的，我们通常无法控制程序集/附属 DLL 的结构以及它们包含的依赖关系的类型。
但无论如何，我认为您不会再次看到此错误。
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.
您需要为整个项目打开 /clr 吗？ 您是否可以仅针对少量选定的文件打开它，并非常小心地包含托管代码？ 我使用大型 C++/MFC 应用程序，我们发现使用托管 C++ 非常困难。 我喜欢 C# 和 .NET，但托管 C++ 却让人头疼。 我们的大多数问题都发生在 .NET 1.0/1.1 上……也许现在情况好多了。
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.