ASP.NET Core 5.0 から 6.0 への移行

[アーティクル]
11/30/2023

この記事では、既存の ASP.NET Core 5.0 プロジェクトを ASP.NET Core 6.0 に更新する方法について説明します。 ASP.NET Core 3.1 から ASP.NET Core 6.0 に移行する手順については、「ASP.NET Core 3.1 から 6.0 への移行」を参照してください。

必須コンポーネント

Visual Studio 2022 と ASP.NET と Web 開発ワークロード。
.NET 6.0 SDK

global.json で .NET Core SDK バージョンを更新する

特定の .NET SDK バージョンを対象とする global.json ファイルを使用する場合は、version プロパティを、インストールされる .NET 6.0 SDK バージョンに更新します。次に例を示します。

{
  "sdk": {
-    "version": "5.0.100"
+    "version": "6.0.100"
  }
}

ターゲットフレームワークを更新する

プロジェクトファイルのターゲットフレームワークモニカー (TFM) を net6.0 に更新します。

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
-    <TargetFramework>net5.0</TargetFramework>
+    <TargetFramework>net6.0</TargetFramework>
  </PropertyGroup>

</Project>

パッケージ参照の更新

プロジェクトファイルで、各 Microsoft.AspNetCore.* および Microsoft.Extensions.* パッケージ参照の Version 属性を 6.0.0 以降に更新します。次に例を示します。

<ItemGroup>
-    <PackageReference Include="Microsoft.AspNetCore.JsonPatch" Version="5.0.3" />
-    <PackageReference Include="Microsoft.Extensions.Caching.Abstractions" Version="5.0.0" />
+    <PackageReference Include="Microsoft.AspNetCore.JsonPatch" Version="6.0.0" />
+    <PackageReference Include="Microsoft.Extensions.Caching.Abstractions" Version="6.0.0" />
</ItemGroup>

新しいホスティングモデル

ASP.NET Core アプリの新しい .NET 6 最小ホスティングモデルで必要となるのは、1 つのファイルと数行のコードのみです。 6.0 に移行するアプリでは、新しい最小ホスティングモデルを使用する必要はありません。 詳細については、次のセクションの「6.0 に移行するアプリでは、新しい最小ホスティングモデルを使用する必要はありません」を参照してください。

次のコードは ASP.NET Core の空のテンプレートからのもので、新しい最小ホスティングモデルを使用してアプリを作成します。

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/", () => "Hello World!");

app.Run();

最小ホスティングモデルには、次の特長があります。

アプリの作成に必要なファイルの数とコードの行数を大幅に削減します。必要なのは、1 つのファイルと 4 行のコードのみです。
Startup.cs と Program.cs を 1 つの Program.cs ファイルに統合します。
トップレベルステートメントを使用して、アプリに必要なコードを最小限に抑えます。
global using ディレクティブを使用して、using ステートメントを不要にするか、または必要とするその行数を最小限に抑えます。

次のコードは、使用されない using ステートメントが削除された、ASP.NET Core 5 Web App テンプレート (Razor Pages) の Startup.cs および Program.cs ファイルを示しています。

using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
// Unused usings removed.

namespace WebAppRPv5
{
    public class Startup
    {
        public Startup(IConfiguration configuration)
        {
            Configuration = configuration;
        }

        public IConfiguration Configuration { get; }

        // This method gets called by the runtime. Use this method to add services to the container.
        public void ConfigureServices(IServiceCollection services)
        {
            services.AddRazorPages();
        }

        // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
        public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
        {
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }
            else
            {
                app.UseExceptionHandler("/Error");
                // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
                app.UseHsts();
            }

            app.UseHttpsRedirection();
            app.UseStaticFiles();

            app.UseRouting();

            app.UseAuthorization();

            app.UseEndpoints(endpoints =>
            {
                endpoints.MapRazorPages();
            });
        }
    }
}

using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Hosting;
// Unused usings removed.

