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

问题描述

当我尝试在 VS 2008 中编译程序集时，我得到以下错误(偶尔，通常是在项目工作 2-3 小时后)

元数据文件 '[name].dll' 无法打开 --'没有足够的存储空间来处理这个命令.

通常要摆脱这种情况，我需要重新启动 Visual Studio

我需要在我的项目中使用的程序集足够大(> 70 Mb)，这可能是该错误的原因，我在以前的项目中从未见过这样的事情.好吧，如果这就是我的问题是为什么会发生这种情况以及我需要做些什么来阻止它.

我的驱动器上有足够的可用内存和 2Gb RAM(发生异常时仅使用 ~1.2 Gb)

我在谷歌上搜索了此类问题的答案.

建议通常与:

<块引用>

1. WinXP 中限制的用户处理程序数量...
2. 达到每个进程可用内存的物理限制

我认为两者都无法解释我的情况

对于用户处理程序和其他 GUI 资源 - 我认为这不是问题.这个 70Mb 的大程序集实际上是一个无 GUI 的代码，它使用套接字进行操作并实现专有协议的解析器.在我当前的项目中，我只有 3 个 GUI 窗体，GUI 控件的总数 <;100.

我想我的情况更接近于这样一个事实，即在 Windows XP 中，进程地址空间受到 2 GB 内存的限制(并且，考虑到内存分段，我可能没有足够大的空闲段来分配内存).

然而，很难相信在 Visual Studio 中使用该项目仅 2-3 小时后，细分会如此之大.任务管理器显示 VS 消耗大约 400-500 Mb (OM + VM).在编译过程中，VS 只需要加载元数据.

嗯，那个库中有很多类和接口，但我仍然希望 1-2 Mb 足以分配编译器用来查找所有公共的元数据类和接口(虽然这只是我的建议，但我不知道 CLR 在加载程序集元数据时到底发生了什么).

此外，我想说整个程序集的大小之所以如此之大，只是因为它是 C++ CLI 库，它具有静态链接到一个 DLL 中的其他 um 管理库.我估计(使用 Reflector).NET(托管)代码约占该程序集的 5-10%.

任何想法如何定义该错误的真正原因?.NET 程序集大小是否有任何限制或建议?(是的，我知道值得考虑将一个大的程序集重构和拆分成几个更小的部分，但它是第 3 方组件，我无法重建它)

解决方案

就我而言，以下修复有帮助: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

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