Limitação interna mista de C++/CLI TypeLoadException:muitos campos

Question

Em uma missão para migrar alguma nova UI para o ambiente Gerenciado/C#, ativei recentemente o Common Language Runtime Support (/clr) em um grande projeto legado, que usa MFC em uma DLL compartilhada e depende de cerca de uma dúzia de outros projetos dentro de nosso solução geral.Este projeto é o núcleo de nosso aplicativo e conduziria qualquer código de UI gerenciado produzido (daí a necessidade de ativar o suporte clr para interoperabilidade).

Depois de corrigir uma série de pequenos erros e avisos, finalmente consegui compilar o aplicativo.No entanto, a execução do aplicativo causa uma EETypeLoadException e me deixa incapaz de depurar...

Fazendo algumas pesquisas, descobri que a causa era "System.TypeLoadException:Limitação interna:muitos campos." que ocorre logo no final da compilação.Eu então encontrei esse link que sugere dividir a montagem em duas ou mais DLLs.Porém, isso não é possível no meu caso, pois uma limitação que tenho é que o código legado permanece basicamente intocado.

Alguém pode sugerir outras soluções possíveis?Estou realmente em um beco sem saída aqui.

Answer 1

Certifique-se de que Habilitar pool de strings opção em Geração de código C/C++ está ativada.

Isso geralmente corrige esse problema, que é um daqueles "hein?" MS Limitações como o limite de 64k nas planilhas do Excel.Somente este afeta o número de símbolos que podem aparecer em uma montagem.

Answer 2

Você precisa ativar /clr para todo o projeto?Em vez disso, você poderia ativá-lo apenas para um pequeno número selecionado de arquivos e ter muito cuidado ao incluir o código gerenciado?Eu trabalho com um grande aplicativo C++/MFC e achamos muito difícil usar C++ gerenciado.Eu adoro C# e .NET, mas C++ gerenciado não tem sido nada além de uma dor de cabeça.A maioria dos nossos problemas aconteceu com o .NET 1.0/1.1 ...talvez as coisas estejam melhores agora.

Answer 3

Eu fiz isso com aplicativos de modo misto muito grandes (C#/C++) três vezes (3x) e, depois de colocar a correção acima em prática, nunca mais vi o erro.

E não, isso deve resultar em uma execução em tempo de execução um pouco mais rápida (no entanto, nada que você possa medir).

Mas concordo que é uma espécie de paliativo.O limite interno de símbolos não costumava ser um problema ou, se fosse, esse limite era muito maior.Então a MS mudou parte do código do carregador.Entrei no MSDN e falei sobre isso e me disseram em termos inequívocos: "só um idiota colocaria tantos símbolos em uma única montagem".

(Essa é uma das razões pelas quais não participo mais do MSDN.)

Bem, me considere estúpido, mas não acho que deveria ter que alterar a estrutura física do meu aplicativo, dividindo as coisas em DLLs satélites, apenas para contornar o fato de que o carregador decidiu que 10.001 símbolos é 1 a mais.

E como você apontou, muitas vezes não temos controle sobre como os assemblies/DLLs satélites são estruturados e o tipo de dependências que eles contêm.

Mas não acho que você verá esse erro novamente, de qualquer forma.