namespace WebAppRPv5
{
    public class Program
    {
        public static void Main(string[] args)
        {
            CreateHostBuilder(args).Build().Run();
        }

        public static IHostBuilder CreateHostBuilder(string[] args) =>
            Host.CreateDefaultBuilder(args)
                .ConfigureWebHostDefaults(webBuilder =>
                {
                    webBuilder.UseStartup<Startup>();
                });
    }
}

ASP.NET Core 6 では、上記のコードが次のコードに置き換えられます。

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddRazorPages();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

上記の ASP.NET Core 6 のサンプルは、次の方法を示しています。

ConfigureServices が WebApplication.Services に置き換えられます。
builder.Build() により、構成済みの WebApplication が変数 app に返されます。 Configure は、app を使用する同じサービスへの構成の呼び出しで置き換えられます。

最小のホスティングモデルを使用して ASP.NET Core 5 の Startup コードを ASP.NET Core 6 に移行する詳細な例については、このドキュメントで後ほど説明します。

Web App テンプレート用に生成された他のファイルに対して、いくつかの変更があります。

Index.cshtml および Privacy.cshtml では、使用されない using ステートメントが削除されます。
Error.cshtml の RequestId は、null 許容参照型 (NRT) として宣言されます。

- public string RequestId { get; set; }
+ public string? RequestId { get; set; }

appsettings.json と appsettings.Development.json では次のようにログレベルの既定値が変更されました。

- "Microsoft": "Warning",
- "Microsoft.Hosting.Lifetime": "Information"
+ "Microsoft.AspNetCore": "Warning"

前述の ASP.NET Core テンプレートコードでは、"Microsoft": "Warning" が "Microsoft.AspNetCore": "Warning" に変更されています。この変更によって、Microsoft 名前空間からのすべての情報メッセージは、Microsoft.AspNetCore を "除き"、ログに記録されることになります。たとえば Microsoft.EntityFrameworkCore は、情報レベルでログに記録されるようになりました。

新しいホスティングモデルの詳細については、「よく寄せられる質問」セクションを参照してください。 NRT と .NET コンパイラの null 状態分析詳細については、「null 許容参照型 (NRT) と .NET コンパイラの null 状態スタティック分析」セクションを参照してください。

6.0 以降に移行するまたは 6.0 以降を使用しているアプリは、新しい最小ホスティングモデルを使用する必要はありません

ASP.NET Core 3.1 および 5.0 テンプレートで使用されている Startup と汎用ホストの使用は完全にサポートされています。

最小ホスティングモデルで Startup を使用する

ASP.NET Core 3.1 および 5.0 アプリは、新しい最小ホスティングモデルで Startup コードを使用できます。最小ホスティングモデルで Startup を使用することには次の利点があります。

Startup クラスを呼び出すために隠れたリフレクションは使用されません。
開発者が Startup への呼び出しを制御するため、非同期コードを記述できます。
ConfigureServices と Configure をインターリーブするコードを記述できます。

新しい最小ホスティングモデルで Startup コードを使用する場合の小さな制限の 1 つは、Configure に依存関係を注入するには、Program.cs のサービスを手動で解決する必要があるということです。

ASP.NET Core 3.1 または 5.0 の Razor Pages テンプレートによって生成された次のコードについて考えてみましょう。

public class Program
{
    public static void Main(string[] args)
    {
        CreateHostBuilder(args).Build().Run();
    }

    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.UseStartup<Startup>();
            });
}

public class Startup
{
    public Startup(IConfiguration configuration)
    {
        Configuration = configuration;
    }

    public IConfiguration Configuration { get; }

    public void ConfigureServices(IServiceCollection services)
    {
        services.AddRazorPages();
    }

    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        if (env.IsDevelopment())
        {
            app.UseDeveloperExceptionPage();
        }
        else
        {
            app.UseExceptionHandler("/Error");
            app.UseHsts();
        }

        app.UseHttpsRedirection();
        app.UseStaticFiles();
        app.UseRouting();

