Espace de stockage insuffisant pour traiter cette commande dans Visual Studio 2008
Lorsque j'essaie de compiler un assembly dans VS 2008, j'ai (parfois, généralement après 2-3 heures de travail avec le projet) l'erreur suivante
Metadata file '[name].dll' could not be opened --
'Not enough storage is available to process this command.
Habituellement, pour m'en débarrasser, je dois redémarrer Visual Studio
L'assemblage que j'ai besoin d'utiliser dans mon projet est assez GRAND (> 70 Mo) 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 pour laquelle ma question est pourquoi cela se produit et ce que je dois faire pour l'arrêter.
J'ai suffisamment de mémoire libre sur mes disques et 2 Go RAM (seulement ~ 1,2 Go sont utilisés lorsque des exceptions se produisent)
J'ai cherché sur Google les réponses à des questions comme celle-ci.
Suggestions généralement liées à:
- au nombre de gestionnaires d'utilisateurs limité dans WinXP ...
- à la limite physique de mémoire disponible par processus
Je ne pense pas que l'un ou l'autre pourrait expliquer mon cas
Pour les gestionnaires d'utilisateurs et autres ressources de l'interface graphique - je ne pense pas que cela pourrait être un problème. Le grand assemblage de 70 Mo est en fait un code sans interface graphique qui fonctionne avec des sockets et implémente des analyseurs 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é avec 2 Go de mémoire (et, compte tenu de la segmentation de la mémoire, il est possible que je n'ai pas un segment libre suffisamment grand pour allouer une mémoire).
Cependant, il est difficile de croire que la segmentation pourrait être si importante après seulement 2-3 heures de travail avec le projet dans Visual Studio. Le Gestionnaire des tâches montre que VS consomme environ 400 à 500 Mo (OM + VM). Pendant la compilation, VS n'a besoin de charger que des métadonnées.
Eh bien, il y a beaucoup de classes et d'interfaces dans cette bibliothèque, mais je m'attends quand même à ce que 1-2 Mo soit plus que suffisant 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 à l'intérieur de CLR lors du chargement des métadonnées d'assemblage).
De plus, je dirais que la taille entière de l'assemblage est si grande que parce qu'elle est C++ CLI bibliothèque contenant d'autres bibliothèques gérées par um en une seule DLL. J'ai estimé (à l'aide de Reflector) que le code .NET (géré) représente environ 5 à 10% de cet assemblage.
Des idées sur la façon de définir la véritable raison de ce bug? Existe-t-il des restrictions ou des recommandations concernant la taille de l'assemblage .NET? ( Oui, je sais qu'il vaut la peine de penser à refactoriser et à diviser un grand assemblage en plusieurs petits morceaux, mais c'est un composant tiers, et je ne peux pas le reconstruire )
Dans mon cas, le correctif suivant a aidé: http://confluence.jetbrains.net/display/ReSharper/OutOfMemoryException+Fix
L'erreur est trompeuse. Il devrait vraiment dire "Un espace contigu suffisamment grand dans la mémoire virtuelle n'a pas pu être trouvé pour effectuer l'opération". Au fil du temps, les allocations et les désallocations d'espace mémoire virtuel le rendent fragmenté. Cela peut conduire à des situations où une allocation importante ne peut pas être remplie malgré la disponibilité d'un espace total important.
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 d'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 le mettrais pas dans la catégorie des improbables, en fait c'est la cause la plus probable.
Comme l'a souligné Anthony, le message d'erreur est un peu trompeur. Le problème est moins sur la taille de votre assembly et plus sur la quantité de mémoire contiguë disponible.
Le problème n'est probablement pas vraiment la taille de votre Assemblée. Il est beaucoup plus probable que quelque chose à l'intérieur de Visual Studio fragmente la mémoire au point qu'une génération ne puisse pas se terminer. Les suspects habituels pour ce type de problème sont
- Trop de projets dans la solution.
- Compléments tiers
Si vous avez plus de 10 projets dans la solution. Essayez de briser la solution et voyez si cela aide.
Si vous avez des compléments tiers, essayez de les désactiver un par un et voyez si le problème disparaît.
Si vous êtes simplement intéressé à le faire fonctionner, redémarrez votre ordinateur et cela fonctionnera comme un charme. J'ai eu le même genre d'erreur dans mon application, puis après avoir lu toutes les réponses ici sur stackoverflow, j'ai décidé de redémarrer d'abord mon ordinateur avant de faire d'autres modifications. Et cela m'a fait gagner beaucoup de temps.
J'obtiens cette erreur sur une de mes machines et étonnamment, ce problème n'est pas vu sur d'autres machines de développement. Il peut y avoir un problème avec 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 à nouveau la solution, cela commencera à fonctionner correctement. J'espère que cela sera utile pour quelqu'un en détresse ..
Une autre cause de ce problème peut être l'utilisation d'un trop grand nombre de jeux de données typés via le concepteur. ou d'autres types qui peuvent être créés via un concepteur comme de nombreux contrôles de databound sur de nombreux formulaires. J'imagine que vous êtes le genre de programmeur hardcore, mais qui ne glisserait pas une DS! :RÉ
par rapport à votre problème, Bogdan, avez-vous essayé de reproduire le problème sans votre composant c ++ chargé? Si vous ne pouvez pas, alors c'est peut-être ça. Comment chargez-vous le composant? avez-vous essayé d'autres techniques comme la reliure tardive, etc.? toute différence?
Supplémentaire: Oui, vous avez raison, les autres coupables sont de nombreux contrôles sur le formulaire. J'ai vu une fois ce même problème avec un développeur qui avait importé une application très VB6 sur .net. il avait littéralement des centaines de formes. Il obtiendrait un plantage périodique du IDE après quelques heures. Je suis presque sûr que c'était l'épuisement du thread. Cela pourrait valoir la peine de mettre en place une boîte Vanilla sans aucun complément chargé juste pour régner mais je suppose que vous êtes juste en train de frapper le mur en termes de limitation combinée de VS et de vos spécifications de boîte. Essayez d'exécuter Windows Vista 64 bits et installez des modules supplémentaires RAM RAM).
Je sais que cela fait longtemps que cela n'a pas été commenté, mais j'ai rencontré ce problème aujourd'hui avec une DLL telerik dans VS2010. Je n'avais jamais vu ce problème auparavant jusqu'à aujourd'hui, lorsque je faisais des changements de paramètres dans IE.
Il existe un paramètre dans Outils/Option dossier/Affichage dans la section Fichiers et dossiers appelé "Lancer les fenêtres de dossier dans un processus séparé".
Je ne suis pas sûr de la quantité de mémoire utilisée pour chaque fenêtre lors de l'utilisation de ce paramètre, mais jusqu'à aujourd'hui, je n'ai jamais fait vérifier cela. Après avoir vérifié cette option pour diverses raisons, j'ai commencé à obtenir le "stockage insuffisant pour traiter cette commande". La dll telerik est une dll de 18 Mo que nous utilisons située dans notre dossier de bibliothèque comme référence dans notre projet.
La décocher a résolu le problème.
Juste passer pour une autre solution possible
J'ai eu ce même problème et dans mon cas, le nom de l'exception était très trompeur. Le problème réel était que le DLL n'a pas pu être chargé du tout en raison d'un chemin non valide. L'exception que je recevais était "
J'ai utilisé l'attribut DllImport en C #, l'application ASP.NET avec la déclaration comme ci-dessous et cela provoquait l'exception:
[DllImport(@"Calculation/lib/supplier/SupplierModule.dll", CallingConvention = CallingConvention.StdCall, CharSet = CharSet.Ansi, EntryPoint = "FunctionName")]
Ci-dessous, un extrait de code de travail:
[DllImport(@"Calculation\lib\supplier\SupplierModule.dll", CallingConvention = CallingConvention.StdCall, CharSet = CharSet.Ansi, EntryPoint = "FunctionName")]
Le problème réel était d'utiliser des barres obliques dans le chemin, au lieu de barres obliques inverses. Cela m'a coûté beaucoup trop cher à comprendre, j'espère que cela aidera les autres.
J'ai également rencontré le même problème. Assurez-vous que le système d'exploitation Windows est en 64 bits. Je suis passé à Windows 64 bits à partir de Windows 32 bits. J'ai résolu le problème.
Si l'utilisation de la mémoire et VM la taille est petite pour devenv. Tuez explicitement "TOUTES" les instances de devenv.exe en cours d'exécution.
J'ai eu 3 devenv.exe en cours d'exécution alors que j'avais deux instances de Visual studion ouvertes devant.
C'était la solution dans mon cas.