Lorsque j'essaie de compiler un assemblage dans VS 2008, j'obtiens (occasionnellement, généralement après 2-3 heures de travail avec le projet) l'erreur suivante
Le fichier de métadonnées '[nom].dll' n'a pas pu être ouvert -- 'L'espace disponible est insuffisant pour traiter cette commande.
En général, pour s'en débarrasser, je dois redémarrer Visual Studio.
L'assemblage que je dois utiliser dans mon projet est assez GROS (> 70 Mb) et c'est probablement la raison de ce bug, je n'ai jamais vu quelque chose comme ça dans mes projets précédents. Ok, si c'est la raison, ma question est de savoir pourquoi cela se produit et ce que je dois faire pour l'arrêter.
J'ai assez de mémoire libre sur mes disques et 2 Go de RAM (seulement ~1,2 Go sont utilisés quand l'exception se produit).
J'ai cherché sur Google les réponses aux questions de ce genre.
Les suggestions portent généralement sur : 1) au nombre de gestionnaires d'utilisateurs qui est limité dans WinXP... 2) à la limite physique de la mémoire disponible par processus.
Je ne pense pas que l'un ou l'autre puisse expliquer mon cas.
Pour les gestionnaires d'utilisateurs et les autres ressources de l'interface graphique, je ne pense pas que cela puisse être un problème. Le gros assemblage de 70Mo est en fait un code sans interface graphique qui fonctionne avec des sockets et implémente des parsers de protocoles propriétaires. Dans mon projet actuel, je n'ai que 3 formulaires GUI, avec un nombre total de contrôles GUI < 100.
Je suppose que mon cas est plus proche du fait que, dans Windows XP, l'espace d'adressage du processus est limité à 2 Go de mémoire (et, compte tenu de la segmentation de la mémoire, il est possible que je ne dispose pas d'un segment libre suffisamment grand pour allouer une mémoire). Cependant, il est difficile de croire que la segmentation puisse être si importante après seulement 2-3 heures de travail avec le projet dans Visual Studio. Le gestionnaire de tâches montre que VS consomme environ 400-500 Mb (OM + VM). Pendant la compilation, VS n'a besoin de charger que les méta-données. Eh bien, il y a beaucoup de classes et d'interfaces dans cette bibliothèque, mais je m'attendrais quand même à ce que 1 à 2 Mo soient plus que suffisants pour allouer métadonnées qui est utilisé par le compilateur pour trouver toutes les classes et interfaces publiques (bien que ce ne soit que ma suggestion, je ne sais pas ce qui se passe exactement dans le CLR quand il charge les métadonnées d'assemblage).
De plus, je dirais que la taille de l'ensemble est si importante uniquement parce qu'il s'agit d'une bibliothèque CLI C++ qui contient d'autres bibliothèques non gérées liées statiquement dans une DLL. J'ai estimé (en utilisant Reflector) que le code .NET (géré) représente environ 5 à 10 % de cet assemblage.
Avez-vous des idées pour définir la véritable raison de ce bug ? Existe-t-il des restrictions ou des recommandations quant à la taille des assemblages .NET ? ( Oui, je sais que cela vaut la peine de penser à refactorer et à diviser un grand assemblage en plusieurs petits morceaux, mais il s'agit d'un composant tiers et je ne peux pas le reconstruire. )