        app.UseEndpoints(endpoints =>
        {
            endpoints.MapRazorPages();
        });
    }
}

新しい最小ホスティングモデルに移行された前述のコードは次のようになります。

using Microsoft.AspNetCore.Builder;

var builder = WebApplication.CreateBuilder(args);

var startup = new Startup(builder.Configuration);

startup.ConfigureServices(builder.Services);

var app = builder.Build();

startup.Configure(app, app.Environment);

app.Run();

public class Startup
{
    public Startup(IConfiguration configuration)
    {
        Configuration = configuration;
    }

    public IConfiguration Configuration { get; }

    public void ConfigureServices(IServiceCollection services)
    {
        services.AddRazorPages();
    }

    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        if (!env.IsDevelopment())
        {
            app.UseExceptionHandler("/Error");
            app.UseHsts();
        }

        app.UseHttpsRedirection();
        app.UseStaticFiles();
        app.UseRouting();

        app.UseEndpoints(endpoints =>
        {
            endpoints.MapRazorPages();
        });
    }
}

前述のコードにおいて、開発モードでは開発者例外ページミドルウェアが既定で有効になっているため、 if (env.IsDevelopment()) ブロックは削除されています。詳細については、次のセクションの「ASP.NET Core 5 と 6 のホスティングモデルの違い」を参照してください。

カスタム依存関係注入 (DI) コンテナーを使用する場合は、次の強調表示されたコードを追加します。

using Autofac;
using Autofac.Extensions.DependencyInjection;
using Microsoft.AspNetCore.Builder;
using Microsoft.Extensions.Hosting;

var builder = WebApplication.CreateBuilder(args);

var startup = new Startup(builder.Configuration);

startup.ConfigureServices(builder.Services);

// Using a custom DI container.
builder.Host.UseServiceProviderFactory(new AutofacServiceProviderFactory());
builder.Host.ConfigureContainer<ContainerBuilder>(startup.ConfigureContainer);

var app = builder.Build();

startup.Configure(app, app.Environment);

app.Run();

using Autofac;
public class Startup
{
    public Startup(IConfiguration configuration)
    {
        Configuration = configuration;
    }

    public IConfiguration Configuration { get; }

    public void ConfigureServices(IServiceCollection services)
    {
        services.AddRazorPages();
    }

    //  Using a custom DI container
    public void ConfigureContainer(ContainerBuilder builder)
    {
        // Configure custom container.
    }

    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        if (!env.IsDevelopment())
        {
            app.UseExceptionHandler("/Error");
            app.UseHsts();
        }

        app.UseHttpsRedirection();
        app.UseStaticFiles();
        app.UseRouting();

        app.UseEndpoints(endpoints =>
        {
            endpoints.MapRazorPages();
        });
    }
}

最小ホスティングモデルを使用する場合、エンドポイントルーティングミドルウェアは、ミドルウェアパイプライン全体をラップするため、UseRouting または UseEndpoints を明示的に呼び出してルートを登録する必要はありません。 UseRouting は引き続きルート照合が発生する場所を指定するために使用できますが、ミドルウェアパイプラインの先頭でルートを照合する必要がある場合は、UseRouting を明示的に呼び出す必要はありません。

次のコードでは、UseRouting と UseEndpoints への呼び出しは Startup から削除されています。 MapRazorPages は Program.cs で呼び出されます。

public class Startup
{
    public Startup(IConfiguration configuration)
    {
        Configuration = configuration;
    }

    public IConfiguration Configuration { get; }

    public void ConfigureServices(IServiceCollection services)
    {
        services.AddRazorPages();
    }

    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        if (!env.IsDevelopment())
        {
            app.UseExceptionHandler("/Error");
            app.UseHsts();
        }

        app.UseHttpsRedirection();
        app.UseStaticFiles();
        //app.UseRouting();

        //app.UseEndpoints(endpoints =>
        //{
        //    endpoints.MapRazorPages();
        //});
    }
}

using Microsoft.AspNetCore.Builder;

