Visual Studio 2008でこのコマンドを処理するのに十分なストレージが利用できない
VS 2008でアセンブリをコンパイルしようとすると、（通常、プロジェクトで2〜3時間作業した後）次のエラーが発生しました
Metadata file '[name].dll' could not be opened --
'Not enough storage is available to process this command.
通常、それを取り除くには、Visual Studioを再起動する必要があります
私のプロジェクトで使用する必要のあるアセンブリは十分に大きい（> 70 Mb）ので、おそらくこれがそのバグの原因であり、以前のプロジェクトではこのようなものを見たことはありません。わかった、これが私の質問がこれが起こる理由であり、それを止めるために私がすべきことであるなら.
ドライブに十分な空きメモリがあり、2Gb RAM（例外が発生した場合、〜1.2Gbのみが使用されます）
私はこのような質問に対する答えを探しました。
通常に関連する提案：
- winXPで制限されているユーザーハンドラーの数...
- プロセスごとに使用可能なメモリの物理的制限まで
私の場合も説明できないと思います
ユーザーハンドラーやその他のGUIリソースについては、これが問題になるとは思いません。大きな70Mbアセンブリは、実際にはソケットで動作し、独自のプロトコルのパーサーを実装するGUIなしのコードです。現在のプロジェクトでは、GUIコントロールの総数が100未満のGUIフォームが3つしかありません。
私の場合は、WindowsではXPプロセスのアドレス空間は2GBのメモリで制限されているという事実に近いと思われます（メモリのセグメンテーションを考慮すると、持っていない可能性がありますメモリを割り当てるのに十分な大きさの空きセグメント）。
ただし、Visual Studioでプロジェクトを2〜3時間操作しただけで、セグメンテーションが非常に大きくなるとは考えにくいです。タスクマネージャーは、VSが約400〜500 Mb（OM + VM）を消費することを示しています。コンパイル中、VSはメタデータのみをロードする必要があります。
そのライブラリには多くのクラスとインターフェイスがありますが、それでも1-2 Mbで十分に割り当てられると期待していますメタデータこれは、すべてのパブリッククラスとインターフェイスを見つけるためにコンパイラによって使用されます（これは私の提案にすぎませんが、アセンブリメタデータを読み込むときにCLR内で正確に何が起こるかわかりません）。
さらに、アセンブリ全体のサイズは、C++ CLI 1つのDLLに静的にリンクされた他のum管理ライブラリを持つライブラリ。 （リフレクターを使用して）.NET（マネージド）コードはこのアセンブリの約5〜10％であると推定しました。
そのバグの本当の理由を定義する方法はありますか？ .NETアセンブリのサイズに関して制限や推奨事項はありますか？ （はい、大きなアセンブリをリファクタリングしていくつかの小さな部分に分割することを考える価値があることは知っていますが、サードパーティのコンポーネントであり、再構築できません）
エラーは誤解を招くものです。 「仮想メモリ内の十分な大きさの連続したスペースが、操作を実行するために見つかりませんでした」と言う必要があります。時間が経つにつれて、仮想メモリ空間の割り当てと割り当て解除が断片化します。これにより、使用可能な合計スペースが十分にあるにも関わらず、大きな割り当てを満たせない状況が発生する可能性があります。
これがあなたの「セグメンテーション」が指しているものだと思います。ロードする必要のある他のすべての詳細や、2〜3時間を占める他のアクティビティの詳細をすべて把握していなければ、これが本当に原因であるかどうかを判断することは困難です。しかし、私はそれをありそうもないカテゴリに入れません。実際、それが最も可能性の高い原因です。
アンソニーが指摘したように、エラーメッセージは少し誤解を招く恐れがあります。問題は、アセンブリの大きさについてではなく、使用可能な連続メモリの量についてです。
問題は、実際にはアセンブリのサイズではない可能性があります。 Visual Studio内の何かが、ビルドを完了できないほどメモリを断片化している可能性がはるかに高くなります。このタイプの問題の通常の容疑者は次のとおりです。
- ソリューション内のプロジェクトが多すぎます。
- サードパーティのアドイン
ソリューションに10以上のプロジェクトがある場合。ソリューションを分割してみて、それが役立つかどうかを確認してください。
サードパーティのアドインがある場合は、一度に1つずつ無効にして、問題が解決するかどうかを確認してください。
動作させたいだけの場合は、コンピューターを再起動してください。私はアプリケーションに同じ種類のエラーがあり、stackoverflowですべての答えを読んだ後、他の変更を行う前にコンピューターを再起動することにしました。そして、それは私に多くの時間を節約しました。
私のマシンの1つでこのエラーが発生していますが、驚くことに、この問題は他の開発マシンでは見られません。 VSのインストールに問題がある可能性があります。しかし、私は簡単な解決策を見つけました。ソリューションの.suoファイルを削除して、ソリューションを再度開くと、スムーズに動作し始めます。これが苦しんでいる人に役立つことを願っています。
この問題の別の原因は、デザイナーを介して入力されたデータセットが多すぎることです。または、多くのフォーム上の多くのデータバインドコントロールのように、デザイナーを介してインスタンス化できる他のタイプ。 DSをドラッグアンドドロップしないだろうが、あなたのようなハードコアプログラマーを想像してください！ ：D
あなたの問題に関連して、ボグダン、C++コンポーネントがロードされていない問題を再現しようとしましたか？それができない場合は、おそらくこれです。コンポーネントをどのようにロードしていますか？遅延バインディングなどの他の手法を試しましたか？違いはありますか？
追加：はい、あなたは正しいです、他の犯人はフォーム上の多くのコントロールです。私はかつて、非常にVB6アプリを.netにインポートした開発者でこの同じ問題を見ました。彼は文字通り何百ものフォームを持っていました。彼はIDEの数時間後に定期的にクラッシュします。それはスレッドの枯渇だったと確信しています。バニラボックスをセットアップする価値があるかもしれません。アドインは出ていますが、VSとボックス仕様の組み合わせ制限という点で、あなたはただ壁にぶつかっていると思います。WindowsVista 64ビットを実行して、追加のRAMモジュールをインストールしてください。
これがコメントされてから長い時間が経っていることは知っていますが、VS2010のtelerik dllでこの問題に今日出くわしました。 IEで設定を変更する今日まで、この問題は一度も見たことがありませんでした。
「別のプロセスでフォルダーウィンドウを起動する」というファイルとフォルダーのセクションのツール/フォルダーオプション/表示に設定があります。
この設定を使用するときに各ウィンドウに使用されるメモリの量はわかりませんが、今日までこれをチェックしていません。さまざまな理由でこのオプションをチェックした後、「このコマンドを処理するのに十分なストレージがありません」というメッセージを受け取り始めました。 telerik dllは、プロジェクトの参照としてライブラリフォルダーにある18mb dllです。
これをオフにすると、問題は解決しました。
別の可能な解決策としてただ渡す
私はこれと同じ問題を抱えており、私の場合、例外名は非常に誤解を招くものでした。実際の問題は、無効なパスのためにDLLをまったくロードできなかったということでした。
以下のような宣言でC＃のASP.NETアプリケーションでDllImport属性を使用すると、例外が発生していました：
[DllImport(@"Calculation/lib/supplier/SupplierModule.dll", CallingConvention = CallingConvention.StdCall, CharSet = CharSet.Ansi, EntryPoint = "FunctionName")]
以下は、動作するコードスニペットです。
[DllImport(@"Calculation\lib\supplier\SupplierModule.dll", CallingConvention = CallingConvention.StdCall, CharSet = CharSet.Ansi, EntryPoint = "FunctionName")]
実際の問題は、バックスラッシュの代わりにパスにスラッシュを使用することでした。これは理解するのに多額の費用がかかり、他の人の助けになることを願っています。
私も同じ問題に直面しました。 Windows OSが64ビットであることを確認してください。 Windows 32ビットからWindows 64ビットに切り替えました。問題が解決しました。
メモリ使用量とVMサイズがdevenvに対して小さい場合。実行中のdevenv.exeの「ALL」インスタンスを明示的に強制終了します。
Visual Studionの2つのインスタンスが前面で開かれているため、3つのdevenv.exeを実行しました。
それが私の場合の解決策でした。