次の方法で共有


ネイティブ AOT デプロイ

ネイティブ AOTとしてアプリを発行すると、ネイティブ コードに事前 (AOT) コンパイルされた自己完結型のアプリが生成されます。 ネイティブ AOT アプリの起動時間が短縮され、メモリ占有領域が小さくなります。 これらのアプリは、.NET ランタイムがインストールされていないマシンで実行できます。

Native AOT の利点は、クラウド インフラストラクチャやハイパースケール サービスなど、デプロイされたインスタンスの数が多いワークロードにとって最も重要です。 .NET 8 では、 ネイティブ AOT ASP.NET Core サポートが追加されました。

ネイティブ AOT デプロイ モデルでは、発行時に事前コンパイラを使用して IL をネイティブ コードにコンパイルします。 ネイティブ AOT アプリでは、アプリケーションの実行時に Just-In-Time (JIT) コンパイラは使用されません。 ネイティブ AOT アプリは、JIT が許可されていない制限された環境で実行できます。 ネイティブ AOT アプリケーションは、 自己完結型アプリの発行と同様に、Linux x64 や Windows x64 などの特定のランタイム環境を対象としています。

[前提条件]

Visual Studio 2022。すべての既定のコンポーネントを含む C++ によるデスクトップ開発 ワークロードが含まれます。

CLI を使用してネイティブ AOT を発行する

  1. プロジェクト ファイルに <PublishAot>true</PublishAot> を追加します。

    このプロパティは、発行時にネイティブ AOT コンパイルを有効にします。 また、ビルドと編集中の動的なコード使用状況分析も可能になります。 この設定は、発行の外部の動作を制御するため、コマンド ラインで渡すのではなく、プロジェクト ファイルに配置することをお勧めします。

    <PropertyGroup>
        <PublishAot>true</PublishAot>
    </PropertyGroup>
    
  2. dotnet publish -r <RID>を使用して、特定のランタイム識別子のアプリを発行します。

    次の例では、必要な前提条件がインストールされているコンピューターに、Windows 用アプリをネイティブ AOT アプリケーションとして発行します。

    dotnet publish -r win-x64 -c Release

    次の例では、Linux 用アプリをネイティブ AOT アプリケーションとして発行します。 Linux マシンで生成されたネイティブ AOT バイナリは、同じまたは新しい Linux バージョンでのみ動作します。 たとえば、Ubuntu 20.04 で生成されたネイティブ AOT バイナリは Ubuntu 20.04 以降で実行されますが、Ubuntu 18.04 では実行されません。

    dotnet publish -r linux-arm64 -c Release

アプリは発行ディレクトリで使用でき、coreclr ランタイムの削除されたバージョンを含め、その中で実行するために必要なすべてのコードが含まれています。

GitHub の dotnet/samples リポジトリで入手できる ネイティブ AOT サンプルを確認してください。 サンプルには 、前提条件 のインストールを自動化し、コンテナーを使用してネイティブ AOT を使用して .NET プロジェクトを発行する方法を示す Linux および Windows Dockerfile が含まれています。

AOT互換性解析ツール

IsAotCompatible プロパティは、ライブラリがネイティブ AOT と互換性があるかどうかを示すために使用されます。 ライブラリで IsAotCompatible プロパティを true に設定する場合を考えてみましょう。次に例を示します。

<PropertyGroup>
    <IsAotCompatible>true</IsAotCompatible>
</PropertyGroup>

上記の構成では、既定の true が次のプロパティに割り当てられます。

  • IsTrimmable
  • EnableTrimAnalyzer
  • EnableSingleFileAnalyzer
  • EnableAotAnalyzer

これらのアナライザーは、ライブラリがネイティブ AOT と互換性があることを確認するのに役立ちます。

ネイティブ デバッグ情報

既定では、ネイティブ AOT 発行では、デバッグ情報が別のファイルに生成されます。

  • Linux: .dbg
  • Windows: .pdb
  • macOS: .dSYM フォルダー

デバッグ ファイルは、デバッガーでアプリを実行したり、 クラッシュ ダンプを検査したりするために必要です。 Unix に似たプラットフォームでは、 StripSymbols プロパティを false に設定して、ネイティブ バイナリにデバッグ情報を含めます。 デバッグ情報を含めると、ネイティブ バイナリが大きくなります。

<PropertyGroup>
    <StripSymbols>false</StripSymbols>
</PropertyGroup>

ネイティブ AOT デプロイの制限事項

ネイティブ AOT アプリには、次の制限があります。

  • Assembly.LoadFileなど、動的な読み込みはありません。
  • System.Reflection.Emitなど、実行時コードの生成はありません。
  • C++/CLI はありません。
  • Windows: 組み込みの COM はありません。
  • トリミングが必要です。 これには制限があります
  • 既知の互換性の問題がある単一ファイルへのコンパイルを指 します
  • アプリには、必要なランタイム ライブラリが含まれています ( 自己完結型アプリと同様に、フレームワークに依存するアプリと比較してサイズを大きくします)。
  • System.Linq.Expressions は常に解釈された形式を使用します。これは、実行時に生成されたコンパイル済みコードよりも遅くなります。
  • 構造体型引数で置き換えたジェネリック パラメーターには、インスタンス化ごとに特殊なコードが生成されます。 動的ランタイムでは、多くのインスタンス化がオンデマンドで生成されます。 ネイティブ AOT では、すべてのインスタンス化が事前に生成されます。 これは、アプリケーションのディスク サイズに大きな影響を与える可能性があります。 ジェネリック仮想メソッドとジェネリック インスタンス メソッドには、実装またはオーバーライドするすべての型に対するインスタンス化も含まれます。
  • すべてのランタイム ライブラリにネイティブ AOT 互換の注釈が付いているわけではありません。 つまり、ランタイム ライブラリ内の一部の警告は、エンド 開発者が操作できません。
  • デバッグとプロファイリングのための診断サポートには いくつかの制限があります。
  • 一部の ASP.NET コア機能のサポート。 詳細については、ASP.NET Core のネイティブ AOT サポートを参照してください。

発行プロセスでは、プロジェクト全体とその依存関係を分析して、考えられる制限事項を確認します。 発行されたアプリが実行時に発生する可能性がある制限ごとに警告が発行されます。

プラットフォーム/アーキテクチャの制限

次の表は、サポートされているコンパイル ターゲットを示しています。

プラットホーム サポートされているアーキテクチャ 注記
ウィンドウズ x64、Arm64
Linux x64、Arm64
macOS x64、Arm64
iOS Arm64 試験的なサポート
iOSSimulator x64、Arm64 試験的なサポート
tvOS Arm64 試験的なサポート
tvOSSimulator x64、Arm64 試験的なサポート
MacCatalyst x64、Arm64 試験的なサポート
アンドロイド x64、Arm64 試験段階、組み込みの Java 相互運用なし

Native AOT で特定のプラットフォームがどのようにサポートされているかの詳細については、表のリンクを参照してください。