var builder = WebApplication.CreateBuilder(args);

var startup = new Startup(builder.Configuration);

startup.ConfigureServices(builder.Services);

var app = builder.Build();

startup.Configure(app, app.Environment);

app.MapRazorPages();

app.Run();

新しい最小ホスティングモデルで Startup を使用する場合は、次の違いに注意してください。

Program.cs は、Startup クラスのインスタンス化と有効期間を制御します。
Configure メソッドに挿入される追加のサービスはすべて、Program クラスによって手動で解決される必要があります。

ASP.NET Core 5 と 6 のホスティングモデルの違い

開発モードでは、開発者例外ページミドルウェアが既定で有効になっています。
アプリ名は、エントリポイントアセンブリの名前である Assembly.GetEntryAssembly().GetName().FullName を既定値とします。ライブラリで WebApplicationBuilder を使用する場合は、MVC のアプリケーションパーツ検出が機能できるように、このアプリ名をライブラリのアセンブリに明示的に変更してください。詳細な手順については、このドキュメントの「コンテンツのルート、アプリ名、および環境を変更する」を参照してください。
エンドポイントルーティングミドルウェアは、ミドルウェアパイプライン全体をラップするため、UseRouting または UseEndpoints を明示的に呼び出してルートを登録する必要はありません。 UseRouting は引き続きルート照合が発生する場所を指定するために使用できますが、ミドルウェアパイプラインの先頭でルートを照合する必要がある場合は、UseRouting を明示的に呼び出す必要はありません。
パイプラインは、IStartupFilter の実行前に作成されるため、パイプラインの構築中に発生した例外は、IStartupFilter 呼び出しチェーンに表示されません。
EF 移行などの一部のツールでは、Program.CreateHostBuilder を使用してアプリの IServiceProvider にアクセスし、アプリのコンテキストでカスタムロジックを実行します。これらのツールは、新しい手法を使用してアプリのコンテキストでカスタムロジックを実行するように更新されています。 Entity Framework 移行は、この方法で Program.CreateHostBuilder を使用するツールの一例です。ツールが新しいモデルを使用するように更新されていることを確認する作業は現在進行中です。
最小ホストの場合、Startup クラスとは異なり、サービスプロバイダーのインスタンスを作成するときに DI スコープは自動的に構成されません。スコープが必要なコンテキストの場合は、IServiceScopeFactory.CreateScope を指定して IServiceScope を呼び出し、新しいスコープのインスタンスを作成する必要があります。詳細については、アプリの起動時にサービスを解決する方法に関する記事を参照してください。
WebApplicationBuilder の作成後に、アプリ名、環境、またはコンテンツルートなどのホスト設定のどれかを変更することは "できません"。ホスト設定の変更に関する詳細な手順については、「IHostBuilder または IWebHostBuilder のカスタマイズ」を参照してください。次の強調表示された API では、例外がスローされます。

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

// WebHost

try
{
    builder.WebHost.UseContentRoot(Directory.GetCurrentDirectory());
}
catch (Exception ex)
{
    Console.WriteLine(ex.Message);
}

try
{
    builder.WebHost.UseEnvironment(Environments.Staging);
}
catch (Exception ex)
{
    Console.WriteLine(ex.Message);
}

try
{
    builder.WebHost.UseSetting(WebHostDefaults.ApplicationKey, "ApplicationName2");
}
catch (Exception ex)
{
    Console.WriteLine(ex.Message);
}

try
{
    builder.WebHost.UseSetting(WebHostDefaults.ContentRootKey, Directory.GetCurrentDirectory());
}
catch (Exception ex)
{
    Console.WriteLine(ex.Message);
}

try
{
    builder.WebHost.UseSetting(WebHostDefaults.EnvironmentKey, Environments.Staging);
}
catch (Exception ex)
{
    Console.WriteLine(ex.Message);
}

// Host
try
{
    builder.Host.UseEnvironment(Environments.Staging);
}
catch (Exception ex)
{
    Console.WriteLine(ex.Message);
}

