Недостаточно памяти для обработки команды в VisualStudio 2008
когда я пытаюсь скомпилировать сборку в VS 2008, я получил (иногда, обычно после 2-3 часов работы с проектом) следующую ошибку
Metadata file '[name].dll' could not be opened --
'Not enough storage is available to process this command.
обычно, чтобы избавиться от этого, мне нужно перезапустить Visual Studio
сборка, которую мне нужно использовать в моем проекте, достаточно велика (>70 Мб), и, вероятно, это причина этой ошибки, я никогда не видел ничего подобного в моих предыдущих проектах. Хорошо, если это причина, мой вопрос: почему это происходит и что мне нужно сделать, чтобы остановить это.
у меня достаточно свободной памяти на моих дисках и 2GB RAM (только ~1.2 Gb используются, когда происходит исключение)
Я искал в гугле ответы на такие вопросы.
предложения, обычно связанные с:
- к числу обработчиков пользователей, которое ограничено в WinXP...
- до физического предела памяти, доступной для каждого процесса
Я тоже не думаю мог бы объяснить мой случай
для обработчиков пользователей и других ресурсов GUI - я не думаю, что это может быть проблемой. Большая сборка 70Mb на самом деле представляет собой код без GUI, который работает с сокетами и реализует синтаксические анализаторы проприетарных протоколов. В моем текущем проекте у меня есть только 3 формы GUI, с общим количеством элементов управления GUI
Я полагаю, что мой случай ближе к тому, что в 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? (Да, я знаю, что стоит подумать о рефакторинге и разделении большой сборки на несколько меньших частей, но это сторонний компонент, и я не могу его перестроить)
10 ответов
в моем случае помогло следующее исправление: http://confluence.jetbrains.net/display/ReSharper/OutOfMemoryException + Fix
ошибка вводит в заблуждение. Он действительно должен сказать: "достаточно большое смежное пространство в виртуальной памяти не может быть найдено для выполнения операции". Со временем выделения и освобождения пространства виртуальной памяти приводит к его фрагментации. Это может привести к ситуациям, когда большое распределение не может быть заполнено, несмотря на наличие большого общего пространства.
Я думаю, что это то, на что ссылается ваша "сегментация". Не зная всех деталей всего остального. то, что нужно загрузить и другую деятельность, которая занимает 2-3-часовой период, трудно сказать, действительно ли это причина. Однако я бы не поставил его в категорию маловероятного, на самом деле это наиболее вероятная причина.
Как отметил Энтони, сообщение об ошибке немного вводит в заблуждение. Проблема заключается не в том, насколько велика ваша сборка, а в том, сколько непрерывной памяти доступно.
проблема, скорее всего, не в размере вашей сборки. Гораздо более вероятно, что что-то внутри Visual Studio фрагментирует память до такой степени, что сборка не может быть завершена. Обычные подозреваемые для этого типа проблемы
- слишком много проектов в решение.
- сторонние надстройки
Если у вас есть более 10 проектов в решении. Попробуйте разбить решение и посмотрите, поможет ли это.
Если у вас есть какие-либо сторонние дополнения, попробуйте отключить их по одному и посмотреть, исчезает ли проблема.
Я получаю эту ошибку на одной из моих машин, и удивительно, что эта проблема не наблюдается на других машинах dev. Может быть что-то не так с установкой VS. Но я нашел более простое решение. Если я удалю .suo файл teh solution и снова открыть решение, он начнет работать плавно. Надеюсь, это будет полезно для кого-то в беде..
Если вам просто интересно заставить его работать, перезагрузите компьютер, и он будет работать как шарм. У меня была такая же ошибка в моем приложении, а затем, прочитав весь ответ здесь, в stackoverflow, я решил сначала перезагрузить компьютер, прежде чем делать какие-либо другие изменения. И это сэкономило мне много времени.
другой причиной этой проблемы может быть использование слишком много типизированных наборов данных через конструктор. или других типов, которые могут быть instaniated через конструктор, как много элементов управления с привязкой к данным на множество форм. Я представляю себе ваш вид хардкорного программиста, хотя кто бы не перетаскивал DS! : D
в отношении вашей проблемы, Богдан, вы пытались воспроизвести проблему без загруженного компонента c++? Если вы не можете, то, может быть, это. Как вы загружаете компонент? ты пробовал? другие методы, такие как поздняя привязка и т. д.? какая разница?
дополнительные: Да, вы правы, другие виновники-это множество элементов управления в форме. Я однажды видел эту же проблему с разработчиком, который импортировал очень приложение VB6 .сеть. у него было буквально 100 бланков. Через пару часов у него будет периодический сбой IDE. Я почти уверен, что это было истощение нитей. Возможно, стоит настроить ванильную коробку без добавлений, загруженных только для исключения добавлений, но я предполагаю, что вы просто ударяя по стене с точки зрения комбинированного ограничения VS и ваших спецификаций коробки. Попробуйте запустить Windows Vista 64bit и установить дополнительные модули RAM.
Если использование памяти и размер VM невелики для devenv. Явно убить" все " экземпляры devenv.exe выполняется.
У меня было 3 devenv.exe работает там, где у меня было два экземпляра Visual studion, открытых спереди.
Это было решение в моем случае.
Я знаю, что прошло много времени с тех пор, как это было прокомментировано, но я столкнулся с этой точной проблемой сегодня с dll telerik в VS2010. Я никогда не видел эту проблему до сегодняшнего дня, когда я делал некоторые изменения настроек в IE.
в разделе "Инструменты/папка"/ "просмотр" в разделе "Файлы и папки" есть параметр "запустить папку windows в отдельном процессе".
Я не уверен, что объем памяти, используемый для каждого окна при использовании этого параметра, но до сегодняшнего дня я никогда не проверяли. После проверки этой опции по разным причинам я начал получать "недостаточно памяти для обработки этой команды". Библиотека telerik dll-это библиотека 18 Мб, которую мы используем в нашей папке библиотеки в качестве ссылки в нашем проекте.
снимите проблема.
просто передаю как еще одно возможное решение
Я тоже столкнулся с той же проблемой. Убедитесь, что ОС windows имеет 64bit. Я переключился на windows 64bit из windows 32bit. Проблема решена.
у меня была такая же проблема, и в моем случае имя исключения было очень вводящим в заблуждение. Фактическая проблема заключалась в том, что 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")]
фактическая проблема заключалась в использовании прямых косых черт в пути, а не назад разрезы. Это стоило мне слишком много, чтобы понять, надеюсь, это поможет другим.