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

[アーティクル]
05/09/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 SDK のバージョンを更新する global.json

特定の .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.Development.jsonでappsettings.json変更されました。

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

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

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

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

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

新しい最小ホスティングモデルでスタートアップを使用する

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

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

新しい最小ホスティングモデルでコードを使用 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();
        });
    }
}

最小ホスティングモデルを使用する場合、エンドポイントルーティングミドルウェアはミドルウェアパイプライン全体をラップするため、ルートを明示的に呼び出したりUseEndpoints、ルートをUseRouting登録したりする必要はありません。 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 のアプリケーションパーツ検出が機能できるように、このアプリ名をライブラリのアセンブリに明示的に変更してください。詳細な手順については、このドキュメントの「コンテンツのルート、アプリ名、および環境を変更する」を参照してください。
エンドポイントルーティングミドルウェアはミドルウェアパイプライン全体をラップするため、ルートの登録またはUseEndpoints明示的な呼び出しをUseRouting行う必要はありません。 UseRouting は引き続きルート一致が発生する場所を指定するために使用できますが UseRouting 、ミドルウェアパイプラインの先頭でルートを照合する必要がある場合は明示的に呼び出す必要はありません。
パイプラインは、IStartupFilter の実行前に作成されるため、パイプラインの構築中に発生した例外は、IStartupFilter 呼び出しチェーンに表示されません。
EF 移行などの一部のツールでは、Program.CreateHostBuilder を使用してアプリの IServiceProvider にアクセスし、アプリのコンテキストでカスタムロジックを実行します。これらのツールは、新しい手法を使用してアプリのコンテキストでカスタムロジックを実行するように更新されています。 Entity Framework Migrations は、この方法でを使用 Program.CreateHostBuilder するツールの例です。ツールが新しいモデルを使用するように更新されていることを確認する作業は現在進行中です。
の作成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 の新機能」のリンクに従って、特定の機能を採用します。

アプリに新しい 6.0 機能Blazorをすべて採用するには、次のプロセスをお勧めします。

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 を使用するアプリの場合は、 DockerfileFROM ステートメントとスクリプトを更新します。 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 issue Breaking Change: Default console logger format set to ON」をJS参照してください。

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が使用されるようになりました。移行のガイダンスについては、「IdentityServer4 v4.1 から Duende IdentityServer v5」を参照してください。

重要

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

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

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# ドキュメントの次のリソースを参照してください。

Null 許容参照型
Null 許容参照型 (C# リファレンス)
null 許容の警告を解決する手法を学ぶ
null 診断警告を改善するために、null 許容参照型を使用してコードベースを更新する
[null 状態のスタティック分析の属性](../../../../csharp/language-reference/attributes/nullable-analysis.md)

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 への移行

前提条件

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

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

パッケージ参照の更新

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

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

新しい最小ホスティング モデルでスタートアップを使用する

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 以降に移行または使用するアプリでは、新しい最小ホスティングモデルを使用する必要はありません

新しい最小ホスティングモデルでスタートアップを使用する

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

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

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