知識マップ: C# Native AOT DLLをC/C++から呼び出す方法

記事「C# Native AOT DLLをC/C++から呼び出す方法」の主張を、概念と関係(エッジ)に分解した知識グラフの全体です。各関係には根拠・確認日・確度が付いています。

C#のNative AOTはUnmanagedCallersOnly属性を付けたメソッドをCのエントリポイントとして公開でき、既存のC/C++アプリからin-processでC#のロジックだけを呼び出せる構成を実現する。ただし境界に出せるのはblittableな型に限られるため、実務ではstringやList<T>を直接見せずcreate/destroy/operateのようなハンドルベースのC APIに落とし、呼び出し規約を明示し、例外の代わりにstatus codeでエラーを表現する設計が推奨される。この構成はC/C++がC#ロジックを呼ぶ向きに適する一方、C#からCを呼ぶならP/Invoke、C#からC++を自然に扱うならC++/CLI、32bit/64bitやプロセス境界を越えたい場合やアンロードしたい場合はCOM/IPCの方が向く。ハンドルの採番を32bit幅で使い回すと一周時に無関係なインスタンスを指す危険があり、世代番号の埋め込みが対策になる。

flowchart LR
    accTitle: Native AOTでC#をネイティブDLLとしてC/C++から呼ぶ知識マップ
    accDescr: Native AOTとUnmanagedCallersOnlyでC#をC/C++から呼ばれるネイティブDLLとして発行できること、境界面をC ABIに落とすための呼び出し規約・blittable型・ハンドル設計・エラー表現の要点、P/Invoke・C++/CLI・COMとの使い分けを示す図
    native_aot["Native AOT"]
    unmanagedcallersonly["UnmanagedCallersOnly属性"]
    blittable_type["blittable型"]
    calling_convention["呼び出し規約(calling convention)"]
    c_abi["C ABI(Application Binary Interface)"]
    native_aot_publish_toolchain["Native AOT publish用のネイティブツールチェーン"]
    dotnet[".NET(Core以降)"]
    native_to_managed_inprocess_call["C/C++からC#ロジックをin-processで呼ぶ要件"]
    p_invoke["P/Invoke"]
    csharp_calls_c_functions["C#からCの関数群を呼ぶ要件"]
    cpp_cli["C++/CLI"]
    csharp_calls_cpp_library["C#からC++ライブラリを自然に扱う要件"]
    com_interop["COM(Component Object Model)"]
    cross_process_or_bitness_boundary["32bit/64bitまたはプロセス境界を越える要件"]
    plugin_unload_requirement["プラグインを後でアンロードしたい要件"]
    status_code_error_convention["エラーをstatus codeで返す設計"]
    handle_based_api_design["ハンドルベースのC API設計(create/destroy/operate)"]
    handle_counter_overflow["ハンドル採番カウンターのオーバーフロー"]
    handle_wraparound_collision["ハンドル一周による衝突"]
    generation_embedded_handle["世代番号を埋め込んだハンドル設計"]
    dumpbin["dumpbin"]
    import_library["インポートライブラリ(.lib)"]
    native_aot -->|"利用する"| unmanagedcallersonly
    unmanagedcallersonly -->|"前提とする"| blittable_type
    calling_convention -->|"で構成できる"| unmanagedcallersonly
    c_abi -->|"利用する"| calling_convention
    unmanagedcallersonly -->|"前提とする"| c_abi
    native_aot -->|"前提とする"| native_aot_publish_toolchain
    native_aot -->|"前提とする"| dotnet
    native_aot -->|"推奨される対応"| native_to_managed_inprocess_call
    p_invoke -->|"推奨される対応"| csharp_calls_c_functions
    cpp_cli -->|"推奨される対応"| csharp_calls_cpp_library
    com_interop -->|"推奨される対応"| cross_process_or_bitness_boundary
    native_aot -->|"用いるのは非推奨"| cross_process_or_bitness_boundary
    native_aot -->|"用いるのは非推奨"| plugin_unload_requirement
    status_code_error_convention -->|"推奨される対応"| unmanagedcallersonly
    handle_based_api_design -->|"推奨される対応"| unmanagedcallersonly
    handle_counter_overflow -.->|"原因になり得る"| handle_wraparound_collision
    generation_embedded_handle -->|"防止する"| handle_wraparound_collision
    native_aot -->|"で確認できる"| dumpbin
    import_library -.->|"前提とする"| native_aot
    native_aot -->|"用いるのは非推奨"| csharp_calls_c_functions
    native_aot -->|"用いるのは非推奨"| csharp_calls_cpp_library
    handle_based_api_design -.->|"原因になり得る"| handle_wraparound_collision

