没有足够的存储空间来在 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
The assembly I need to use in我的项目足够大（> 70 Mb），可能这就是该错误的原因，我在以前的项目中从未见过这样的事情。 好吧，如果这是原因，我的问题是为什么会发生这种情况以及我需要做什么来阻止它。
我的驱动器和 2Gb RAM 上有足够的可用内存（发生异常时仅使用约 1.2 Gb），
我在 google 上搜索了此类问题的答案。
建议通常与以下内容相关：
- WinXP 中限制的用户处理程序数量...
- 每个进程可用内存的物理限制
我认为两者都不能解释我的情况
对于用户处理程序和其他 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 库，并且将其他 um 管理的库静态链接到一个 DLL 中。 我估计（使用 Reflector）.NET（托管）代码大约占该程序集的 5-10%。
有什么想法如何定义该错误的真正原因吗？ 对于 .NET 程序集大小是否有任何限制或建议？ （是的，我知道值得考虑重构并将一个大组件拆分为几个较小的部分，但它是第 3 方组件，我无法重建它）
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:
- to the number of user handlers that is limited in WinXP...
- 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)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
该错误具有误导性。 它确实应该说“无法在虚拟内存中找到足够大的连续空间来执行该操作”。 随着时间的推移，虚拟内存空间的分配和释放会导致其变得碎片化。 这可能会导致尽管有足够的可用总空间，但仍无法填充大量分配的情况。
我认为这就是您的“细分”所指的。 在不了解需要加载的所有其他内容以及占用 2-3 小时时间的其他活动的所有详细信息的情况下，很难说这是否确实是原因。 但我不会将其归入不太可能的类别，事实上这是最有可能的原因。
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.
就我而言，以下修复有所帮助：
http://confluence. jetbrains.net/display/ReSharper/OutOfMemoryException+Fix
In my case the following fix helped:
http://confluence.jetbrains.net/display/ReSharper/OutOfMemoryException+Fix
正如安东尼指出的那样，错误消息有点误导。 问题不在于程序集有多大，而在于有多少连续内存可用。
问题可能并不在于您的程序集的大小。 更有可能的是，Visual Studio 内部的某些东西正在将内存碎片化到构建无法完成的程度。 此类问题的常见嫌疑是
如果解决方案中的项目超过 10 个。 尝试分解该解决方案，看看是否有帮助。
如果您有任何第 3 方插件，请尝试一次禁用它们，看看问题是否消失。
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.
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
If you have more than say 10 projects in the solution. Try breaking up the solution and see if that helps.
If you have any 3rd party addins, try disabling them one at a time and seeing if the problem goes away.
我在我的一台机器上遇到此错误，令人惊讶的是，在其他开发机器上没有看到此问题。 可能是VS安装有问题。
但我找到了一个更简单的解决方案。
如果我删除该解决方案的 .suo 文件并再次重新打开该解决方案，它将开始顺利工作。
希望这对陷入困境的人有用。
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..
如果您只是想让它工作，那么重新启动计算机，它就会像魅力一样工作。 我的应用程序中出现了同样的错误，然后在阅读了 stackoverflow 上的所有答案后，我决定先重新启动计算机，然后再进行任何其他修改。 它节省了我很多时间。
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.
导致此问题的另一个原因可能是通过设计器使用了太多类型化的数据集。 或可以通过设计器实例化的其他类型，例如许多表单上的大量数据绑定控件。
我想你是那种不会拖放 DS 的硬核程序员！ :D
关于您的问题，Bogdan，您是否尝试在未加载 C++ 组件的情况下重现该问题？ 如果你不能，那么也许就是这个。 您如何加载组件？ 您是否尝试过其他技术，例如后期绑定等？ 有什么区别吗？
额外的：
是的，你是对的，其他罪魁祸首是表单上的大量控件。 我曾经在一位将 VB6 应用程序导入到 .net 的开发人员中看到过同样的问题。 他实际上有数百份表格。 几个小时后，他会遇到 IDE 周期性崩溃的情况。 我很确定这是线程耗尽。 可能值得设置一个不加载任何插件的普通盒子，只是为了排除插件，但我的猜测是，就 VS 和你的盒子规格的综合限制而言，你只是碰壁了。 尝试运行 Windows Vista 64 位并安装一些额外的 RAM 模块。
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
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?
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.
如果 devenv 的内存使用量和 VM 大小较小。
显式终止正在运行的 devenv.exe 的“所有”实例。
我运行了 3 个 devenv.exe，因为我在前面打开了两个 Visual studion 实例。
这就是我的情况的解决方案。
If memory usage and VM size is small for devenv.
Explicitly kill "ALL" instances of devenv.exe running.
I had 3 devenv.exe running where as I had two instances of Visual studion opened in front.
That was solution in my case.
我知道自从有人对此发表评论以来已经很长时间了，但今天我在 VS2010 中使用 telerik dll 遇到了这个确切的问题。 我以前从未见过这个问题，直到今天我在 IE 中进行一些设置更改时才遇到这个问题。
“文件和文件夹”部分的“工具/文件夹选项/视图”中有一个设置，称为“在单独的进程中启动文件夹窗口”。
我不确定使用此设置时每个窗口使用的内存量，但直到今天我从未检查过此设置。 由于其他原因检查此选项后，我开始收到“没有足够的存储空间来处理此命令”。 telerik dll 是一个 18mb 的 dll，我们使用它位于库文件夹中作为项目中的参考。
取消选中此选项可以解决问题。
只是作为另一种可能的解决方案传递
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.
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.
Unchecking this resolved the problem.
Just passing along as another possible solution
我也面临同样的问题。
确保 Windows 操作系统是 64 位。
我从Windows 32位切换到Windows 64位。 我的问题解决了。
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.
我遇到了同样的问题，就我而言，异常名称非常具有误导性。 实际问题是由于路径无效，根本无法加载 DLL。 我遇到的异常是“
我在 C#、ASP.NET 应用程序中使用了 DllImport 属性，其声明如下所示，它导致了异常：
下面是工作代码片段：
实际问题是在路径中使用正斜杠，而不是反斜杠。这让我花了太多时间才弄清楚，希望这对其他人有帮助。
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 "
I used DllImport attribute in C#, ASP.NET application with declaration like below and it was causing the exception:
Below is working code snippet:
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.