C# 在 VisualStudio 2008 中没有足够的存储空间来处理此命令

Not enough storage is available to process this command in VisualStudio 2008

提问by Bogdan_Ch

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

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

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

通常要摆脱这种情况，我需要重新启动 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.

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

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

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

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

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

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.

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

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

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.

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

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 metadatathat 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 CLRwhen it loads assembly metadata).

好吧，该库中有很多类和接口，但我仍然希望 1-2 Mb 足以分配编译器用来查找所有公共类和接口的元数据（尽管这只是我的建议） ，我不知道CLR加载程序集元数据时内部究竟发生了什么）。

In addition, I would say that entire assembly size is so big only because it is C++ CLIlibrary 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.

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

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)

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

采纳答案by zuraff

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

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

回答by AnthonyWJones

The error is misleading. It really should say "A large enough contiguous space in virtual memory could not be found to perform the operation". Over time allocations and deallocations of virtual memory space leads to it becoming fragmented. This can lead to situations where a large allocation cannot be filled despite there being a plenty total space available.

该错误具有误导性。它真的应该说“在虚拟内存中找不到足够大的连续空间来执行操作”。随着时间的推移，虚拟内存空间的分配和释放会导致它变得碎片化。这可能导致尽管有足够的可用总空间但无法填充大量分配的情况。

I think this what your "segmentation" is refering to. Without knowing all the details of everything else that needs to load and other activity which occupies the 2-3 hour period its difficult to say whether this really is the cause. However I would not put it into the category of unlikely, in fact it is the most likely cause.

我认为这就是您的“分段”所指的内容。在不知道需要加载的所有其他内容和占用 2-3 小时时间的其他活动的所有细节的情况下，很难说这是否真的是原因。不过我不会把它归入不太可能的范畴，事实上它是最可能的原因。

回答by JaredPar

As Anthony pointed out, the error message is a bit misleading. The issue is less about how big your assembly is and more about how much contiguous memory is available.

正如 Anthony 指出的，错误信息有点误导。问题不是关于你的程序集有多大，而是关于有多少连续内存可用。

The problem is likely not really the size of your assembly. It's much more likely that something inside of Visual Studio is fragmenting memory to the point that a build cannot complete. The usual suspects for this type of problem are

问题可能不是真正的程序集大小。更有可能是 Visual Studio 内部的某些东西将内存碎片化到无法完成构建的程度。此类问题的常见嫌疑人是

1. Too many projects in the solution.
2. Third party add-ins

1. 解决方案中的项目太多。
2. 第三方加载项

If you have more than say 10 projects in the solution. Try breaking up the solution and see if that helps.

如果您的解决方案中有超过 10 个项目。尝试分解解决方案，看看是否有帮助。

If you have any 3rd party addins, try disabling them one at a time and seeing if the problem goes away.

如果您有任何 3rd 方插件，请尝试一次禁用它们并查看问题是否消失。

回答by JaredPar

Another cause for this problem can be using too many typed datasets via the designer. or other types that can be instaniated via a designer like lots of databound controls on lots of forms. I imagine your the sort of hardcore programmer though who wouldn't drag n' drop a DS! :D

此问题的另一个原因可能是通过设计器使用了过多的类型化数据集。或可以通过设计器实例化的其他类型，例如大量表单上的大量数据绑定控件。我想你是那种不会拖拽 DS 的铁杆程序员！:D

in relation to your problem, Bogdan, have you tried to reproduce the problem w/o your c++ component loaded? If you can't then maybe its this. How are you loading the component? have you tried other techniques like late binding, etc? any difference?

关于您的问题，Bogdan，您是否尝试在未加载 C++ 组件的情况下重现该问题？如果你不能，那么也许就是这个。你是如何加载组件的？您是否尝试过其他技术，例如后期绑定等？有什么区别吗？

Additional: Yes you are right, the other culprits are lots of controls on the form. I once saw this same issue with a dev that had imported a very VB6 app over to .net. he had literally 100's of forms. He would get periodic crashing of the IDE after a couple of hours. I'm pretty sure it was thread exhaustion. It might be worth setting up a vanilla box w/ no addins loaded just to rule addins out, but my guess is you are just hitting the wall in terms of a combined limiation of VS and your box specs. Try running Windows Vista 64bit and install some extra RAM modules.

