.NET 8 の SDK とツールの新機能

この記事では、.NET SDK と .NET 8 用ツールの新機能について説明します。

SDK

このセクションでは、次のサブトピックについて説明します。

• CLI ベースのプロジェクト評価
• ターミナル ビルドの出力
• 簡略化された出力パス
• 'dotnet workload clean' コマンド
• 資産の 'dotnet publish' および 'dotnet pack'
• テンプレート エンジン
• ソース リンク
• ソース ビルド SDK

CLI ベースのプロジェクト評価

MSBuild には、MSBuild のデータをスクリプトまたはツールに簡単に組み込むことができる新機能が含まれています。 次の新しいフラグは、dotnet publish などの CLI コマンドで使用して、CI パイプラインやその他の場所で使用するデータを取得するために使用できます。

値は標準出力に書き込まれます。 次の例に示すように、複数または複雑な値が JSON として出力されます。

>dotnet publish --getProperty:OutputPath
bin\Release\net8.0\

>dotnet publish -p PublishProfile=DefaultContainer --getProperty:GeneratedContainerDigest --getProperty:GeneratedContainerConfiguration
{
  "Properties": {
    "GeneratedContainerDigest": "sha256:ef880a503bbabcb84bbb6a1aa9b41b36dc1ba08352e7cd91c0993646675174c4",
    "GeneratedContainerConfiguration": "{\u0022config\u0022:{\u0022ExposedPorts\u0022:{\u00228080/tcp\u0022:{}},\u0022Labels\u0022...}}"
  }
}

