没有足够的存储可在2008年的VisualStudio处理此命令 [英] Not enough storage is available to process this command in VisualStudio 2008

问题描述

当我尝试在VS 2008编译程序集，我得到了（偶尔，一般2-3小时的工作，与项目后）以下的误差

 元数据文件[名] .DLL'不能被打开 -  
'没有足够的存储是可用来处理此命令。 
  

通常摆脱，我需要重新启动Visual Studio

我需要在我的项目中使用的组件足够大（> 70 MB），可能这是错误的原因，我从来没有见过像这样的东西的一些我以前的项目。好吧，如果是这样的原因，我的问题是，为什么出现这种情况，我需要做些什么来阻止它的东西。

我有足够的可用内存在我的硬盘和2GB内存（当发生异常只有约1.2 GB的使用）

我GOOGLE了回答这样的问题。

通常与建议：

1. 来是在WinXP用户有限的处理器的数量...


2. 来记忆每个进程中可用的物理限制

有关用户处理程序和其他图形用户界面资源 - 我不认为这可能是一个问题。大70MB装配实际上是与插座进行操作和实现的专有协议分析器图形界面的代码。在我当前的项目，我只有3 GUI形式，具有GUI控件和LT的总数; 100。

我想我的情况更接近事实，在Windows XP中进程的地址空间与2 GB内存（并考虑到内存分割限制，可能是我没有免费的段足够大来分配内存）。

然而，这是很难相信的分割可能只是2-3个小时在Visual Studio项目工作后这么大。任务管理器显示VS消耗大约400-500 MB（OM + VM）。在编译期间，VS需要仅加载的元数据。

嗯，有很多在该库中的类和接口，但我仍然可以预料，1至2 MB更多的则是足以分配的元所使用的编译器找到的所有公共类和接口（虽然这只是我的建议，我不知道里面是什么 CLR 究竟发生时，它加载组装元数据）。

另外，我要说的是整个装配尺寸这么大，不仅因为它是 C ++ CLI 在有其他UM管理库库静态链接到一个 DLL 。我估计（使用反射）的.NET（托管）代码，约为本次大会的5-10％。

任何想法如何定义错误的真正原因？有没有为.NET程序集大小的任何限制或建议？ （是的，我知道，这值得思考的重构和分裂一个大的组装成若干小片段，但它是一个第三方组件，我不能重建它的）

解决方案

在我的情况下修复帮助：
的 http://confluence.jetbrains.net/display/ReSharper/OutOfMemoryException+Fix

When I try to compile an assembly in VS 2008, I got (occasionally, usually after 2-3 hours of work with the project) the following error

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

Usually to get rid of that I need to restart Visual Studio

The assembly I need to use in my project is BIG enough (> 70 Mb) and probably this is the reason of that bug, I've never seen some thing like this in my previous projects. Ok, if this is the reason my question is why this happens and what I need to do to stop it.

I have enough of free memory on my drives and 2Gb RAM (only ~1.2 Gb are utilized when exception happens)

I googled for the answers to the questions like this.

Suggestions usually related to:

1. to the number of user handlers that is limited in WinXP...
2. to the physical limit of memory available per process

I don't think either could explain my case

For user handlers and other GUI resources - I don't think this could be a problem. The big 70Mb assembly is actually a GUI-less code that operates with sockets and implements parsers of a proprietary protocols. In my current project I have only 3 GUI forms, with total number of GUI controls < 100.

I suppose my case is closer to the fact that in Windows XP the process address space is limited with 2 GB memory (and, taking into account memory segmentation, it is possible that I don't have a free segment large enough to allocate a memory).

However, it is hard to believe that segmentation could be so big after just 2-3 hours of working with the project in Visual Studio. Task Manager shows that VS consumes about 400-500 Mb (OM + VM). During compilation, VS need to load only meta-data.

Well, there are a lot of classes and interfaces in that library, but still I would expect that 1-2 Mb is more then enough to allocate metadata that is used by compiler to find all public classes and interfaces (though it is only my suggestion, I don't know what exactly happens inside CLR when it loads assembly metadata).

In addition, I would say that entire assembly size is so big only because it is C++ CLI library that has other um-managed libraries statically linked into one DLL. I estimated (using Reflector) that .NET (managed) code is approx 5-10% of this assembly.

Any ideas how to define the real reason of that bug? Are there any restrictions or recommendations as to .NET assembly size? (Yes I know that it worth thinking of refactoring and splitting a big assembly into several smaller pieces, but it is a 3rd party component, and I can't rebuilt it)

解决方案

In my case the following fix helped: http://confluence.jetbrains.net/display/ReSharper/OutOfMemoryException+Fix

这篇关于没有足够的存储可在2008年的VisualStudio处理此命令的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！