混合 C++/CLI TypeLoadException 内部限制：太多领域

Question

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

在修复了大量的小错误和警告之后，我终于成功地编译了应用程序。但是，运行应用程序会导致 EETypeLoadException 并使我无法调试...

经过一番挖掘，我发现原因是“System.TypeLoadException：内部限制：太多字段。”这发生在编译结束时。然后我发现 这个链接 这建议将程序集分解为两个或多个 dll。然而，这对我来说是不可能的，因为我的限制是遗留代码基本上保持不变。

谁能建议任何其他可能的解决方案？我真的陷入了死胡同。

Answer 1

确保 启用字符串池 C/C++ 代码生成下的选项已打开。

这通常可以解决此问题，哪一个是“嗯？” MS限制，例如Excel电子表格的64K限制。只有这一项会影响装配体中可能出现的符号数量。

Answer 2

您需要为整个项目打开 /clr 吗？您是否可以仅针对少量选定的文件打开它，并非常小心地包含托管代码？我使用大型 C++/MFC 应用程序，我们发现使用托管 C++ 非常困难。我喜欢 C# 和 .NET，但托管 C++ 却让人头疼。我们的大多数问题都发生在 .NET 1.0/1.1 上......也许现在情况好多了。

Answer 3

我已经对非常大的混合模式 (C#/C++) 应用程序执行了此操作三次 (3x)，并且一旦将上述修复到位，就再也没有看到该错误。

不，如果有的话，这应该会导致运行时执行速度稍快一些（但是，这是您无法测量的。）

但我同意这只是权宜之计。符号的内部限制曾经不是一个问题，或者如果是的话，这个限制要高得多。然后微软改变了一些加载器代码。我在 MSDN 上对此进行了咆哮，并被毫不含糊地告知，“只有白痴才会在一个程序集中放置那么多符号”。

（这是我不再参与 MSDN 的原因之一。）

好吧，把我当傻子吧，但我不认为我应该改变应用程序的物理结构，将东西分解成卫星 DLL，只是为了回避加载程序认为 10,001 个符号太多的事实。

正如您所指出的，我们通常无法控制程序集/附属 DLL 的结构以及它们包含的依赖关系的类型。

但无论如何，我认为您不会再看到此错误。