title: Not enough storage is available to process this command in VisualStudio 2008
body: <p>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</p>
  
  <pre><code>Metadata file '[name].dll' could not be opened -- 
         'Not enough storage is available to process this command.
  </code></pre>
  
  <p>Usually to get rid of that I need to restart Visual Studio</p>
  
  <p>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.</p>
  
  <p>I have enough of free memory on my drives and 2Gb RAM (only ~1.2 Gb are utilized when exception happens)</p>
  
  <p>I googled for the answers to the questions like this.</p>
  
  <p>Suggestions usually related to:</p>
  
  <blockquote>
    <ol>
    <li>to the number of user handlers that is limited in WinXP...</li>
    <li>to the physical limit of memory available per process</li>
    </ol>
  </blockquote>
  
  <p>I don't think either could explain my case</p>
  
  <p>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 &lt; 100.</p>
  
  <p>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). </p>
  
  <p>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. </p>
  
  <p>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 <strong>metadata</strong> 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 <code>CLR</code> when it loads assembly metadata).</p>
  
  <p>In addition, I would say that entire assembly size is so big only because it is <code>C++ CLI</code> library that has other um-managed libraries statically linked into one <code>DLL</code>. I estimated (using Reflector) that .NET (managed) code is approx 5-10% of this assembly.</p>
  
  <p>Any ideas how to define the real reason of that bug? Are there any restrictions or recommendations as to .NET assembly size? (<em>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</em>)</p>