Смешанный C++ / CLI TypeLoadException Внутреннее ограничение: слишком много полей

В стремлении перенести некоторый новый пользовательский интерфейс в среду Managed / C# я недавно включил поддержку Common Language Runtime Support (/ clr) в большом устаревшем проекте, который использует MFC в общей DLL и полагается примерно на дюжину других проектов в рамках нашей общее решение. Этот проект является ядром нашего приложения и будет управлять любым создаваемым управляемым кодом пользовательского интерфейса (следовательно, необходимо включить поддержку clr для взаимодействия).

После исправления множества мелких ошибок и предупреждений мне, наконец, удалось заставить приложение скомпилироваться ... Однако запуск приложения вызывает исключение EETypeLoadException и оставляет меня неспособным отлаживать ...

Покопавшись, я обнаружил, что причиной является «System.TypeLoadException: внутреннее ограничение: слишком много полей». что происходит в самом конце компиляции. Затем я нашел эту ссылку, которая предлагает разбить сборку на две или более DLL. Однако в моем случае это невозможно, поскольку у меня есть ограничение в том, что унаследованный код в основном остается нетронутым.

Может ли кто-нибудь предложить другие возможные решения? Я действительно в тупике.

Ответов (3)

Решение

Убедитесь, что параметр « Включить пул строк» ​​в разделе «Генерация кода C/C++» включен.

Это обычно решает эту проблему, которая является одним из тех «а?» Ограничения MS, такие как ограничение в 64 КБ для электронных таблиц Excel. Только это влияет на количество символов, которые могут появиться в сборке.

Я проделал это с очень большими приложениями смешанного режима (C# / C++) три раза (3 раза), и после того, как исправил вышеуказанное исправление, больше никогда не видел ошибки.

И нет, во всяком случае, это должно привести к немного более быстрому выполнению во время выполнения (впрочем, ничего, что вы когда-либо могли бы измерить).

Но я согласен, что это временная мера. Внутренний лимит на символы раньше не был проблемой, а если и был, то этот лимит был намного выше. Затем MS изменила часть кода загрузчика. Я зашел на MSDN и начал болтать об этом, и мне недвусмысленно сказали: «Только идиот поместит такое количество символов в одну сборку».

(Это одна из причин, по которой я больше не участвую в MSDN.)

Что ж, раскрасьте меня в тупик, но я не думаю, что мне нужно менять физическую структуру моего приложения, разбивая вещи на вспомогательные библиотеки DLL, просто чтобы обойти тот факт, что загрузчик решил, что 10 001 символ - это слишком много.

И, как вы отметили, мы часто не можем контролировать структуру сборок / вспомогательных DLL и типы зависимостей, которые они содержат.

Но я не думаю, что вы в любом случае снова увидите эту ошибку.

Вам нужно включить / clr для всего проекта? Не могли бы вы вместо этого включить его только для небольшого выбранного количества файлов и быть очень осторожными при включении управляемого кода? Я работаю с большим приложением C++ / MFC, и нам очень трудно использовать управляемый C++. Я люблю C# и .NET, но управляемый C++ был не чем иным, как головной болью. Большинство наших проблем произошло с .NET 1.0 / 1.1 ... может быть, сейчас дела обстоят лучше.