爲了將一些新的UI遷移到Managed/C＃land，我最近在一個大的傳統項目上打開了Common Language Runtime Support（/ clr）在共享DLL中，並依賴於我們整體解決方案中的大約十幾個其他項目。這個項目是我們應用程序的核心，並且會驅動任何生成的託管UI代碼（因此需要打開對interop的clr支持）。混合的C++/CLI TypeLoadException內部限制：太多字段
固定一噸的小小動作錯誤和警告之後，我終於設法將應用程序編譯.. 然而，運行的應用程序會導致EETypeLoadException並讓我無法調試...
做一些挖，我發現原因是「System.TypeLoadException：內部限制：太多領域。」這在編譯結束時發生。然後我發現this link這表明將程序集分解成兩個或更多dll。然而，在我的情況下這是不可能的，因爲我的限制是遺留代碼基本上保持不變。
任何人都可以提出任何其他可能的解決方案嗎？我真的在這裏死路一條。
確保已打開C/C++代碼生成下的Enable String Pooling選項。
這通常會解決這個問題，這是其中的一個「嗯？」 MS限制，如Excel電子表格中的64k限制。只有這一個會影響程序集中可能出現的符號數量。
我已經用非常大的混合模式（C＃/ C++）應用程序三次（3x）完成此操作，並且一旦將上述修復程序放置到位，再也沒有看到錯誤。
沒有，如果有的話這將導致稍快運行時執行（你所能衡量。然而，什麼都沒有。）
但我同意這是一個權宜之計有點的。對符號的內部限制並不是一個問題，或者如果是這樣，限制要高得多。然後MS改變了一些加載器代碼。我進入了MSDN並對其進行了抨擊，並毫不含糊地被告知，「只有一個白癡纔會將這麼多符號放在一個程序集中」。
（這是我在MSDN上不再參加的原因之一。）
好，彩箱笨，但我不認爲我應該改變我的應用程序的物理結構，打破東西出來成衛星DLL，只是爲了解決裝載者已經決定10,001個符號的事實太多了。如你所指出的，我們經常無法控制程序集/附屬DLL的結構，以及它們所包含的依賴關係。
但我不認爲你會再次看到這個錯誤，無論如何。
您是否需要爲整個項目開啓/關閉？你可以打開它只爲一小部分文件選擇，並非常小心如何包括託管代碼？我使用大型的C++/MFC應用程序，我們發現使用託管C++非常困難。我喜歡C＃和.NET，但託管C++一直只是頭痛。我們的大部分問題都發生在.NET 1.0/1.1上......現在情況可能會好一些。
我仍然看到調試64版本中的字符串池的錯誤。我們不會因爲Visual Studio中的錯誤而在程序集中創建多個託管程序集來拆分程序集。使用VS 2008。 – 2013-10-25 19:32:29