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

Question

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

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

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

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

Answer 1

Убедитесь, что включена опция Включить объединение строк в C / C ++. Генерация кода.

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

Answer 2

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

Answer 3

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

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

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

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

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

И, как вы указали, мы часто не контролируем структуру сборок / сателлитов и их зависимости.

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