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