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