Недостаточно памяти для обработки этой команды в VisualStudio 2008

Question

Когда я пытаюсь скомпилировать сборку в VS 2008, я получаю (иногда, обычно после 2-3 часов работы с проектом) следующую ошибку

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

Обычно, чтобы избавиться от этого, мне нужно перезапустить Visual Studio

Сборка, которую мне нужно использовать в моем проекте, достаточно БОЛЬШАЯ (> 70 Мб), и, вероятно, это является причиной этой ошибки, я никогда не видел ничего подобного в моих предыдущих проектах. Хорошо, если это причина, по которой мой вопрос, почему это происходит и что мне нужно сделать, чтобы остановить это.

На моих дисках достаточно свободной памяти и 2 ГБ ОЗУ (при возникновении исключения используется только ~ 1,2 ГБ)

Я гуглил ответы на подобные вопросы.

Предложения, обычно относящиеся к:

1. к числу пользовательских обработчиков, ограниченных в WinXP ...
2. до физического лимита памяти, доступной для процесса

Я не думаю, что кто-либо мог бы объяснить мой случай

Для пользовательских обработчиков и других ресурсов графического интерфейса - я не думаю, что это может быть проблемой. Большая 70-мегабайтная сборка на самом деле является кодом без GUI, который работает с сокетами и реализует парсеры проприетарных протоколов. В моем текущем проекте у меня есть только 3 формы GUI, с общим количеством элементов управления GUI <100. </p>

Полагаю, мой случай ближе к тому факту, что в Windows XP адресное пространство процесса ограничено 2 ГБ памяти (и, учитывая сегментацию памяти, возможно, у меня недостаточно свободного сегмента, чтобы выделить память).

Однако трудно поверить, что сегментация может быть такой большой после всего лишь 2-3 часов работы с проектом в Visual Studio. Диспетчер задач показывает, что VS потребляет около 400-500 Мб (OM + VM). Во время компиляции VS нужно загружать только метаданные.

Хорошо, в этой библиотеке много классов и интерфейсов, но все же я ожидаю, что 1-2 Мбайт более чем достаточно для выделения метаданных , которые используются компилятором для поиска всех открытых классов. и интерфейсы (хотя это только мое предложение, я не знаю, что именно происходит внутри CLR при загрузке метаданных сборки).

Кроме того, я бы сказал, что весь размер сборки настолько велик только потому, что это библиотека C++ CLI, в которой другие библиотеки, управляемые um, статически связаны в один DLL. Я подсчитал (используя Reflector), что .NET (управляемый) код составляет примерно 5-10% этой сборки.

Есть идеи, как определить истинную причину этой ошибки? Существуют ли какие-либо ограничения или рекомендации относительно размера сборки .NET? ( Да, я знаю, что стоит подумать о рефакторинге и разбиении большой сборки на несколько более мелких частей, но это сторонний компонент, и я не могу перестроить его )

Answer 1

Ошибка вводит в заблуждение. На самом деле следует сказать: «В виртуальной памяти не найдено достаточно непрерывного пространства для выполнения операции». С течением времени распределение и освобождение пространства виртуальной памяти приводит к его фрагментации. Это может привести к ситуациям, когда большое выделение не может быть заполнено, несмотря на то, что имеется достаточно свободного места.

Я думаю, это то, к чему относится ваша «сегментация». Не зная всех деталей всего остального, что необходимо загрузить, и другой деятельности, которая занимает 2-3 часа, трудно сказать, действительно ли это является причиной. Однако я бы не отнес это к категории маловероятных, на самом деле это наиболее вероятная причина.

Answer 2

В моем случае помогло следующее исправление: http://confluence.jetbrains.net/display/ReSharper/OutOfMemoryException+Fix

Answer 3

Как указал Энтони, сообщение об ошибке немного вводит в заблуждение. Проблема не столько в том, насколько велика ваша сборка, сколько в том, сколько свободной памяти доступно.

Проблема скорее всего не в размере вашей сборки. Скорее всего, что-то внутри Visual Studio фрагментирует память до такой степени, что сборка не может быть завершена. Обычные подозреваемые для этого типа проблемы

1. Слишком много проектов в решении.
2. Сторонние надстройки

Если в решении более 10 проектов. Попробуйте разбить решение и посмотрите, поможет ли это.