try
{
    // TODO: This does not throw
    builder.Host.UseContentRoot(Directory.GetCurrentDirectory());
}
catch (Exception ex)
{
    Console.WriteLine(ex.Message);
}

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

WebApplicationBuilder.Host または WebApplicationBuilder.WebHost から Startup クラスを使用することはできません。次の強調表示されたコードでは、例外がスローされます。

var builder = WebApplication.CreateBuilder(args);

try
{
    builder.Host.ConfigureWebHostDefaults(webHostBuilder =>
    {
        webHostBuilder.UseStartup<Startup>();
    });
}
catch (Exception ex)
{
    Console.WriteLine(ex.Message);
    throw;    
}

builder.Services.AddRazorPages();

var app = builder.Build();

var builder = WebApplication.CreateBuilder(args);

try
{
    builder.WebHost.UseStartup<Startup>();
}
catch (Exception ex)
{
    Console.WriteLine(ex.Message);
    throw;    
}

builder.Services.AddRazorPages();

var app = builder.Build();

WebApplicationBuilder (WebApplicationBuilder.Host) 上の IHostBuilder の実装では、ConfigureServices、ConfigureAppConfiguration、または ConfigureHostConfiguration の実行は遅延されません。実行が遅延されないため、WebApplicationBuilder を使用するコードにより、IServiceCollection および IConfiguration に加えられる変更を監視することができます。次の例では、IService として Service1 のみを追加しています。

using Microsoft.Extensions.DependencyInjection.Extensions;

var builder = WebApplication.CreateBuilder(args);

builder.Host.ConfigureServices(services =>
{
    services.TryAddSingleton<IService, Service1>();
});

builder.Services.TryAddSingleton<IService, Service2>();

var app = builder.Build();

// Displays Service1 only.
Console.WriteLine(app.Services.GetRequiredService<IService>());

app.Run();

class Service1 : IService
{
}

class Service2 : IService
{
}

interface IService
{
}

上記のコードの builder.Host.ConfigureServices コールバックは、builder.Build が呼び出されるまで遅延されことはなく、インラインで呼び出されます。つまり、Service1 は、Service2 の前に IServiceCollection に追加され、IServiceに対して Service1 が解決されます。

ASP.NET Core 6 のライブラリの構築

既存の .NET エコシステムでは、IServiceCollection、IHostBuilder、IWebHostBuilder について拡張性が構築されています。これらのプロパティは、WebApplicationBuilder で Services、Host、WebHost として使用できます。

WebApplication では、Microsoft.AspNetCore.Builder.IApplicationBuilder と Microsoft.AspNetCore.Routing.IEndpointRouteBuilder の両方が実装されます。

ライブラリの作成者は ASP.NET Core 固有のコンポーネントを構築するときに、引き続き IHostBuilder、IWebHostBuilder、IApplicationBuilder、IEndpointRouteBuilder をターゲットにすることが想定されています。これにより、ミドルウェア、ルートハンドラー、またはその他の拡張ポイントは、さまざまなホスティングモデル間で引き続き機能することが保証されます。

よく寄せられる質問 (FAQ)

新しい最小ホスティングモデルの機能は低下していますか?

いいえ。新しいホスティングモデルは、IHostBuilder および IWebHostBuilder によってサポートされるシナリオの 98% で機能的に同等です。 IHostBuilder で特定の回避策を必要とする高度なシナリオがいくつかありますが、それらは非常にまれであると考えられます。
汎用ホスティングモデルは非推奨ですか?

いいえ。汎用ホスティングモデルは、無期限にサポートされる代替モデルです。汎用ホストは新しいホスティングモデルの基礎であり、引き続きワーカーベースのアプリケーションをホストするための主要な方法です。
新しいホスティングモデルに移行する必要がありますか?

