Il n'y a pas assez de mémoire disponible pour traiter cette commande dans VisualStudio 2008.

Question

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. )

Answer 1

L'erreur est trompeuse. Elle devrait plutôt dire "Un espace contigu suffisamment grand dans la mémoire virtuelle n'a pu être trouvé pour effectuer l'opération". Au fil du temps, les allocations et les désallocations de l'espace mémoire virtuel entraînent sa fragmentation. Cela peut conduire à des situations où une allocation importante ne peut être remplie alors qu'il y a beaucoup d'espace total disponible.

Je pense que c'est à cela que se réfère votre "segmentation". Sans connaître tous les détails de tout ce qui doit être chargé et des autres activités qui occupent la période de 2 à 3 heures, il est difficile de dire si c'est vraiment la cause. Cependant, je ne la mettrais pas dans la catégorie des causes improbables, en fait, c'est la cause la plus probable.

Answer 2

Dans mon cas, la solution suivante m'a aidé : http://confluence.jetbrains.net/display/ReSharper/OutOfMemoryException+Fix

Answer 3

Comme Anthony l'a souligné, le message d'erreur est un peu trompeur. Le problème concerne moins la taille de votre assemblage que la quantité de mémoire contiguë disponible.

Le problème n'est probablement pas vraiment la taille de votre assemblage. Il est beaucoup plus probable que quelque chose à l'intérieur de Visual Studio fragmente la mémoire au point qu'une construction ne peut pas se terminer. Les suspects habituels pour ce type de problème sont

1. Trop de projets dans la solution.
2. Compléments de tiers

Si vous avez plus de 10 projets dans la solution. Essayez de diviser la solution et voyez si cela peut vous aider.

Si vous avez des modules complémentaires tiers, essayez de les désactiver un par un pour voir si le problème disparaît.

Answer 4

J'obtiens cette erreur sur l'une de mes machines et, étonnamment, ce problème ne se pose pas sur les autres machines de développement. Peut-être que quelque chose ne va pas dans l'installation de VS. Mais j'ai trouvé une solution plus simple. Si je supprime le fichier .suo de la solution et que je rouvre la solution, elle commencera à fonctionner sans problème. J'espère que cela sera utile pour quelqu'un en détresse

Answer 5

Si vous souhaitez simplement le faire fonctionner, redémarrez votre ordinateur et il fonctionnera comme un charme. J'avais le même genre d'erreur dans mon application et après avoir lu toutes les réponses ici sur stackoverflow, j'ai décidé de redémarrer mon ordinateur avant de faire d'autres modifications. Et cela m'a fait gagner beaucoup de temps.