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

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

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

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

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

18.08.2008 16:11:14
3 ОТВЕТА
РЕШЕНИЕ

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

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

8
22.02.2013 21:34:39

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

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

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

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

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

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

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

2
18.08.2008 17:33:24
Я все еще вижу ошибку с пулами строк в сборках отладки 64. Мы не разбиваем сборку из-за ошибок в Visual Studio и создания нескольких управляемых сборок в решении. Использование VS 2008.
Adam Bruss 25.10.2013 19:32:29

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

3
18.08.2008 17:40:27