いいえ。新しいホスティングモデルは、.NET 6 以降を使用する新しいアプリをホストするための推奨される方法ですが、既存のアプリのプロジェクトレイアウトを変更する必要はありません。つまり、プロジェクトファイルのターゲットフレームワークを net5.0 から net6.0 に変更することで、アプリを .NET 5 から .NET 6 にアップグレードできます。詳細については、この記事の「ターゲットフレームの更新」セクションを参照してください。ただし、新しいホスティングモデルでのみ使用できる新しい機能を利用するには、アプリを新しいホスティングモデルに移行することをお勧めします。
トップレベルステートメントを使用する必要がありますか?

いいえ。新しいプロジェクトテンプレートはすべてトップレベルステートメントを使用しますが、新しいホスティング API を任意の .NET 6 アプリで使用して、Web サーバーまたは Web アプリをホストできます。
Program または Startup クラスにフィールドとして格納された状態をどこに配置しますか?

依存関係挿入 (DI) を使用して、ASP.NET Core アプリの状態をフローすることを強くお勧めします。

DI の外部に状態を格納するには、次の 2 つの方法があります。
- 状態を別のクラスに格納します。クラスに格納する場合、状態はアプリ内のどこからでもアクセスできる静的な状態であることを前提とします。
- トップレベルステートメントによって生成される Program を使用して状態を格納します。 Program を使用して状態を格納する方法は、セマンティックアプローチです。
```
var builder = WebApplication.CreateBuilder(args);

ConfigurationValue = builder.Configuration["SomeKey"] ?? "Hello";

var app = builder.Build();

app.MapGet("/", () => ConfigurationValue);

app.Run();

partial class Program
{
    public static string? ConfigurationValue { get; private set; }
}
```
カスタムの依存関係挿入コンテナーを使用していた場合はどうなりますか?

カスタムの DI コンテナーはサポートされます。例については、「カスタムの依存関係挿入 (DI) コンテナー」を参照してください。
WebApplicationFactory および TestServer は引き続き機能しますか?

はい。 WebApplicationFactory<TEntryPoint> は、新しいホスティングモデルをテストするための方法です。例については、「WebApplicationFactory または TestServer を使用してテストする」を参照してください。

Blazor

この記事の前半のガイダンスに従ってアプリを 6.0 に更新した後、「ASP.NET Core 6.0 の新機能」のリンクに従って、特定の機能を導入します。

Blazor アプリのための 6.0 の新機能をすべて導入するには、次のプロセスに従うことをお勧めします。

Blazor プロジェクトテンプレートの 1 つから新しい 6.0 Blazor プロジェクトを作成します。詳しくは、「ASP.NET Core Blazor 用のツール」をご覧ください。
アプリのコンポーネントとコードを 6.0 アプリに移動して、6.0 の新機能を導入するように変更します。

SPA プロジェクトの移行

SPA 拡張機能からの Angular アプリの移行

こちらの GitHub の issue を参照してください

SPA 拡張機能からの React アプリの移行

この GitHub のイシューの「SPA 拡張機能からの React アプリケーションの移行」を参照してください

Docker イメージの更新

Docker を使用するアプリの場合、Dockerfile の FROM ステートメントとスクリプトを更新します。 ASP.NET Core 6.0 ランタイムを含む基本イメージを使用します。 ASP.NET Core 5.0 と 6.0 の間では docker pull コマンドに次の違いがあることに注意してください。

- docker pull mcr.microsoft.com/dotnet/aspnet:5.0
+ docker pull mcr.microsoft.com/dotnet/aspnet:6.0

GitHub イシューの「破壊的変更: 既定のコンソールロガーのフォーマットを JSON に設定」をご覧ください。

ASP.NET Core Razor SDK に変更する

Razor コンパイラでは、新しいソースジェネレーター機能を活用して、プロジェクト内の Razor ビューとページからコンパイル済みの C# ファイルを生成するようになりました。以前のバージョンでは、次のように動作していました。