附加：是的，您是对的，其他罪魁祸首是表单上的大量控件。我曾经在一个开发人员中看到过同样的问题，该开发人员将一个非常 VB6 的应用程序导入到 .net。他有 100 多种形式。几个小时后，他会定期崩溃 IDE。我很确定这是线程耗尽。可能值得设置一个没有加载插件的香草盒子来排除插件，但我猜你只是在 VS 和盒子规格的组合限制方面碰壁了。尝试运行 Windows Vista 64 位并安装一些额外的 RAM 模块。

回答by Sudheer Kumar

I am getting this error on one of my machines and surprisingly, this problem is not seen on other dev machines. May be something wrong with VS installation. But I found an easier solution. If I delete the .suo file of teh solution and re-open the solution again, it will start working smoothly. Hope this will be useful for somebody in distress..

我在我的一台机器上遇到了这个错误，令人惊讶的是，在其他开发机器上没有看到这个问题。VS 安装可能有问题。但我找到了一个更简单的解决方案。如果我删除解决方案的 .suo 文件并再次重新打开解决方案，它将开始顺利运行。希望这对遇险的人有用..

回答by adeel41

If you are just interested to make it work then restart your computer and it will work like a charm. I Had same kind of error in my application and then after reading all of the answer here at stackoverflow, I decided to first restart my computer before doing any other modifications. And it saved me a lot of time.

如果您只是想让它工作，那么重新启动计算机，它就会像魅力一样工作。我在我的应用程序中遇到了同样的错误，然后在 stackoverflow 上阅读了所有答案之后，我决定在进行任何其他修改之前先重新启动我的计算机。它为我节省了很多时间。

回答by Jas

If memory usage and VM size is small for devenv. Explicitly kill "ALL" instances of devenv.exe running.

如果 devenv 的内存使用量和 VM 大小较小。显式终止正在运行的 devenv.exe 的“所有”实例。

I had 3 devenv.exe running where as I had two instances of Visual studion opened in front.

我运行了 3 个 devenv.exe，因为我在前面打开了两个 Visual Studion 实例。

That was solution in my case.

在我的情况下，这是解决方案。

回答by Jon

I know it has been a long time since this was commented on but I ran into this exact issue today with a telerik dll in VS2010. I had never seen this issue before until today when I was making some setting changes in IE.

我知道自从对此发表评论以来已经很长时间了，但我今天在 VS2010 中使用 Telerik dll 遇到了这个确切的问题。我以前从未见过这个问题，直到今天我在 IE 中进行一些设置更改。

There is a setting in Tools/Folder Option/View in the Files and Folders section called "Launch folder windows in a separate process".

文件和文件夹部分的工具/文件夹选项/视图中有一个设置，称为“在单独的进程中启动文件夹窗口”。

I am not sure the amount of memory used for each window when using this setting but until today I have never had this checked. After checking this option for misc reasons I started getting the "not enough storage is available to process this command". The telerik dll is an 18mb dll that we are using located in our library folder as a reference in our project.

我不确定使用此设置时每个窗口使用的内存量，但直到今天我从未检查过这个。出于其他原因检查此选项后，我开始收到“没有足够的存储空间来处理此命令”。Telerik dll 是一个 18mb dll，我们使用它位于我们的库文件夹中作为我们项目的参考。

Unchecking this resolved the problem.

取消选中此项解决了问题。

Just passing along as another possible solution

只是作为另一种可能的解决方案传递

回答by Kiran K Katkar

I also faced the same problem. Make sure that the windows os is with 64bit. I switched to windows 64bit from windows 32bit. I problem got solved.

我也面临同样的问题。确保 windows 操作系统是 64 位的。我从 windows 32bit 切换到 windows 64bit。我的问题解决了。

回答by Sami Viitala

I had this same issue and in my case, the exception name was very misleading. The actual problem was that the DLL couldn't be loaded at all due to invalid path. The exception i was getting said "

我遇到了同样的问题，就我而言，异常名称非常具有误导性。实际问题是由于路径无效，根本无法加载 DLL。我得到的例外说“

I used DllImport attribute in C#, ASP.NET application with declaration like below and it was causing the exception:

我在 C#、ASP.NET 应用程序中使用了 DllImport 属性，声明如下，它导致了异常：

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

Below is working code snippet:

下面是工作代码片段：

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

The actual problem was using forward slashes in path, instead of back slashes. This cost me way too much to figure out, hope this will help others.

实际问题是在路径中使用正斜杠，而不是反斜杠。这花费了我太多的时间来弄清楚，希望这会对其他人有所帮助。