Native AOT

.NETアプリを単一のネイティブバイナリへ事前コンパイルする発行方式。非対応リストにC++/CLIが明記されている。

概念URI

https://comcomponent.com/knowledge/native-aot/

別名・表記

PublishAot

下位概念

UnmanagedCallersOnly属性 / Native AOT publish用のネイティブツールチェーン

最終確認日

2026-08-01

機械可読データ

JSON-LD

この概念が関わる関係

• C++/CLIはNative AOTと両立しません。Native AOTの非対応リストにC++/CLIが明記されており、PublishAotで単一のネイティブバイナリにする方針とは両立しない / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Native AOTはUnmanagedCallersOnly属性を利用します。Native AOTで発行するC#のクラスライブラリは、UnmanagedCallersOnlyを付けたメソッドをCのエントリポイントとして公開できる。 / 確度: 確立した関係 / 確認日: 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 出典
• Native AOTを32bit/64bitまたはプロセス境界を越える要件に用いることは推奨されません。32bit/64bitを橋渡ししたい、またはプロセス境界を越えたい場合には、in-process DLLであるNative AOTの構成は向かない。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Native AOTをプラグインを後でアンロードしたい要件に用いることは推奨されません。Native AOTで発行した共有ライブラリはアンロード前提では使わないほうがよい。 / 確度: 確立した関係 / 確認日: 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 出典
• Native AOTはJIT(Just-In-Time)コンパイルと両立しません。publish時に生成されるNative AOTのネイティブバイナリは実行時JITを使わない。ただし通常のdotnet runや開発時の実行は引き続きJITのままである / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• Native AOTはtrimming(トリミング)を前提とします。Native AOTはtrimmingとほぼ前提として結びついた発行モデルである / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Native AOTはリフレクションと両立しません。実行時に見て決める自由なリフレクションは、publish時に必要コードを確定しにくくNative AOTと相性が悪い / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• Native AOTは動的コード生成(Reflection.Emit等)と両立しません。System.Reflection.Emitのような実行時コード生成はNative AOTでは使えない / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Native AOTはbuilt-in COM interopと両立しません。WindowsのNative AOTにはbuilt-in COMが無い / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• ComWrappers / source-generated COMはNative AOTに対する本記事の推奨です。COM相互運用がどうしても必要な場合、built-in COMの代わりにComWrappers/source-generated COMを前提に設計し直すことがNative AOTでは有力な選択肢になる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• WPFをNative AOTに用いることは推奨されません。trimmingとの相性が悪いため、WPF本体を最初のNative AOT候補にするのは慎重に見るべきとされる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Windows FormsをNative AOTに用いることは推奨されません。built-in COM marshallingへの依存が重いため、WinForms本体を最初のNative AOT候補にするのは慎重に見るべきとされる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Native AOTはsource generatorを利用します。Native AOTはsource generatorと相性がよく、実行時の動的処理をビルド時へ寄せる設計と噛み合う / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Native AOTはself-contained発行を前提とします。Native AOTはself-contained系の発行モデルとして考える / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Native AOTはsingle-file発行を利用します。single-fileの本質とは別だが、Native AOTの発行結果はsingle-fileに近い1本の実行ファイルになりやすい / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• Native AOTは.NET(Core以降)を前提とします。Native AOTは.NET 8以降のSDKでサポートされる発行方式である / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 逆コンパイルをNative AOTに用いることは推奨されません。Native AOTで発行されたバイナリはILを含まずネイティブコードに変換済みのため、逆コンパイラでのC#復元は期待できない / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• ILスタブをNative AOTに用いることは推奨されません。ILスタブは実行時のコード生成に依存するため、事前コンパイルを前提とするNative AOTには向かない。DllImport自体は対応済みのシグネチャなら使えるが、コンパイル時にマーシャリングコードを生成するLibraryImportのほうが適する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• LibraryImportはNative AOTに対する本記事の推奨です。LibraryImportはコンパイル時にマーシャリングコードを生成するため、Native AOTに対応するという本記事の推奨 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• CsWin32はNative AOTに対する本記事の推奨です。NativeMethods.jsonでallowMarshalingを無効にすると、ランタイムのマーシャラーに依存しないコード生成に切り替わりNative AOTを見据えた構成にできる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• Native AOTはbuilt-in COM interopと両立しません。Native AOTでは動的読み込みやC++/CLIに加え、Windows上の組み込みCOMが使えなくなる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Native AOTは対象Windowsへの依存を前提とします。Native AOTも対象プラットフォームが決め打ちで、AnyCPUで1個という発想は成立しない。Native AOT自体はLinux・macOSも対象にできるので、対象Windowsへの依存が生じるのはWindowsをターゲットに選んだときに限られる。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典

この概念を扱う記事

• C#からネイティブDLLを呼ぶ：C++/CLIラッパー vs P/Invoke(言及)
• C# Native AOT DLLをC/C++から呼び出す方法(主要トピック)
• .NET Native AOTとは - JITやtrimmingとの違い(主要トピック)
• ソースコードも仕様書もないシステムを引き継いだら ── 止めずに運用・保守するための実務手順(言及)
• C#からWin32 APIを安全に呼ぶ ── P/Invoke実務ガイド(DllImport / LibraryImport / CsWin32)(言及)
• Windowsアプリの1ファイル配布 - シングルバイナリとOS依存の限界(言及)

一次資料

• https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/

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