Если у вас есть какие-либо сторонние надстройки, попробуйте отключить их по одному и посмотреть, исчезнет ли проблема.

Answer 4

Если вы просто заинтересованы, чтобы он работал, перезагрузите компьютер, и он будет работать как чудо. У меня была такая же ошибка в моем приложении, а затем, прочитав все ответы здесь в stackoverflow, я решил сначала перезагрузить компьютер, прежде чем делать какие-либо другие изменения. И это сэкономило мне много времени.

Answer 5

Я получаю эту ошибку на одной из моих машин и, что удивительно, эта проблема не видна на других машинах разработки. Может быть что-то не так с установкой VS. Но я нашел более простое решение. Если я удалю .suo файл решения и снова открою решение, оно начнет работать без сбоев. Надеюсь, это будет полезно для тех, кто в беде ..

Answer 6

Другой причиной этой проблемы может быть использование слишком большого числа типизированных наборов данных через конструктор. или другие типы, которые могут быть созданы с помощью дизайнера, например, множество элементов управления с привязкой к данным для множества форм. Я полагаю, что вы тот самый хардкорный программист, который не будет тянуть и бросать DS! : D

в связи с вашей проблемой, Богдан, вы пытались воспроизвести проблему без загрузки вашего компонента c ++? Если вы не можете, то, возможно, это это. Как вы загружаете компонент? Вы пробовали другие методы, такие как позднее связывание и т. д.? какая разница?

Дополнительно: Да, вы правы, другие преступники имеют много элементов управления в форме. Однажды я увидел такую ​​же проблему с разработчиком, который импортировал очень приложение VB6 в .net. у него были буквально сотни форм. Через пару часов он получит периодический сбой IDE. Я почти уверен, что это истощение ниток. Возможно, стоит установить ванильный блок без загружаемых надстроек только для того, чтобы исключить надстройки, но я предполагаю, что вы просто бьете в стену с точки зрения комбинированного ограничения VS и характеристик вашего бокса. Попробуйте запустить 64-битную Windows Vista и установить несколько дополнительных модулей оперативной памяти.

Answer 7

У меня была такая же проблема, и в моем случае имя исключения очень вводило в заблуждение. Фактическая проблема заключалась в том, что DLL не могла быть загружена вообще из-за неверного пути. Исключение, которое я получаю, говорит "

Я использовал атрибут DllImport в C #, приложении ASP.NET с объявлением, как показано ниже, и это вызывало исключение:

   [DllImport(@"Calculation/lib/supplier/SupplierModule.dll", CallingConvention = CallingConvention.StdCall, CharSet = CharSet.Ansi, EntryPoint = "FunctionName")]

Ниже приведен фрагмент кода:

[DllImport(@"Calculation\lib\supplier\SupplierModule.dll", CallingConvention = CallingConvention.StdCall, CharSet = CharSet.Ansi, EntryPoint = "FunctionName")]

Фактическая проблема заключалась в использовании прямой косой черты в пути вместо обратной косой черты. Это стоило мне слишком много, чтобы понять, надеюсь, это поможет другим.

Answer 8

Я тоже сталкивался с такой же проблемой. Убедитесь, что ОС Windows с 64-битной. Я переключился на Windows 64bit с Windows 32bit. Я решил проблему.

Answer 9

Я знаю, что прошло много времени с тех пор, как это было прокомментировано, но я столкнулся с этой проблемой сегодня с telerik dll в VS2010. Я никогда раньше не сталкивался с этой проблемой до сегодняшнего дня, когда вносил некоторые изменения в настройки IE.

В Tools / Folder Option / View в разделе Files and Folders есть настройка, которая называется «Запускать окна папок в отдельном процессе».

Я не уверен, какой объем памяти используется для каждого окна при использовании этого параметра, но до сегодняшнего дня я никогда не проверял этот параметр. После проверки этой опции по разным причинам я начал получать сообщение «недостаточно места для обработки этой команды». Telerik dll - это dll на 18 Мб, который мы используем, расположенный в нашей папке библиотеки в качестве ссылки в нашем проекте.

Снятие отметки решило проблему.

Просто выдать другое возможное решение

Answer 10

Если использование памяти и размер виртуальной машины малы для devenv. Явно уничтожить «ВСЕ» экземпляры запущенного devenv.exe.

У меня был запущен 3 devenv.exe, где передо мной открылись два экземпляра Visual Studion.

Это было решением в моем случае.