概念間の関係(全22件)

図と同じ関係を文章でも列挙します。表示している文と機械可読な意味データ(RDFa)は同じ要素に載っています。確度が「確立した関係」のものは直接の関係として、「条件付きの関係」のものは成立条件つきの言明(rdf:Statement)として表現しています。

Native AOTはUnmanagedCallersOnly属性を利用します。Native AOTで発行するC#のクラスライブラリは、UnmanagedCallersOnlyを付けたメソッドをCのエントリポイントとして公開できる。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
UnmanagedCallersOnly属性はblittable型を前提とします。UnmanagedCallersOnlyを付けたメソッドのシグネチャには、blittableな型しか使えない。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
呼び出し規約(calling convention)はUnmanagedCallersOnly属性で構成できます。呼び出し規約はUnmanagedCallersOnlyのCallConvsパラメーターで、cdeclなどを明示的に固定できる。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
C ABI(Application Binary Interface)は呼び出し規約(calling convention)を利用します。C ABIは呼び出し規約・型のレイアウト・名前とリンクという3つの約束から成り、呼び出し規約はその構成要素の1つ。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
UnmanagedCallersOnly属性はC ABI(Application Binary Interface)を前提とします。exportされるのはあくまでCの関数入口であり、境界面は.NETではなくC ABIとして設計する必要がある。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
Native AOTはNative AOT publish用のネイティブツールチェーンを前提とします。Native AOTのpublishには、ネイティブのツールチェーンが別途必要で、無いとC#のコンパイルではなく最後のネイティブリンクの段階で失敗する。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
Native AOTは.NET(Core以降)を前提とします。Native AOTは.NET SDKのpublish機能であり、.NET(Core以降)であることを前提とする。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
Native AOTはC/C++からC#ロジックをin-processで呼ぶ要件に対する本記事の推奨です。C/C++からC#の処理をin-processで呼びたいという要件では、Native AOT + UnmanagedCallersOnlyが有力な選択肢になる。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
P/InvokeはC#からCの関数群を呼ぶ要件に対する本記事の推奨です。C#からCの関数群を呼ぶ場合は、向きが素直なP/Invokeが自然な選択肢になる。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
C++/CLIはC#からC++ライブラリを自然に扱う要件に対する本記事の推奨です。C#からC++ライブラリを自然に扱いたい場合は、C++の型や所有権、例外を吸収しやすいC++/CLIが向く。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
COM(Component Object Model)は32bit/64bitまたはプロセス境界を越える要件に対する本記事の推奨です。32bit/64bitやプロセス境界を越えたい場合は、in-process DLLでは越えられないためCOM/IPCの方が筋がよい。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
Native AOTを32bit/64bitまたはプロセス境界を越える要件に用いることは推奨されません。32bit/64bitを橋渡ししたい、またはプロセス境界を越えたい場合には、in-process DLLであるNative AOTの構成は向かない。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
Native AOTをプラグインを後でアンロードしたい要件に用いることは推奨されません。Native AOTで発行した共有ライブラリはアンロード前提では使わないほうがよい。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
エラーをstatus codeで返す設計はUnmanagedCallersOnly属性に対する本記事の推奨です。managed例外をそのまま呼び出し元へ漏らさず、戻り値をstatus code、実データをoutポインタ引数で返す設計が、UnmanagedCallersOnlyの境界では実務上推奨される。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
ハンドルベースのC API設計(create/destroy/operate)はUnmanagedCallersOnly属性に対する本記事の推奨です。create/destroy/operateのようなフラットなC APIに落として寿命管理とエラーコードを明示する設計が、UnmanagedCallersOnlyの境界では実務上安定する。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
ハンドル採番カウンターのオーバーフローはハンドル一周による衝突の原因になることがあります。32bitビルドで採番カウンターが2^32を超えて一周すると、破棄済みの辞書キーに同じハンドル値が戻ってきて再利用され、無関係な新しいインスタンスを指すようになり得る。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
世代番号を埋め込んだハンドル設計はハンドル一周による衝突を防ぎます。下位を連番、上位を世代番号とし destroy のたびに世代を進めることで、同じ連番が巡ってきても値が一致しなくなり衝突を防げる。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
Native AOTはdumpbinで確認できます。Native AOTで発行したDLLに目的の関数が実際にexportされているかは、dumpbin /exportsで確認できる。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
インポートライブラリ(.lib)はNative AOTを前提とします。呼び出し側を静的リンクにしたい場合のインポートライブラリは、Native AOTがpublishしたDLL(またはそのexport名一覧)を前提に作成する。ただしインポートライブラリ一般がNative AOTを前提とするわけではなく、この対応関係はNative AOTが発行したDLLに対して作成する場合に限られる。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
Native AOTをC#からCの関数群を呼ぶ要件に用いることは推奨されません。「C#からCの関数群を呼ぶ」場面ではP/Invokeが有力候補として挙げられており、Native AOT + UnmanagedCallersOnlyはこれとは逆向き(C/C++からC#)の場面のための構成である。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
Native AOTをC#からC++ライブラリを自然に扱う要件に用いることは推奨されません。C++のクラスやstd::vectorや例外をそのまま扱いたい場合は、C++/CLIかネイティブ側ラッパーのほうが自然で、Native AOTのC ABI越しの構成には向かない。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
ハンドルベースのC API設計(create/destroy/operate)はハンドル一周による衝突の原因になることがあります。ハンドルベースのAPI設計で採番カウンターを32bit幅のnintへキャストすると、32bitビルドでは採番が一周し得る。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典

