Недостаточно памяти для обработки этой команды в 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 (только при использовании исключения - 1,2 Гб)

Я искал ответы на такие вопросы, как это.

Предложения, обычно связанные с:

к числу обработчиков пользователей, которые ограничены в WinXP...

к физическому пределу памяти, доступному для каждого процесса.

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

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

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

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

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

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

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

Ответ 1

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

Ответ 2

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

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

Ответ 3

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

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

Слишком много проектов в решении.
Надстройки третьих лиц

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

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

Ответ 7

Если использование памяти и размер виртуальной машины мал для devenv. Явно убить "ВСЕ" экземпляры devenv.exe.

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

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

Ответ 8

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

В разделе "Инструменты/Папка" / "Вид" в разделе "Файлы и папки" есть параметр "Запуск окон папки в отдельном процессе".

Я не уверен, сколько памяти используется для каждого окна при использовании этого параметра, но до сегодняшнего дня я никогда не проверял это. После проверки этой опции по разным причинам я начал получать "недостаточно для хранения этой команды". DLL telerik - это dll 18mb, которые мы используем в нашей библиотеке в качестве ссылки в нашем проекте.

Устранение этой проблемы устраняет проблему.

Просто пройдя как еще одно возможное решение

Ответ 9

Я также столкнулся с той же проблемой. Убедитесь, что окна os имеют 64 бит. Я перешел на Windows 64bit из окон 32bit. Проблема была решена.

Ответ 10

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

Я использовал атрибут DllImport в приложении С#, 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")]

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