コンパイルは、生成済みのコードを生成するために RazorGenerate および RazorCompile ターゲットに依存していました。これらのターゲットは有効ではなくなりました。 .NET 6 では、コードの生成とコンパイルの両方が、コンパイラへの 1 回の呼び出しでサポートされます。 RazorComponentGenerateDependsOn は、ビルドを実行する前に必要な依存関係を指定するために引き続きサポートされます。
アプリケーションでコンパイルされたビューの種類を含む別の Razor アセンブリ AppName.Views.dll が生成されていました。この動作は非推奨になり、アプリの種類と生成済みのビューの両方を含む単一のアセンブリ AppName.dll が生成されます。
AppName.Views.dll に含まれるアプリの種類は public でした。 .NET 6 でも、アプリの種類は AppName.dll に含まれますが、internal sealed です。 AppName.Views.dll で型の検出を実行するアプリは、AppName.dll で型の検出を実行できません。以下に、API の変更を示します。

- public class Views_Home_Index : global::Microsoft.AspNetCore.Mvc.Razor.RazorPage<dynamic>
+ internal sealed class Views_Home_Index : global::Microsoft.AspNetCore.Mvc.Razor.RazorPage<dynamic>

次の変更を行います。

次のプロパティは、シングルステップのコンパイルモデルで使用できなくなりました。
- RazorTargetAssemblyAttribute
- RazorTargetName
- EnableDefaultRazorTargetAssemblyInfoAttributes
- UseRazorBuildServer
- GenerateRazorTargetAssemblyInfo
- GenerateMvcApplicationPartsAssemblyAttributes

詳細については、「RazorRazor: コンパイラによって Views アセンブリが生成されなくなりました」を参照してください。

Duende Identity Server を使用するプロジェクトテンプレート

プロジェクトテンプレートでは、Duende Identity Serverが使用されるようになりました。移行のガイダンスについては、「Server4 v4.1 から Duende Server v5」をご覧ください。

重要

Duende Identity Server は、レシプロカルライセンス契約を伴うオープンソース製品です。運用環境で Duende Identity Server を使用する予定がある場合は、Duende Software から商用ライセンスを取得し、ライセンス料金を支払うことが必要な場合があります。詳細については、「Duende Software: ライセンス」を参照してください。

ASP.NET Core Identity に Microsoft Azure Active Directory を使用する方法については、「Identity (dotnet/aspnetcore GitHub リポジトリ)」を参照してください。

IPersistedGrantDbContext の更新バージョンの新しい要件を満たすために、すべての IdentityDbContext に Keys という名前の DbSet<Key> プロパティを追加します。 Duende Identity Server のストアとのコントラクトの一部としてキーが必要です。

public DbSet<Key> Keys { get; set; }

メモ

既存の移行は、Duende Identity Server 用に再作成する必要があります。

ASP.NET Core 6.0 に移行されたコードサンプル

6.0 での新しい最小ホスティングモデルに移行されたコードサンプル

破壊的変更の確認

次のリソースを参照してください。

Identity: UI の既定のブートストラップバージョンを変更
バージョン 5.0 から 6.0 への移行に関する破壊的変更: ASP.NET Core および Entity Framework Core が含まれています。
Announcements GitHub リポジトリ (aspnet/Announcements、6.0.0 ラベル): 破壊的および非破壊的な情報が含まれています。

null 許容参照型 (NRT) と .NET コンパイラの null 状態スタティック分析

ASP.NET Core プロジェクトテンプレートでは、null 許容参照型 (NRT) が使用され、.NET コンパイラでは null 状態スタティック分析が実行されます。これらの機能は、C# 8 でリリースされていて、ASP.NET Core 6.0 (C# 10) 以降を使用して生成されたアプリに対して既定で有効になります。

.NET コンパイラの null 状態スタティック分析の警告は、ドキュメントの例またはサンプルアプリをローカルで更新するためのガイドとして使用することも、無視することもできます。 null 状態スタティック分析は、アプリのプロジェクトファイルで Nullable を disable に設定することにより無効にすることができます。これを推奨するのは、ドキュメントの例およびサンプルアプリにおいて、.NET の学習中にコンパイラの警告が邪魔に感じる場合のみです。 "運用プロジェクトで null 状態チェックを無効にすることはお勧めしません。"

