管理対象リソースとは、基本的に、ガベージコレクターによって管理される「管理対象メモリ」を意味します。管理対象オブジェクト（管理対象メモリを使用する）への参照がなくなった場合、ガベージコレクタは（最終的に）そのメモリを解放します。
管理されていないリソースは、ガベージコレクターが知らないすべてです。例えば：
- ファイルを開く
- ネットワーク接続を開く
- 管理されていないメモリ
- XNAの場合：頂点バッファー、インデックスバッファー、テクスチャなど.
通常、これらのアンマネージリソースを解放する必要がありますbeforeそれらを管理するオブジェクトへの参照をすべて失います。これを行うには、そのオブジェクトでDisposeを呼び出すか、（C＃で）usingの呼び出しを処理するDisposeステートメントを使用します。
アンマネージリソースのDisposeを正しく無視すると、そのリソースを含むオブジェクトがガベージコレクションされると、ガベージコレクタが最終的にそれを処理します（これが「最終化」です）。ただし、ガベージコレクターはアンマネージリソースを認識しないため、それらを解放する必要があるかどうかを判断できません。したがって、プログラムのパフォーマンスが低下したり、リソースが完全に不足したりする可能性があります。
管理されていないリソースを処理するクラスを自分で実装する場合、DisposeおよびFinalizeを正しく実装するのはあなた次第です。
一部のユーザーは、開いているファイル、db接続、割り当てられたメモリ、ビットマップ、ファイルストリームなどを管理対象リソースにランク付けし、他のユーザーを管理対象外にランク付けします。 つまり管理されているか、管理されていないのか？
私の意見では、応答はより複雑です：.NETでファイルを開くときは、おそらく組み込みの.NETクラスSystem.IO.File、FileStreamまたは他の何かを使用します。通常の.NETクラスであるため、管理されます。しかし、それは実際にはファイルを開くラッパーであり、内部で「ダーティーな作業」を行い（Win32 dllを使用してオペレーティングシステムと通信し、低レベル関数またはアセンブラー命令を呼び出します）ます。そして、これは、.NETが管理していないことを知りません。ただし、アセンブラー命令を使用して自分でファイルを開き、.NETファイル関数をバイパスすることができます。その場合、ハンドルと開いているファイルは管理されていないリソースです。
DBについても同様です。DBアセンブリを使用する場合、DbConnectionなどのクラスがあり、それらは.NETに認識され、管理されます。しかし、彼らは管理されていない「汚い仕事」をラップします（サーバーにメモリを割り当て、それとの接続を確立します...）。このラッパークラスを使用せず、自分でネットワークソケットを開き、コマンドを使用して奇妙なデータベースと通信する場合、管理されません。
これらのラッパークラス（ファイル、DbConnectionなど）は管理されますが、ラッパーを使用せずに自分で「ダーティな作業」を行う場合、内部では管理されていないリソースを使用します。したがって、これらのラッパーはDispose/Finalizeパターンを実装します。ラッパーが不要になったときにプログラマーがアンマネージリソースを解放し、ラッパーがガベージコレクションされたときにアンマネージリソースを解放するのは、プログラマーの責任です。ラッパーは、ガベージコレクターによって正しくガベージコレクションされますが、内部のアンマネージリソースは、Dispose/Finalizeパターンを使用して収集されます。
組み込みの.NETまたはサードパーティのラッパークラスを使用せず、クラスでアセンブラー命令などによってファイルを開く場合、これらの開いているファイルは管理されないため、破棄/最終パターンを実装する必要があります。使用しない場合、メモリリークやリソースの永久ロックなど、使用しなくなった場合（ファイル操作が完了した場合）、またはアプリケーションが終了した後でも発生します。
しかし、これらのラッパーを使用するときもあなたの責任です。破棄/最終処理を実装する（IDisposableを実装することを認識している）場合は、破棄/最終処理パターンも実装し、これらのラッパーも破棄するか、アンマネージリソースを解放するようにシグナルを送信します。そうしないと、リソースは無期限に解放されますが、すぐに解放しても問題ありません（すぐにファイルを閉じて、数分/時間ランダムに開いたままブロックしないでください）。したがって、クラスのDisposeメソッドでは、使用するすべてのラッパーのDisposeメソッドを呼び出します。
管理されていないリソースは、.NETランタイム（CLR）（別名.NET以外のコード）の外部で実行されるリソースです。たとえば、Win32 APIのDLLの呼び出し、または記述された.dllの呼び出しC++で。
「管理されていないリソース」は物ではなく、責任です。オブジェクトがアンマネージリソースを所有している場合、（1）クリーンアップしないと問題を引き起こす可能性のある方法で外部のエンティティが操作され、（2）オブジェクトにはそのようなクリーンアップを実行するために必要な情報があり、責任があることを意味しますそれをするために。
多くの種類のアンマネージリソースは、さまざまな種類のオペレーティングシステムエンティティ（ファイル、GDIハンドル、割り当てられたメモリブロックなど）に非常に強く関連付けられていますが、すべてで共有される単一の種類のエンティティはありませんクリーンアップの責任以外。通常、オブジェクトにクリーンアップを実行する責任がある場合、オブジェクトに責任があるすべてのクリーンアップを実行するように指示するDisposeメソッドがあります。
場合によっては、オブジェクトは、誰も最初にDisposeを呼び出さずに放棄される可能性を考慮します。 GCは、オブジェクトが（Finalizeと呼ばれるルーチンを呼び出すことによって）放棄されたという通知を要求することを許可し、オブジェクトはこの通知を使用して自分でクリーンアップを実行できます。
「管理対象リソース」や「管理対象外リソース」などの用語は、残念ながら、異なる人々が異なることを意味するために使用しています。オブジェクトの観点から、クリーンアップの責任を持たない、Disposeが呼び出された場合にのみ処理されるクリーンアップの責任、またはDisposeを介して処理されるクリーンアップの責任があると考えると、より便利だと思いますまた、ファイナライズによって処理されます。
マネージリソースとアンマネージリソースの基本的な違いは、ガベージコレクターがすべてのマネージリソースについて知っていることです。ある時点でGCが実行され、マネージオブジェクトに関連付けられたすべてのメモリとリソースをクリーンアップします。 GCは、ファイル、ストリーム、ハンドルなどのアンマネージリソースを認識しないため、コードで明示的にクリーンアップしないと、メモリリークやロックされたリソースが発生します。
here から盗まれた場合は、投稿全体を自由に読んでください。
.NETマネージヒープでメモリが割り当てられるリソースは、マネージリソースです。 CLRはこの種のメモリを完全に認識しており、孤立しないようにすべてを行います。それ以外は管理されていません。たとえば、COMとの相互運用により、プロセスメモリ空間にオブジェクトが作成される場合がありますが、CLRはそれを処理しません。この場合、管理対象境界を越えて呼び出しを行う管理対象オブジェクトは、それを超えるものに対する責任を所有する必要があります。
まず、VB6またはC++プログラム（非Dotnetアプリケーション）の実行方法を理解しましょう。コンピューターは機械レベルのコードのみを理解することを知っています。マシンレベルのコードは、ネイティブコードまたはバイナリコードとも呼ばれます。したがって、それぞれの言語コンパイラであるVB6またはC++プログラムを実行すると、それぞれの言語ソースコードがネイティブコードにコンパイルされ、基礎となるオペレーティングシステムとハードウェアが理解できるようになります。
ネイティブコード（アンマネージコード）は、生成元のオペレーティングシステムに固有（ネイティブ）です。このコンパイル済みネイティブコードを使用して別のオペレーティングシステムで実行しようとすると、失敗します。したがって、このスタイルのプログラム実行の問題は、あるプラットフォームから別のプラットフォームに移植できないことです。
.Netプログラムの実行方法を理解しましょう。 dotnetを使用して、さまざまなタイプのアプリケーションを作成できます。 .NETアプリケーションの一般的なタイプには、Web、Windows、コンソール、およびモバイルアプリケーションが含まれます。アプリケーションの種類に関係なく、.NETアプリケーションを実行すると、次のことが起こります
.NETアプリケーションは、中間言語（IL）にコンパイルされます。 ILは、共通中間言語（CIL）およびMicrosoft中間言語（MSIL）とも呼ばれます。 .NETアプリケーションと非.NETアプリケーションの両方がアセンブリを生成します。アセンブリの拡張子は.DLLまたは.EXEです。たとえば、Windowsまたはコンソールアプリケーションをコンパイルすると、.EXEが取得されます。Webまたはクラスライブラリプロジェクトをコンパイルすると、.DLLが取得されます。 .NETアセンブリとNON .NETアセンブリの違いは、DOTNETアセンブリは中間言語形式であり、NON DOTNETアセンブリはネイティブコード形式であるということです。
NON DOTNETアプリケーションは、オペレーティングシステム上で直接実行できます。DOTNETアプリケーションは、共通言語ランタイム（CLR）と呼ばれる仮想環境上で実行されます。 CLRには、Just In-Time Compiler（JIT）と呼ばれるコンポーネントが含まれています。これは、中間言語を、基礎となるオペレーティングシステムが理解できるネイティブコードに変換します。
したがって、.NETでは、アプリケーションの実行は2つのステップで構成されます。1。言語コンパイラ、ソースコードを中間言語（IL）にコンパイルします。 。
.NETアセンブリはネイティブコードではなく、Intermedaite言語形式であるため、.NETアセンブリは、ターゲットプラットフォームに共通言語ランタイム（CLR）があれば、どのプラットフォームにも移植できます。ターゲットプラットフォームのCLRは、Intermedaite言語を、基になるオペレーティングシステムが理解できるネイティブコードに変換します。中間言語は、マネージコードとも呼ばれます。これは、CLRが内部で実行されるコードを管理するためです。たとえば、VB6プログラムでは、開発者はオブジェクトによって消費されたメモリの割り当てを解除する責任があります。プログラマがメモリの割り当てを解除するのを忘れると、メモリ不足の例外を検出するのが困難になる可能性があります。一方、.NETプログラマーは、オブジェクトによって消費されたメモリの割り当てを解除することを心配する必要はありません。自動メモリ管理は、GLR収集とも呼ばれ、CLRによって提供されます。ガベージコレクションとは別に、CLRによって提供される他の利点がいくつかあります。これについては、後のセッションで説明します。 CLRは中間言語を管理および実行しているため、中間言語（IL）はマネージコードとも呼ばれます。
.NETは、C＃、VB、J＃、C++などのさまざまなプログラミング言語をサポートしています。 C＃、VB、およびJ＃はマネージコード（IL）のみを生成できますが、C++はマネージコード（IL）とアンマネージコード（ネイティブコード）の両方を生成できます。
ネイティブコードは、プログラムを閉じた後に破棄されるため、どこにも永続的に保存されません。プログラムを再度実行すると、ネイティブコードが再び生成されます。
.NETプログラムは、Javaプログラムの実行に似ています。 JavaにはバイトコードとJVM（Java仮想マシン）があり、.NETのように中間言語とCLR（共通言語ランタイム）
これはこのリンクから提供されます-彼は素晴らしい家庭教師です。 http://csharp-video-tutorials.blogspot.in/2012/07/net-program-execution-part-1.html