My<cod/>.net
Mixed C++ / CLI TypeLoadException внутреннее ограничение: слишком много полей
Стремясь перенести некоторые новые UI в Managed/C# земли, я недавно включил поддержку Common Language Runtime Support (/clr) в большом устаревшем проекте, который использует MFC в общем DLL и опирается на около десятка других проектов в рамках нашего общего решения. Этот проект является ядром нашего приложения и будет управлять любым управляемым кодом UI, который создается (следовательно, необходимо включить поддержку clr для interop).
После исправления тонны мелких мелких ошибок и предупреждений мне наконец удалось заставить приложение компилироваться.. Однако запуск приложения вызывает EETypeLoadException и оставляет меня неспособным выполнить отладку...
Немного покопавшись, я обнаружил, что причина была "System.TypeLoadException: внутреннее ограничение: слишком много полей.- что происходит прямо в конце компиляции. Затем я нашел эту ссылку , которая предлагает разбить assembly на две или более библиотек DLL. Однако в моем случае это невозможно, поскольку ограничение, которое я имею, заключается в том, что унаследованный код в основном остается нетронутым.
Может ли кто-нибудь предложить другие возможные решения? Я действительно в тупике здесь.
Убедитесь, что включен параметр включить объединение строк под C/C++ генерацией кода.
Это обычно устраняет эту проблему, которая является одним из тех "huh?" MS ограничений, таких как ограничение 64k для Excel электронных таблиц. Только это влияет на количество символов, которые могут появиться в assembly.
Вам нужно включить /clr для всего проекта? Не могли бы вы вместо этого включить его только для небольшого количества выбранных файлов и быть очень осторожными при включении управляемого кода? Я работаю с большим приложением C++/MFC, и мы обнаружили, что очень трудно использовать управляемый C++. Я люблю C# и .NET, но управляемый C++ был не чем иным, как головной болью. Большинство наших проблем произошло с .NET 1.0/1.1 ... может быть, теперь все наладилось.
Я сделал это с очень большими смешанными режимами (C#/C++) приложений три раза (3x) и один раз поставив выше исправление на место никогда не видел ошибку снова.
И нет, если что-то это должно привести к немного более быстрому выполнению во время выполнения (ничего, что вы могли бы когда-либо измерить, однако.)
Но я согласен, что это своего рода временная остановка. Внутренний лимит на символы не был проблемой, а если и был, то этот лимит был намного выше. Затем MS изменил часть кода загрузчика. Я попал на MSDN и разглагольствовал об этом, и мне сказали в недвусмысленных выражениях: "только идиот может поместить столько символов в один assembly".
(Что является одной из причин, по которой я больше не участвую в MSDN.)
Ну, пусть я дурак, но я не думаю, что мне нужно менять физическую структуру моего приложения, разбивая вещи на спутник DLLs, просто чтобы обойти тот факт, что загрузчик решил, что 10 001 символ-это 1 слишком много.
И, как вы уже отмечали, мы часто не можем контролировать, как сборки/satellite DLLs являются структурой, и какие зависимости они содержат.
Но я не думаю, что вы снова увидите эту ошибку, в любом случае.