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

Question

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

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

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

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

Answer 1

Убедитесь, что опция Enable String Pooling под кодом поколения C/C++ включена.

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

Answer 2

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

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

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

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

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

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

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

Answer 3

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