主要概念の定義

Native AOT: .NETアプリを単一のネイティブバイナリへ事前コンパイルする発行方式。非対応リストにC++/CLIが明記されている。
UnmanagedCallersOnly属性: static メソッドに付与すると、そのメソッドをネイティブコードから直接呼び出せるCのエントリポイントとして公開できる.NETの属性。
呼び出し規約(calling convention): 関数呼び出しで引数をレジスタとスタックのどちらでどう渡すか、戻り値をどこに置くか、呼び出し後にスタックを戻すのが呼ぶ側か呼ばれる側かを定める約束。
C ABI(Application Binary Interface): コンパイル済みのバイナリ同士が実行時にどう噛み合うかを、呼び出し規約・型のレイアウト・名前とリンクという3つの約束で定める、機械語レベルの取り決め。
P/Invoke: C#などの.NETコードからアンマネージドなC関数群を呼び出すための、.NETの標準的な相互運用機構。
C++/CLI: ネイティブC++とマネージド.NETの両方を1つのプロジェクトで扱えるMicrosoftの言語拡張。ネイティブDLLとC#の間に薄いラッパー層を作るのに使われる。
COM(Component Object Model): プロセス内外・言語をまたいでオブジェクトを利用可能にするMicrosoftのバイナリ相互運用規格で、32bit/64bitやプロセス境界を越える橋渡しにも使われる。
エラーをstatus codeで返す設計: ネイティブ境界を越える関数の戻り値をエラーコードとし、実データはoutバッファやポインタ引数で返す、managed例外を境界に漏らさないための設計方針。
ハンドルベースのC API設計(create/destroy/operate): ネイティブ側にはintptr_t相当のハンドルだけを見せ、状態本体は.NET側で保持しながらcreate/add/get/destroyのようなフラットな関数に分解するAPI設計パターン。
ハンドル採番カウンターのオーバーフロー: long型の採番カウンターをnint(32bitビルドでは32bit幅)へキャストする際に上位ビットが黙って捨てられ、採番が2^32を超えると値が一周する現象。
世代番号を埋め込んだハンドル設計: ハンドルの下位ビットを連番、上位ビットを世代番号とし、destroyのたびに世代を進めることで、同じ連番が巡ってきても値が一致しないようにするハンドル設計。
インポートライブラリ(.lib): DLLの関数を実行時のLoadLibrary/GetProcAddressを介さず、リンク時に静的に解決できるようにするための.libファイル。

機械可読データ

JSON-LD / Turtle ── この記事の知識グラフ全体
概念一覧 / 語彙(述語)の定義

このページはサイトの知識グラフ(_data/knowledge/)から自動生成されています。誤りの指摘はお問い合わせからお願いします。