>dotnet publish -p PublishProfile=DefaultContainer --getItem:ContainerImageTags
{
  "Items": {
    "ContainerImageTags": [
      {
        "Identity": "latest",
        ...
    ]
  }
}

ターミナル ビルドの出力

dotnet build には、より最新化されたビルド出力を生成するための新しいオプションがあります。 この "ターミナル ロガー" 出力は、発生したプロジェクトに関するエラーをグループ化し、ターゲットが複数あるプロジェクトのさまざまなターゲット フレームワークをより適切に区別し、ビルドの実行内容に関するリアルタイムの情報を提供します。 新しい出力をオプト インするには、--tl オプションを使用します。 このオプションの詳細については、dotnet build のオプションに関する記事を参照してください。

簡略化された出力パス

.NET 8 では、ビルド出力の出力パスとフォルダー構造を簡略化するオプションが導入されています。 以前の .NET アプリでは、さまざまなビルド成果物に対して深くて複雑な出力パスのセットが生成されていました。 新しい簡略された出力パス構造では、すべてのビルド出力が共通の場所に収集されるため、ツールでの予測が容易になります。

詳細については、「成果物の出力レイアウト」を参照してください。

dotnet workload clean コマンド

.NET 8 では、いくつかの .NET SDK または Visual Studio の更新で残された可能性のあるワークロード パックをクリーンアップする新しいコマンドが導入されています。 ワークロードを管理する際に問題が発生した場合、再試行する前に、workload clean を使用して既知の状態に安全に復元することを検討してください。 このコマンドには、2 つのモードがあります。

• dotnet workload clean

  ファイルベースまたは MSI ベースのワークロードに対してワークロード ガベージ コレクションを実行し、孤立したパックをクリーンアップします。 孤立したパックとは、アンインストールされたバージョンの .NET SDK からのもの、またはパックのインストール レコードが存在しないパックです。

  Visual Studio がインストールされている場合、このコマンドは、Visual Studio を使用して手動でクリーンアップする必要があるワークロードの一覧も表示します。

• dotnet workload clean --all

  このモードの方がアグレッシブであり、マシン上にある現在の SDK ワークロード インストールの種類である (および Visual Studio からのものではない) すべてのパックがクリーンアップされます。 また、実行中の .NET SDK 機能バンド以下のすべてのワークロード インストール レコードも削除されます。

dotnet publish および dotnet pack アセット

dotnet publish と dotnet pack のコマンドは実稼働アセットの生成を目的としているため、既定で Release アセットが生成されるようになりました。

次の出力は、dotnet build と dotnet publish の動作の違いと、PublishRelease プロパティを false に設定して Debug アセットの発行に戻す方法を示しています。

/app# dotnet new console
/app# dotnet build
  app -> /app/bin/Debug/net8.0/app.dll
/app# dotnet publish
  app -> /app/bin/Release/net8.0/app.dll
  app -> /app/bin/Release/net8.0/publish/
/app# dotnet publish -p:PublishRelease=false
  app -> /app/bin/Debug/net8.0/app.dll
  app -> /app/bin/Debug/net8.0/publish/

詳細については、「'dotnet pack' では Release 構成が使用される」と「'dotnet publish' では Release 構成が使用される」を参照してください。

dotnet restore セキュリティ監査

.NET 8 以降では、依存関係パッケージが復元されるときに、既知の脆弱性のセキュリティ チェックをオプト インできます。 この監査では、影響を受けるパッケージ名、脆弱性の重大度、詳細に関するアドバイザリへのリンクを含むセキュリティ脆弱性のレポートが生成されます。 dotnet add または dotnet restore を実行すると、検出された脆弱性に関する警告 NU1901-NU1904 が表示されます。 詳細については、「セキュリティの脆弱性の監査」を参照してください。

テンプレート エンジン

テンプレート エンジンは、NuGet のセキュリティ関連機能の一部を統合することで、.NET 8 でより安全なエクスペリエンスを提供します。 WebJobs からの改善点は、以下のとおりです。

• 既定で、http:// フィードからのパッケージのダウンロードが回避されます。 たとえば、次のコマンドでは、ソース URL が HTTPS を使用しないため、テンプレート パッケージのインストールに失敗します。

  dotnet new install console --add-source "http://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-public/nuget/v3/index.json"

  この制限は、--force フラグを使用してオーバーライドできます。

• dotnet new、dotnet new install、dotnet new update では、テンプレート パッケージの既知の脆弱性のチェックがあります。 脆弱性が見つかっても続行する場合は、--force フラグを使用する必要があります。

• dotnet new では、テンプレート パッケージの所有者に関する情報を指定してください。 所有権は NuGet ポータルによって検証され、信頼できる特性と見なすことができます。

• dotnet search と dotnet uninstall では、"信頼済み" のパッケージからテンプレートがインストールされているかどうかを示します。つまり、予約済みのプレフィックスが使用されます。

ソース リンク

Source Link が .NET SDK に含まれるようになりました。 目的は、Source Link を SDK にバンドルすることで、パッケージ用に別の <PackageReference> を必要とする代わりに、既定でこの情報を含めるパッケージが増えるようにすることです。 この情報により、開発者向けの IDE のエクスペリエンスが向上します。

ソース ビルド SDK

Linux ディストリビューション ビルド済み (ソース ビルド) SDK に、ソース ビルド ランタイム パッケージを使用して自己完結型アプリケーションをビルドする機能が追加されました。 ディストリビューション固有のランタイム パッケージが、ソース ビルド SDK にバンドルされています。 自己完結型のデプロイの間に、このバンドルされたランタイム パッケージが参照され、ユーザーに対してこの機能が有効になります。

ネイティブ AOT のサポート

ネイティブ AOT として発行するオプションは、.NET 7 で最初に導入されました。 ネイティブ AOT を使用してアプリを発行すると、ランタイムを必要とせず、すべてが 1 つのファイルに含まれている完全に自己完結型のバージョンのアプリが作成されます。 .NET 8 では、ネイティブ AOT 発行に次の機能強化が加えられます。

• macOS の x64 および Arm64 のアーキテクチャのサポートが追加されています。

• Linux のネイティブ AOT アプリのサイズが最大で 50% 小さくなりました。 次の表は、.NET 7 と .NET 8 の .NET ランタイム全体を含むネイティブ AOT で公開された "Hello World" アプリのサイズを示しています。

  オペレーティング システム	.NET 7	.NET 8
  Linux x64 (-p:StripSymbols=true を含む)	3.76 MB	1.84 MB
  Windows x64	2.85 MB	1.77 MB

• 最適化の設定 (サイズまたは速度) を指定できます。 既定では、コンパイラはアプリケーションのサイズに注意を払いながら、高速なコードを生成します。 ただし、<OptimizationPreference> MSBuild プロパティを使用して、どちらか一方に特化して最適化することができます。 詳細については、「AOT デプロイを最適化する」を参照してください。

コンソール アプリ テンプレート

既定のコンソール アプリ テンプレートに、すぐに使用できる AOT のサポートが含まれるようになりました。 AOT コンパイル用に構成されたプロジェクトを作成するには、単に dotnet new console --aot を実行します。 --aot によって追加されるプロジェクト構成には、次の 3 つの効果があります。

• プロジェクトを (dotnet publish や Visual Studio などで) 発行するときに、ネイティブ AOT を使用してネイティブの自己完結型実行可能ファイルが生成されます。
• トリミング、AOT、および単一ファイルの互換性アナライザーが有効になります。 これらのアナライザーは、プロジェクトの問題が発生する可能性がある部分 (存在する場合) を警告します。
• AOT のデバッグ時エミュレーションが有効になるため、AOT コンパイルなしでプロジェクトをデバッグしても、AOT と同様のエクスペリエンスが得られます。 たとえば、AOT の注釈が付いていない (したがって、互換性アナライザーで見逃される) NuGet パッケージで System.Reflection.Emit を使用する場合、このエミュレーションを行うことで、AOT を使用してプロジェクトを発行しようとしても驚くことがありません。

ネイティブ AOT を備えた iOS 類似プラットフォームをターゲットとする

.NET 8 では、iOS 類似プラットフォームに対するネイティブ AOT サポートを有効にする作業を開始します。 次のプラットフォームで、ネイティブ AOT を使用して .NET iOS および .NET MAUI アプリケーションをビルドして実行できるようになりました。

• ios
• iossimulator
• maccatalyst
• tvos
• tvossimulator

予備テストでは、Mono の代わりにネイティブ AOT を使用する .NET iOS アプリで、ディスク上のアプリ サイズが約 35% 縮小することが示されています。 .NET MAUI iOS アプリのディスク上のアプリ サイズは、最大 50% 縮小します。 さらに、起動速度も速くなります。 Mono と比べて、.NET iOS アプリの起動速度は約 28% 早く、.NET MAUI iOS アプリでは起動パフォーマンスは 約 50% 向上しています。 この .NET 8 のサポートは試験的なものであり、機能全体としての最初のステップにすぎません。 詳細については、「.NET 8 の .NET MAUI 関連のパフォーマンスの向上」のブログ記事を参照してください。

ネイティブ AOT サポートは、アプリのデプロイを目的としたオプトイン機能として利用できます。Mono は依然として、アプリの開発とデプロイの既定のランタイムです。 iOS デバイスでネイティブ AOT を使用して .NET MAUI アプリケーションをビルドして実行するため、.NET MAUI ワークロードのインストールには dotnet workload install maui を、アプリの作成には dotnet new maui -n HelloMaui を使用します。 次に、プロジェクト ファイルで MSBuild プロパティ PublishAot を true に設定します。

<PropertyGroup>
  <PublishAot>true</PublishAot>
</PropertyGroup>

必要なプロパティを設定し、次の例に示すように dotnet publish を実行すると、ネイティブ AOT を使用してアプリがデプロイされます。

dotnet publish -f net8.0-ios -c Release -r ios-arm64  /t:Run

制限事項

すべての iOS 機能がネイティブ AOT と互換性を持つわけではありません。 同様に、iOS で一般的に使用されるすべてのライブラリが NativeAOT と互換性があるわけではありません。 また、既存のネイティブ AOT デプロイの制限事項に加えて、次の一覧に、iOS 類似プラットフォームをターゲットとする場合のその他の制限事項をいくつか示します。

• ネイティブ AOT の使用は、アプリのデプロイ (dotnet publish) 中にのみ有効になります。
• マネージド コードのデバッグは Mono でのみサポートされています。
• .NET MAUI フレームワークとの互換性には制限があります。

Android アプリの AOT コンパイル

アプリのサイズを小さくするために、Android を対象とする .NET アプリと .NET MAUI アプリは、リリース モードでビルドされるときに、"プロファイリングされた" 事前 (AOT) コンパイル モードを使用します。 プロファイリングされた AOT コンパイルは、通常の AOT コンパイルよりも少ないメソッドに影響します。 .NET 8 では、Android アプリのサイズをさらに小さくするためにさらに AOT コンパイルを選択できる <AndroidStripILAfterAOT> プロパティが導入されました。

<PropertyGroup>
  <AndroidStripILAfterAOT>true</AndroidStripILAfterAOT>
</PropertyGroup>

既定では、AndroidStripILAfterAOT を true に設定すると、既定の AndroidEnableProfiledAot 設定がオーバーライドされ、AOT コンパイルされた (ほぼ) すべてのメソッドをトリミングできます。 また、両方のプロパティを true に明示的に設定することで、プロファイリングされた AOT と IL のストリッピングをまとめて使用することもできます。

<PropertyGroup>
  <AndroidStripILAfterAOT>true</AndroidStripILAfterAOT>
  <AndroidEnableProfiledAot>true</AndroidEnableProfiledAot>
</PropertyGroup>

クロスビルド Windows アプリ

Windows 以外のプラットフォームで Windows をターゲットとするアプリをビルドすると、結果の実行可能ファイルは、指定した Win32 リソース (アプリケーションのアイコン、マニフェスト、バージョン情報など) で更新されるようになりました。

以前は、このようなリソースを使用するには、Windows 上にアプリケーションを構築する必要がありました。 このクロスビルディング サポートのギャップを解決することは、インフラストラクチャの複雑さとリソースの使用の両方に影響を与える重大な問題であったため、よく聞かれる要望でした。

Linux 上の .NET

Linux の最小サポート ベースライン

.NET 8 では Linux の最小サポート ベースラインが更新されました。 .NET は、すべてのアーキテクチャで Ubuntu 16.04 を対象に構築されます。 これは主に、.NET 8 で最小の glibc バージョンを定義する場合に重要です。 .NET 8 は、Ubuntu 14.04 や Red Hat Enterprise Linux 7 などの古い glibc を含むディストリビューション バージョンでは起動できません。

詳細については、「Red Hat Enterprise Linux ファミリのサポート」を参照してください。

Linux で独自の .NET をビルドする

以前の .NET バージョンでは、ソースから .NET をビルドできましたが、リリースに対応する dotnet/installer リポジトリ コミットから "source tarball" を作成する必要がありました。 .NET 8 では、これが不要になり、Linux 上の .NET を dotnet/dotnet リポジトリから直接ビルドできます。 このリポジトリでは dotnet/source-build を使用して .NET ランタイム、ツール、SDK をビルドします。 これは、Red Hat と Canonical が .NET のビルドに使用するビルドと同じです。

dotnet-buildtools/prereqs コンテナー イメージには必要なすべての依存関係が含まれるため、コンテナーでビルドする方法がほとんどのユーザーにとって最も簡単です。 詳細については、ビルド手順に関する記事を参照してください。

NuGet の署名検証

.NET 8 以降、NuGet は Linux 上の署名付きパッケージを既定で検証します。 NuGet は引き続き Windows でも署名済みパッケージを検証します。

ほとんどのユーザーは、この検証に気付くことはありません。 ただし、既存のルート証明書バンドルが /etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem にある場合は、警告 NU3042 と共に信頼エラーが発生する可能性があります。

環境変数 DOTNET_NUGET_SIGNATURE_VERIFICATION を false に設定することで、検証をオプトアウトできます。

コード分析

.NET 8 には、.NET ライブラリ API の使い方が正しく効率的であることを検証するのに役立つ、いくつかの新しいコード アナライザーと修正ツールが含まれています。 次の表は新しいアナライザーをまとめたものです。

診断

C# ホット リロード ではジェネリックの変更がサポートされます

.NET 8 以降、C# ホット リロード ではジェネリック型とジェネリック メソッドの変更がサポートされています。 Visual Studio を使用してコンソール、デスクトップ、モバイル、または WebAssembly アプリケーションをデバッグするときに、C# コードまたは Razor ページのジェネリック クラスとジェネリック メソッドに変更を適用できます。 詳しくは、Roslyn でサポートされているエディットの全一覧をご参照ください。

関連項目

• .NET 8 の新機能