uando tento compilar um assembly no VS 2008, recebo (ocasionalmente, geralmente após 2-3 horas de trabalho com o projeto) o seguinte er

Metadata file '[name].dll' could not be opened -- 
       'Not enough storage is available to process this command.

Normalmente, para me livrar disso, preciso reiniciar o Visual Studio

A montagem que eu preciso usar no meu projeto é GRANDE o suficiente (> 70 Mb) e, provavelmente, esse é o motivo desse erro, nunca vi algo assim nos meus projetos anteriores. Ok, se esse é o motivo, minha pergunta é por que isso acontece e o que preciso fazer para impedir iss

Tenho memória livre suficiente em minhas unidades e 2 GB de RAM (apenas ~ 1,2 Gb são utilizados quando a exceção acontec

Pesquisei no Google as respostas para perguntas como est

Sugestões geralmente relacionadas a:

para o número de manipuladores de usuário limitados no WinXP ... até o limite físico de memória disponível por processo

Acho que também não poderia explicar meu caso

Para manipuladores de usuários e outros recursos da GUI - não acho que isso possa ser um problema. O grande conjunto de 70Mb é na verdade um código sem GUI que opera com soquetes e implementa analisadores de protocolos proprietários. No meu projeto atual, tenho apenas 3 formulários da GUI, com número total de controles da GUI <100.

Suponho que meu caso esteja mais próximo do fato de que no Windows XP o espaço de endereço do processo é limitado a 2 GB de memória (e, levando em consideração a segmentação da memória, é possível que eu não tenha um segmento livre grande o suficiente para alocar um memória)

No entanto, é difícil acreditar que a segmentação possa ser tão grande após apenas 2-3 horas de trabalho com o projeto no Visual Studio. O Gerenciador de tarefas mostra que o VS consome cerca de 400-500 Mb (OM + VM). Durante a compilação, o VS precisa carregar apenas metadados.

Bem, existem muitas classes e interfaces nessa biblioteca, mas ainda assim eu esperaria que 1-2 Mb seja mais que suficiente para alocar metadados usado pelo compilador para encontrar todas as classes e interfaces públicas (embora seja apenas minha sugestão, não sei o que exatamente acontece dentro deCLR quando carrega os metadados da montagem

Além disso, eu diria que todo o tamanho da montagem é tão grande apenas porque éC++ CLI biblioteca que possui outras bibliotecas gerenciadas um estaticamente vinculadas em umaDLL. Estimei (usando o Reflector) que o código .NET (gerenciado) é de aproximadamente 5 a 10% deste assembl

Alguma idéia de como definir a verdadeira razão desse bug? Existem restrições ou recomendações quanto ao tamanho do assembly .NET? im, eu sei que vale a pena pensar em refatorar e dividir uma grande montagem em várias partes menores, mas é um componente de terceiros e não posso reconstruí-l)