NRT、MSBuild の Nullable プロパティ、およびアプリの更新方法 (#pragma のガイダンスを含む) の詳細については、C# ドキュメントの次のリソースを参照してください。

ASP.NET Core モジュール (ANCM)

Visual Studio のインストール時に ASP.NET Core モジュール (ANCM) が選択されたコンポーネントではなかった場合、または ANCM の以前のバージョンがシステムにインストールされていた場合は、最新の .NET Core ホスティングバンドルインストーラー (直接ダウンロード) をダウンロードし、インストーラーを実行します。詳細については、「ホスティングバンドル」を参照してください。

アプリケーション名の変更

.NET 6 では、WebApplicationBuilder によって、コンテンツのルートパスが DirectorySeparatorChar で終わるように正規化されます。 HostBuilder または WebHostBuilder から移行するほとんどのアプリは正規化されないため、同じアプリ名を共有することはありません。詳しくは、「SetApplicationName」をご覧ください。

その他の技術情報

6.0 での新しい最小ホスティングモデルに移行されたコードサンプル

次の方法で共有

ASP.NET Core 5.0 から 6.0 への移行

必須コンポーネント

global.json で .NET Core SDK バージョンを更新する

ターゲットフレームワークを更新する

パッケージ参照の更新

新しいホスティングモデル

6.0 以降に移行するまたは 6.0 以降を使用しているアプリは、新しい最小ホスティングモデルを使用する必要はありません

最小ホスティングモデルで Startup を使用する

ASP.NET Core 5 と 6 のホスティングモデルの違い

ASP.NET Core 6 のライブラリの構築

よく寄せられる質問 (FAQ)

Blazor

SPA プロジェクトの移行

SPA 拡張機能からの Angular アプリの移行

SPA 拡張機能からの React アプリの移行

Docker イメージの更新

ASP.NET Core Razor SDK に変更する

Duende Identity Server を使用するプロジェクトテンプレート

ASP.NET Core 6.0 に移行されたコードサンプル

破壊的変更の確認

null 許容参照型 (NRT) と .NET コンパイラの null 状態スタティック分析

ASP.NET Core モジュール (ANCM)

アプリケーション名の変更

その他の技術情報

その他のリソース

次の方法で共有

ASP.NET Core 5.0 から 6.0 への移行

必須コンポーネント

global.json で .NET Core SDK バージョンを更新する

ターゲット フレームワークを更新する

パッケージ参照の更新

新しいホスティング モデル

6.0 以降に移行するまたは 6.0 以降を使用しているアプリは、新しい最小ホスティング モデルを使用する必要はありません

最小ホスティング モデルで Startup を使用する

ASP.NET Core 5 と 6 のホスティング モデルの違い

ASP.NET Core 6 のライブラリの構築

よく寄せられる質問 (FAQ)

Blazor

SPA プロジェクトの移行

SPA 拡張機能からの Angular アプリの移行

SPA 拡張機能からの React アプリの移行

Docker イメージの更新

ASP.NET Core Razor SDK に変更する

Duende Identity Server を使用するプロジェクト テンプレート

ASP.NET Core 6.0 に移行されたコード サンプル

破壊的変更の確認

null 許容参照型 (NRT) と .NET コンパイラの null 状態スタティック分析

ASP.NET Core モジュール (ANCM)

アプリケーション名の変更

その他の技術情報

その他のリソース

ターゲットフレームワークを更新する

新しいホスティングモデル

6.0 以降に移行するまたは 6.0 以降を使用しているアプリは、新しい最小ホスティングモデルを使用する必要はありません

最小ホスティングモデルで Startup を使用する

ASP.NET Core 5 と 6 のホスティングモデルの違い

Duende Identity Server を使用するプロジェクトテンプレート

ASP.NET Core 6.0 に移行されたコードサンプル