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

修复了许多小小的错误和警告之后，我终于设法使应用程序得以编译。
但是，运行该应用程序会导致EETypeLoadException并使我无法调试...

进行一些挖掘，发现原因是" System.TypeLoadException：内部限制：字段太多"。它发生在编译结束时。然后，我发现此链接建议将程序集分解为两个或者多个dll。但是，在我的情况下这是不可能的，因为我的一个限制是传统代码基本上保持不变。

谁能提出其他可能的解决方案？我真的在这里死胡同了。

解决方案

回答

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

通常可以解决此问题，这是"呵呵"之一。 MS限制，例如Excel电子表格上的64k限制。只有这一点会影响程序集中可能出现的符号数量。

回答

我已经使用大型混合模式(C＃/ C ++)应用程序完成了三遍(3x)，并且一旦完成了上述修复，就再也看不到错误。

不，如果有的话，这会导致运行时执行速度稍快(但是，我们无法衡量)。

但我同意这有点权宜之计。符号的内部限制曾经不是一个问题，或者如果是，则该限制要高得多。然后，MS更改了一些加载程序代码。我进入MSDN并对其进行了指责，并毫不犹豫地被告知："只有一个白痴才将那么多符号放在一个程序集中"。

(这是我不再参与MSDN的原因之一。)

好吧，给我涂上愚蠢的颜色，但我认为我不必改变应用程序的物理结构，将其分解为卫星DLL，仅是为了避免装入程序认为10,001个符号太多的事实。

正如我们所指出的，我们通常无法控制程序集/卫星DLL的结构以及它们所包含的依存关系。

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

回答

我们是否需要为整个项目打开/ clr？我们能否只为少数几个文件打开它，并非常小心地包含托管代码？我使用大型C ++ / MFC应用程序，但发现使用托管C ++非常困难。我爱Cand .NET，但托管C ++只是令人头疼。我们的大多数问题都发生在.NET 1.0 / 1.1上……也许现在情况有所好转。