MS_ComponentTechnology

コンポーネント技術

• 戻る（Windows OSの基礎的トピック）

内部リンク

• DLL
• COM
• アセンブリ
• DLL/COMユーザ

補足（本ページの位置付け）: 本ページは**リンク集（ハブ）**であり、
内容は各リンク先にある。全体像を掴むための地図として、
4 者の関係を整理しておく。

【Windows のコンポーネント技術の系譜】★

   1990年代前半  【DLL】
     → 関数を外部ファイルに切り出して共有する
     → C の関数呼び出しがそのまま見えている
     → 【型情報がない】。呼ぶ側が正しい宣言を書く責任を負う
             │
             ▼
   1993年〜     【COM】（Component Object Model）
     → 【インターフェース】で契約を定義する
     → 言語非依存（C++ / VB / VBScript / Delphi …）
     → 参照カウントによる寿命管理（AddRef / Release）
     → レジストリに CLSID を登録して探す
             │
             ▼
   2002年〜     【.NET アセンブリ】
     → 【メタデータを自分の中に持つ】★
     → 型情報・バージョン・依存関係が自己記述的
     → レジストリ登録が不要（XCOPY 配置）
     → GC による寿命管理

【何が改善されてきたのか】★
   ① 【型情報をどこに置くか】
        DLL     … どこにもない（ヘッダは別管理）
        COM     … タイプ ライブラリ（.tlb）に置く
        アセンブリ … 【自分の中に持つ】★
   ② 【どうやって見つけるか】
        DLL     … ファイル パス / PATH
        COM     … 【レジストリ】（CLSID / ProgID）
                  → 「DLL 地獄」の主因 ★
        アセンブリ … アプリ フォルダ / GAC / NuGet
   ③ 【誰が寿命を管理するか】
        DLL     … 呼び出し側
        COM     … 参照カウント（解放漏れが起きる）
        アセンブリ … 【GC】★

【今も COM / DLL が必要になる場面】★
   ・【Office 自動化】（Excel / Word の COM）
   ・【Windows の OS 機能】（Shell / WMI / DirectX）
   ・【既存資産】（VB6 / C++ の業務ライブラリ）
   ・【デバイス SDK】（メーカー提供の C 製 DLL）

   → .NET から使う方法は
     [マネージドコードとアンマネージドコードのブリッジ](MS_ManagedUnmanagedBridge)
     および [マーシャリング](MS_Marshaling) を参照。

【現代的な「コンポーネント」の代替】
   ・【NuGet パッケージ】… .NET 世界の標準
   ・【Web API / gRPC】 … プロセス・言語を越える境界を
                          【ネットワーク越し】に置く ★
   ・【コンテナ】       … 実行環境ごと分離する
   → 「同一プロセス内で言語を越える」という
     COM の野心は、
     【プロセスを分けてしまう】方向に置き換わった

---

Tags: 移行, Windows, .NET開発