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

Question

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

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

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

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

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

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

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