ひとことで言うと
.NET Assembly Inspectorは、コンパイル済みアプリケーションのための「デジタルの解剖台」だ。DLLやEXEをこじ開けて、元のC#ソースコードをリバースエンジニアリングしたり、その裏で動く低レベルな命令を探索したりできる。
解決する課題
このツールが存在する理由を理解するには、2000年代初頭まで時計の針を戻す必要がある。Microsoftが.NET Frameworkを発表したとき、彼らはWindowsコードのコンパイル方法を根本から変えてしまった。C#（またはVB.NET）のコードを、C++のように特定のプロセッサアーキテクチャに縛られたマシンコード（機械語）に直接変換するのではなく、.NETコンパイラはコードを「中途半端な状態」へと翻訳する。
この中間フォーマットはCIL（Common Intermediate Language、歴史的にはMSILと呼ばれていた）と呼ばれる。これが大量の記述的なメタデータと一緒にパッケージ化され、.dllや.exeファイルになる。これがアセンブリだ。アプリを実行するまさにその最後の瞬間に、.NETランタイム（CLR）がしゃしゃり出てきて、そのCILを「Just-In-Time（JIT）」で生のマシンコードへとコンパイルする。
この設計は天才的だった。一度コードを書けば、理論上は.NETランタイムが存在する場所ならどこでも実行できるようになったからだ。しかし、非常に興味深い副産物も生まれた。.NETアセンブリはめちゃくちゃ「おしゃべり」なのだ。 JITコンパイラが安全にコードを実行するためには、そのコードについてのすべてを知っている必要がある。そのため、アセンブリには元のソースコードの構造情報のほぼすべてが含まれることになった。クラス、メソッド、プロパティ、ジェネリック型など、すべてが完璧に保存されている。
じゃあ何が問題なのか？時にDLLはブラックボックスのように振る舞う。ソースコードがハードディスクのクラッシュで失われたレガシーアプリを引き継ぐことになったかもしれない。ろくなドキュメントもないのにNullReferenceExceptionを吐き続けるクローズドソースのサードパーティライブラリを使っているかもしれない。あるいは、ひとりの開発者として、async/awaitやLINQのような綺麗に整った「シンタックスシュガー（構文糖衣）」の下に、C#コンパイラがどんな泥臭くて複雑なロジックを隠しているのかを知りたくなることもあるだろう。
これまで、こうしたブラックボックスをこじ開けるには、Lutz Roederの伝説的な.NET Reflector、ILSpy、dotPeekのような重厚なデスクトップ向けリバースエンジニアリングツールをダウンロードする必要があった。今日では、現代の魔法のおかげで、こうした複雑なバイナリ構造のパース、検査、そして完全な逆コンパイルを、すべてブラウザ上で完結できるようになった。
裏側の仕組み
.NETアセンブリを開くのは魔法でもなんでもない。ドキュメント化され尽くしたファイルフォーマットをパースしているだけだ。DLLのバイナリの解剖図をこじ開けてみよう。
PE/COFFシェル
.NETのDLLをバイナリエディタ（Hexエディタ）で覗いてみると、標準的なWindowsのC++実行ファイルと全く同じ見た目をしていることに驚くかもしれない。ファイルはMZ（DOSヘッダー）という文字から始まり、PE（Portable Executable）ヘッダーが含まれている。
これは巧妙な変装だ。Windowsがファイルのロード方法を確実に理解できるように、.NETアセンブリは標準的なWindows実行ファイルのシェルに包まれている。しかし、PEヘッダーには特別なポインタ、CLRヘッダー（Common Language Runtime Header）が含まれている。Windowsがこのヘッダーを見つけると、ファイルを通常のプログラムとして扱うのをやめて、制御を.NETランタイムに引き渡す。このヘッダー以降のすべては、純粋な.NETアーキテクチャの世界だ。
メタデータテーブルとトークン
.NETアセンブリは、本質的にはミニチュアのリレーショナルデータベースだ。内部のすべてを記述するために、一連のメタデータテーブルに依存している。クラス用のTypeDefテーブル、関数用のMethodDefテーブル、そして他のDLLから呼び出す関数用のMemberRefテーブルが存在する。
一つ一つの要素にはメタデータトークンが割り当てられている。これは一意のIDとして機能する32ビットの整数だ。
0x02から始まるトークンはType（型）を意味する（例：0x02000004）。0x06から始まるトークンはMethod（メソッド）を意味する（例：0x0600000C）。
アセンブリをブラウズするとき、インスペクタはこれらのテーブルを読み込み、それらを結合し（メソッド0x0600000Cが型0x02000004に属していることを突き止め）、アーキテクチャのツリービューを描画しているというわけだ。
中間言語（IL）
これらのメソッドの中には、CIL（Common Intermediate Language：中間言語）で書かれた実際の実行ロジックが住んでいる。ILはスタックベースのアセンブリ言語だ。CPUのレジスタを使う代わりに、仮想的な「評価スタック」に値をプッシュしたりポップしたりして演算を行う。
2つの数値を足すシンプルなC#関数を書いたとしよう。
public int Add(int a, int b) {
return a + b;
}
コンパイラは、以下のようなILを生成する。
.method public hidebysig instance int32 Add(int32 a, int32 b) cil managed {
.maxstack 2
IL_0000: ldarg.1 // Push argument 'a' onto the stack
IL_0001: ldarg.2 // Push argument 'b' onto the stack
IL_0002: add // Pop two values, add them, push the result
IL_0003: ret // Return the value at the top of the stack
}
アセンブリインスペクタは、こうした生のバイトコード（ldarg.1なら0x03、addなら0x58といった具合に）をパースし、この読みやすいテキストへと変換してくれる。
逆コンパイルの技術
ハードコアな最適化のためならILを読むのもいいが、たいていの開発者はC#を見たいはずだ。逆コンパイルとは、コンパイルプロセスを逆回しで実行する行為である。
ツールはILのスタック命令を読み取り、それを抽象構文木（AST）にマッピングし直す。そしてパターンに気づくのだ。「あぁ、このコードはIEnumeratorを初期化して、MoveNext()がfalseになるまでループし、try/finallyブロックを使ってそれをDisposeしているな。ってことは、これはforeachループだ！」と。ツールは低レベルなILの概念を元の高レベルなC#の構造に変換し、元のソースコードのほぼ完璧なレプリカを提供してくれる。
実際のストーリー
消えたソースコード事件
ある若手開発者が5年前、社内の重要な請求処理ユーティリティを作成した。彼らは最終的に会社を去り、移行時のミスでソースコードを管理していたGitリポジトリが永久に削除されてしまった。そして現在。連携しているサードパーティAPIがURLを更新したため、このユーティリティが壊れてしまった。
ツールをゼロから書き直して3週間を無駄にする代わりに、リード開発者はBillingUtility.exeをアセンブリインスペクタにドラッグした。数秒後、コードは完全に逆コンパイルされた。ハードコードされたURLを見つけ出し、逆コンパイルされたC#コードを新しいVisual StudioプロジェクトにコピペしてURLを修正。再コンパイルし、昼休みまでに本番環境にプッシュした。.NETはメタデータを非常によく保存するため、コンパイルされたEXEが事実上ソースコードの緊急バックアップとして機能したのだ。
サードパーティのブラックボックス
あるエンタープライズチームは、高価なクローズドソースのPDF生成ライブラリにお金を払っている。本番環境で、特定の関数がArgumentOutOfRangeExceptionを吐き続けている。ベンダーのサポートチームは反応がなく、公式ドキュメントにはこの特定のメソッドについての記載が全くない。
イライラした開発者は、インスペクタでベンダーのDLLを開き、クラッシュしているメソッドに移動して、逆コンパイルされたC#を眺めてみた。そこで、ドキュメントにない隠し内部チェックを発見した。PDFのタイトル文字列が50文字を超えると、ライブラリが例外をスローするようになっていたのだ。この知識を得た開発者は、ライブラリに渡す前に文字列を切り詰めるようにし、パッチを何週間も待つことなくクラッシュを即座に回避した。
シンタックスシュガーの裏切り
パフォーマンスにとりつかれたあるバックエンド開発者が、エレガントなシーケンスジェネレータを作るため、C#の気の利いた機能であるyield returnを使うことにした。コードは美しく見えたが、アプリケーションは突然ひどいガベージコレクション（GC）のラグに悩まされるようになった。
開発者はコードをコンパイルし、出来上がったDLLを調べてみた。恐ろしいことに、4行のシンプルなメソッドは、実際には4行のILにコンパイルされていなかったのだ。水面下で、C#コンパイラはIEnumeratorを実装した巨大で隠蔽されたステートマシン（状態遷移）クラスを生成しており、メソッドが呼ばれるたびにヒープにメモリを割り当てていた。生のILを見たことでシンタックスシュガーの幻想は打ち砕かれ、その開発者はよりシンプルな、アロケーションゼロのSpanアプローチを使って関数を書き直すことになった。
よくある間違いと罠
- 難読化（Obfuscation）を忘れる: 美しいC#を読もうと期待してDLLをポップに開いたのに、メソッド名が
a、b、cだらけの読解不能なスパゲッティコードを見つけることがある。これは、知的財産を保護するためにメタデータやILをスクランブルする「難読化ツール（Obfuscator）」によって意図的に行われたものだ。インスペクタはその難読化されたカオスを正確に表示してくれるが、元に戻すことはできない。 - 逆コンパイルされたコードが一言一句元のままだと思い込む: デコンパイラは高度な推測を行う。あなたが
for (;;)ループを書いたとしても、デコンパイラはwhile (true)ループを吐き出すかもしれない。ロジックと実行内容は同一だが、テキストは元の作者がタイピングしたものとはわずかに異なる場合がある。 - 「Compiler Generated（コンパイラ生成）」の異常さにパニックになる: コードを調べていると、
<>c__DisplayClass0_0のような奇妙な名前のクラスを日常的に見かけるだろう。パニックにならないでほしい。これは、C#コンパイラがクロージャ、ラムダ式、asyncのステートマシンなどを裏で処理するための仕組みだ。これらはコンパイラが生成したアーティファクトであり、マルウェアではない。 - ReleaseビルドではなくDebugビルドを検査してしまう: 「Debug」モードでコンパイルされたDLLを逆コンパイルすると、ILの中に大量の
nop（No Operation：何もしない）命令が含まれていることに気づくはずだ。これらは純粋に、デバッガがブレークポイントをアタッチする場所を確保するために存在している。本番環境でコードが「実際に」何をしているのかを見たいなら、最適化が有効になっている「Release」ビルドを常に検査しよう。
なぜ知っておくべきなのか
真剣な.NET開発者なら誰でも、いつかは舞台裏を覗き見しなければならない壁にぶつかる。アセンブリインスペクタは、単にC#を書くだけの開発者から、C#が実際にどう実行されるかを理解するエンジニアへとあなたを押し上げてくれる。
それは「魔法のような」機能の幻想を打ち砕き、LINQや非同期プログラミング、パターンマッチングなどの実際のパフォーマンスコストを理解する助けになる。ドキュメントもなくソースコードもないレガシーバイナリの保守を任されたときには、究極のパラシュートとして機能する。最も重要なのは、依存関係を自ら検証できるようになることだ。ブラウザ上で直接、コンパイルされた生のロジックを監査するツールを持っていれば、もうサードパーティのNuGetパッケージを盲目的に信頼する必要はない。
さらに深掘りする
- Standard ECMA-335: Common Language Infrastructure (CLI) - .NETアセンブリとILの構造が正確にどうなっているかを詳細に記した、基礎となる巨大な仕様書。
- .NET のアセンブリ (Microsoft Learn) - アセンブリの仕組み、ロード方法、コードの共有方法に関する公式のハイレベルなドキュメント。
- List of CIL Instructions (Wikipedia) - 特定のILオペコード（
ldargやstlocなど）が実際に何をするのかを理解するための、非常にアクセスしやすく便利なチートシート。 - ILSpy on GitHub - 最も人気のあるオープンソース.NETデコンパイラのソースコード。逆コンパイルのASTがリアルタイムでどう構築されるかを確認できる素晴らしいリソース。