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