Migrowanie z ASP.NET Core 5.0 do wersji 6.0

Artykuł
11/30/2023

W tym artykule wyjaśniono, jak zaktualizować istniejący projekt ASP.NET Core 5.0 w celu ASP.NET Core 6.0. Aby uzyskać instrukcje dotyczące migracji z ASP.NET Core 3.1 do ASP.NET Core 6.0, zobacz Migrowanie z ASP.NET Core 3.1 do 6.0.

Wymagania wstępne

Program Visual Studio 2022 z pakietem roboczym tworzenia aplikacji ASP.NET i aplikacji internetowych.
Zestaw SDK dla platformy .NET 6.0

Aktualizowanie wersji zestawu .NET SDK w programie global.json

Jeśli plik jest zależny od global.json określonej wersji zestawu .NET SDK, zaktualizuj version właściwość do zainstalowanej wersji zestawu SDK platformy .NET 6.0. Na przykład:

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

Aktualizowanie platformy docelowej

Zaktualizuj plik projektu Target Framework Moniker (TFM) na net6.0:

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

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

</Project>

Aktualizowanie odwołań do pakietów

W pliku projektu zaktualizuj atrybut każdego Microsoft.AspNetCore.* odwołania Version i Microsoft.Extensions.* pakietu do 6.0.0 lub nowszego. Na przykład:

<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>

Nowy model hostingu

Nowy minimalny model hostingu platformy .NET 6 dla aplikacji ASP.NET Core wymaga tylko jednego pliku i kilku wierszy kodu. Aplikacje migrujące do wersji 6.0 nie muszą używać nowego minimalnego modelu hostingu. Aby uzyskać więcej informacji, zobacz Aplikacje migrujące do wersji 6.0 nie muszą używać nowego minimalnego modelu hostingu w poniższej sekcji.

Poniższy kod z pustego szablonu ASP.NET Core tworzy aplikację przy użyciu nowego minimalnego modelu hostingu:

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

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

app.Run();

Minimalny model hostingu:

Znacznie zmniejsza liczbę plików i wierszy kodu wymaganych do utworzenia aplikacji. Potrzebny jest tylko jeden plik z czterema wierszami kodu.
Unifies i into a single file (Unifies Startup.cs i Program.cs into a single Program.cs file).
Używa instrukcji najwyższego poziomu, aby zminimalizować kod wymagany dla aplikacji.
Używa dyrektyw globalnychusing, aby wyeliminować lub zminimalizować wymaganą liczbę wierszy instrukcji using.

Poniższy kod wyświetla Startup.cs pliki i Program.cs z szablonu aplikacji internetowej platformy ASP.NET Core 5 (Razor strony) z usuniętymi nieużywanymi using instrukcjami:

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>();
                });
    }
}

W ASP.NET Core 6 powyższy kod jest zastępowany następującym kodem:

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();

W poprzednim przykładzie ASP.NET Core 6 pokazano, jak:

ConfigureServices element jest zastępowany ciągiem WebApplication.Services.
builder.Build() Zwraca wartość skonfigurowaną WebApplication dla zmiennej app. Configure element jest zastępowany wywołaniami konfiguracji do tych samych usług przy użyciu polecenia app.

Szczegółowe przykłady migrowania kodu ASP.NET Core 5 Startup do ASP.NET Core 6 przy użyciu minimalnego modelu hostingu znajdują się w dalszej części tego dokumentu.

Istnieje kilka zmian w innych plikach wygenerowanych dla szablonu aplikacji internetowej:

Index.cshtml i Privacy.cshtml mają usunięte nieużywane using instrukcje.
RequestId in Error.cshtml jest deklarowany jako typ odwołania dopuszczalnego wartości null (NRT)::

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

Wartości domyślne na poziomie dziennika zostały zmienione w systemach appsettings.json i appsettings.Development.json:

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

W poprzednim kodzie "Microsoft": "Warning" szablonu ASP.NET Core został zmieniony na "Microsoft.AspNetCore": "Warning". Ta zmiana powoduje rejestrowanie wszystkich komunikatów informacyjnych z przestrzeni nazw z Microsoft wyjątkiemMicrosoft.AspNetCore. Na przykład Microsoft.EntityFrameworkCore jest teraz rejestrowany na poziomie informacyjnym.

Aby uzyskać więcej informacji na temat nowego modelu hostingu, zobacz sekcję Często zadawane pytania . Aby uzyskać więcej informacji na temat wdrażania analizy stanu null kompilatora i kompilatora platformy .NET, zobacz sekcję Analiza statyczna typu referencyjnego dopuszczanego wartości null (NRT) i kompilatora platformy .NET.

Aplikacje migrujące do wersji 6.0 lub nowszej nie muszą używać nowego minimalnego modelu hostingu

Używanie Startup i host ogólny używany przez szablony ASP.NET Core 3.1 i 5.0 jest w pełni obsługiwane.

Korzystanie z uruchamiania z nowym minimalnym modelem hostingu

aplikacje ASP.NET Core 3.1 i 5.0 mogą używać kodu Startup z nowym minimalnym modelem hostingu. Użycie Startup z minimalnym modelem hostingu ma następujące zalety:

Do wywołania Startup klasy nie jest używane żadne ukryte odbicie.
Kod asynchroniczny można napisać, ponieważ deweloper kontroluje wywołanie metody Startup.
Można napisać kod, który przeplata ConfigureServices się i Configure.

Jednym z drobnych ograniczeń dotyczących używania Startup kodu z nowym minimalnym modelem hostingu jest to, że aby wstrzyknąć zależność do Configureelementu , usługa w Program.cs programie musi zostać rozwiązana ręcznie.

Rozważmy następujący kod wygenerowany przez szablon ASP.NET Core 3.1 lub 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();
        });
    }
}

Poprzedni kod zmigrowany do nowego minimalnego modelu hostingu:

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();
        });
    }
}

W poprzednim kodzie blok jest usuwany, if (env.IsDevelopment()) ponieważ w trybie programowania oprogramowanie pośredniczące strony wyjątku dewelopera jest domyślnie włączone. Aby uzyskać więcej informacji, zobacz Różnice między modelami hostingu platformy ASP.NET Core 5 i 6 w następnej sekcji.

W przypadku korzystania z niestandardowego kontenera wstrzykiwania zależności (DI) dodaj następujący wyróżniony kod:

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();
        });
    }
}

W przypadku korzystania z minimalnego modelu hostingu oprogramowanie pośredniczące routingu punktu końcowego opakowuje cały potok oprogramowania pośredniczącego, dlatego nie ma potrzeby jawnych wywołań ani UseRoutingUseEndpoints rejestrowania tras. UseRouting Można nadal używać do określania, gdzie odbywa się dopasowywanie tras, ale UseRouting nie musi być jawnie wywoływane, jeśli trasy powinny być dopasowane na początku potoku oprogramowania pośredniczącego.

W poniższym kodzie wywołania metody UseRouting i UseEndpoints są usuwane z Startupklasy . MapRazorPages jest wywoływana w pliku 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();

W przypadku korzystania Startup z nowego minimalnego modelu hostingu należy pamiętać o następującej różnicy:

Program.cs steruje tworzeniem wystąpienia i okresem Startup istnienia klasy.
Wszelkie dodatkowe usługi wprowadzone do Configure metody muszą zostać ręcznie rozpoznane przez klasę Program .

Różnice między modelami hostingu ASP.NET Core 5 i 6

W trybie programowania oprogramowanie pośredniczące strony wyjątku dewelopera jest domyślnie włączone.
Nazwa aplikacji jest domyślnie nazwą zestawu punktu wejścia: Assembly.GetEntryAssembly().GetName().FullName. W przypadku korzystania z WebApplicationBuilder elementu w bibliotece jawnie zmień nazwę aplikacji na zestaw biblioteki, aby umożliwić odnajdywanie części aplikacji MVC do pracy. Aby uzyskać szczegółowe instrukcje, zobacz Zmienianie katalogu głównego zawartości, nazwy aplikacji i środowiska w tym dokumencie.
Oprogramowanie pośredniczące routingu punktów końcowych opakowuje cały potok oprogramowania pośredniczącego, dlatego nie ma potrzeby jawnych wywołań ani UseRoutingUseEndpoints rejestrowania tras. UseRouting Można nadal używać do określania, gdzie odbywa się dopasowywanie tras, ale UseRouting nie musi być jawnie wywoływane, jeśli trasy powinny być dopasowane na początku potoku oprogramowania pośredniczącego.
Potok jest tworzony przed każdym IStartupFilter uruchomieniem, dlatego wyjątki spowodowane podczas tworzenia potoku nie są widoczne dla IStartupFilter łańcucha wywołań.
Niektóre narzędzia, takie jak migracje ef, służą Program.CreateHostBuilder do uzyskiwania dostępu do aplikacji IServiceProvider w celu wykonywania logiki niestandardowej w kontekście aplikacji. Te narzędzia zostały zaktualizowane w celu użycia nowej techniki do wykonywania logiki niestandardowej w kontekście aplikacji. Migracje platformy Entity Framework to przykład narzędzia, które używa Program.CreateHostBuilder w ten sposób. Pracujemy nad upewnieniem się, że narzędzia zostały zaktualizowane w celu korzystania z nowego modelu.
Startup W przeciwieństwie do klasy minimalny host nie konfiguruje automatycznie zakresu di podczas tworzenia wystąpienia dostawcy usług. W przypadku kontekstów, w których wymagany jest zakres, należy wywołać IServiceScope element IServiceScopeFactory.CreateScope , aby utworzyć wystąpienie nowego zakresu. Aby uzyskać więcej informacji, zobacz jak rozwiązać problem z usługą podczas uruchamiania aplikacji.
Nie można zmienić żadnych ustawień hosta, takich jak nazwa aplikacji, środowisko lub katalog główny zawartości po utworzeniu obiektu WebApplicationBuilder. Aby uzyskać szczegółowe instrukcje dotyczące zmieniania ustawień hosta, zobacz Dostosowywanie IHostBuilder lub IWebHostBuilder. Następujące wyróżnione interfejsy API zgłaszają wyjątek:

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();

Nie Startup można użyć klasy z lub WebApplicationBuilder.HostWebApplicationBuilder.WebHost. Poniższy wyróżniony kod zgłasza wyjątek:

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();

Implementacja IHostBuilder metody WebApplicationBuilder (WebApplicationBuilder.Host) nie odrocza wykonywania ConfigureServicesmetod , ConfigureAppConfigurationlub ConfigureHostConfiguration . Nie odroczenie wykonywania umożliwia używanie WebApplicationBuilder kodu w celu obserwowania zmian wprowadzonych w elementach IServiceCollection i IConfiguration. Poniższy przykład dodaje Service1 tylko jako element IService:

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
{
}

W poprzednim kodzie wywołanie zwrotne jest wywoływane w tekście, builder.Host.ConfigureServices a nie odroczone do builder.Build momentu wywołania. Oznacza to, że Service1 element jest dodawany do IServiceCollection elementu przed Service2 i powoduje Service1 rozwiązanie problemu dla elementu IService.

Kompilowanie bibliotek dla platformy ASP.NET Core 6

Istniejący ekosystem platformy .NET zbudował rozszerzalność wokół IServiceCollectionelementów , IHostBuilderi IWebHostBuilder. Te właściwości są dostępne w systemach WebApplicationBuilderServices, Hosti WebHost.

WebApplication implementuje zarówno elementy , jak Microsoft.AspNetCore.Builder.IApplicationBuilder i Microsoft.AspNetCore.Routing.IEndpointRouteBuilder.

Oczekujemy, że autorzy bibliotek będą nadal kierować do IHostBuilderelementów docelowych , IWebHostBuilder, IApplicationBuilderi IEndpointRouteBuilder podczas kompilowania składników specyficznych dla platformy ASP.NET Core. Dzięki temu oprogramowanie pośredniczące, program obsługi tras lub inne punkty rozszerzalności będą nadal działać w różnych modelach hostingu.

Często zadawane pytania

Czy nowy minimalny model hostingu jest mniej zdolny?

L.p. Nowy model hostingu jest funkcjonalnie równoważny dla 98% scenariuszy obsługiwanych przez IHostBuilder program i IWebHostBuilder. Istnieją pewne zaawansowane scenariusze, które wymagają konkretnych obejść w systemie IHostBuilder, ale oczekujemy, że będą one niezwykle rzadkie.
Czy ogólny model hostingu jest przestarzały?

L.p. Ogólny model hostingu jest alternatywnym modelem, który jest obsługiwany przez czas nieokreślony. Host ogólny stanowi podstawę nowego modelu hostingu i jest nadal podstawowym sposobem hostowania aplikacji opartych na procesach roboczych.
Czy muszę przeprowadzić migrację do nowego modelu hostingu?

L.p. Nowy model hostingu jest preferowanym sposobem hostowania nowych aplikacji przy użyciu platformy .NET 6 lub nowszej, ale nie trzeba zmieniać układu projektu w istniejących aplikacjach. Oznacza to, że aplikacje mogą uaktualnić platformę .NET 5 do .NET 6, zmieniając platformę docelową w pliku projektu z net5.0 na net6.0. Aby uzyskać więcej informacji, zobacz sekcję Aktualizowanie platformy docelowej w tym artykule. Zalecamy jednak migrację aplikacji do nowego modelu hostingu, aby korzystać z nowych funkcji dostępnych tylko dla nowego modelu hostingu.
Czy muszę używać instrukcji najwyższego poziomu?

L.p. Nowe szablony projektów używają instrukcji najwyższego poziomu, ale nowe interfejsy API hostingu mogą być używane w dowolnej aplikacji platformy .NET 6 do hostowania serwera internetowego lub aplikacji internetowej.
Gdzie umieścić stan, który był przechowywany jako pola w mojej klasie Program lub Startup ?

Zdecydowanie zalecamy używanie wstrzykiwania zależności (DI) do przepływu stanu w aplikacjach ASP.NET Core.

Istnieją dwa podejścia do przechowywania stanu poza di:
- Zapisz stan w innej klasie. Przechowywanie w klasie zakłada stan statyczny, do którego można uzyskać dostęp z dowolnego miejsca w aplikacji.
- Użyj klasy wygenerowanej Program przez instrukcje najwyższego poziomu do przechowywania stanu. Używanie Program metody do przechowywania stanu to metoda semantyczna:
```
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; }
}
```
Co zrobić, jeśli używam niestandardowego kontenera iniekcji zależności?

Niestandardowe kontenery DI są obsługiwane. Aby zapoznać się z przykładem, zobacz Niestandardowy kontener iniekcji zależności (DI).
Czy i WebApplicationFactoryTestServer nadal działa?

Tak. WebApplicationFactory<TEntryPoint> to sposób testowania nowego modelu hostingu. Aby zapoznać się z przykładem, zobacz Testowanie za pomocą WebApplicationFactory polecenia lub TestServer.

Blazor

Po wykonaniu wskazówek we wcześniejszej wersji tego artykułu, aby zaktualizować aplikację do wersji 6.0, zastosuj określone funkcje, korzystając z linków w temacie Co nowego w programie ASP.NET Core 6.0.

Aby wdrożyć wszystkie nowe funkcje w wersji 6.0 dla Blazor aplikacji, zalecamy następujący proces:

Utwórz nowy projekt w wersji 6.0 Blazor na podstawie jednego z Blazor szablonów projektów. Aby uzyskać więcej informacji, zobacz Tooling for ASP.NET Core Blazor.
Przenieś składniki i kod aplikacji do aplikacji w wersji 6.0, wprowadzając modyfikacje w celu wdrożenia nowych funkcji w wersji 6.0.

Migrowanie projektów SPA

Migrowanie aplikacji Angular z rozszerzeń SPA

Zobacz ten problem z usługą GitHub

Migrowanie aplikacji React z rozszerzeń SPA

Zobacz Migrowanie aplikacji React z rozszerzeń Spa w tym problemie z usługą GitHub

Aktualizowanie obrazów platformy Docker

W przypadku aplikacji korzystających z platformy Docker zaktualizuj instrukcje i skrypty dockerfileFROM . Użyj obrazu podstawowego, który zawiera środowisko uruchomieniowe ASP.NET Core 6.0. Rozważ następującą docker pull różnicę poleceń między ASP.NET Core 5.0 i 6.0:

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

Zobacz Zmiana powodująca niezgodność problemu w usłudze GitHub: domyślny format rejestratora konsoli ustawiony na WŁJS.

Zmiany w zestawie ASP.NET Core Razor SDK

Kompilator Razor wykorzystuje teraz nową funkcję generatorów źródeł do generowania skompilowanych plików języka C# z Razor widoków i stron w projekcie. W poprzednich wersjach:

Kompilacja polegała na elementach RazorGenerate docelowych i RazorCompile w celu utworzenia wygenerowanego kodu. Te cele nie są już prawidłowe. Na platformie .NET 6 zarówno generowanie kodu, jak i kompilacja są obsługiwane przez pojedyncze wywołanie kompilatora. RazorComponentGenerateDependsOn Program jest nadal obsługiwany w celu określenia zależności, które są wymagane przed uruchomieniem kompilacji.
Wygenerowano oddzielny Razor zestaw AppName.Views.dllzawierający skompilowane typy widoków w aplikacji. To zachowanie zostało uznane za przestarzałe, a tworzony jest pojedynczy zestaw AppName.dll zawierający zarówno typy aplikacji, jak i wygenerowane widoki.
Typy aplikacji były AppName.Views.dll publiczne. W programie .NET 6 typy aplikacji znajdują się, AppName.dll ale są .internal sealed Aplikacje wykonujące odnajdywanie AppName.Views.dll typu na platformie nie będą mogły odnajdywać typu w systemie AppName.dll. Poniżej przedstawiono zmianę interfejsu 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>

Wprowadź następujące zmiany:

Następujące właściwości nie mają już zastosowania w przypadku modelu kompilacji jednoetapowej.
- RazorTargetAssemblyAttribute
- RazorTargetName
- EnableDefaultRazorTargetAssemblyInfoAttributes
- UseRazorBuildServer
- GenerateRazorTargetAssemblyInfo
- GenerateMvcApplicationPartsAssemblyAttributes

Aby uzyskać więcej informacji, zobacz Razor kompilator nie tworzy już zestawu Views.

Szablony projektów używają serwera Duende Identity Server

Szablony projektów używają teraz serwera Duende Identity Server. Aby uzyskać wskazówki dotyczące migracji, zobacz IdentityServer4 v4.1 to Duende IdentityServer v5.

Ważne

Duende Identity Server to produkt typu open source z wzajemną umową licencyjną. Jeśli planujesz korzystać z serwera Duende Identity Server w środowisku produkcyjnym, może być wymagane uzyskanie licencji komercyjnej od Duende Software i zapłacenie opłaty licencyjnej. Aby uzyskać więcej informacji, zobacz Duende Software: Licenses (Duende Software: Licenses).

Aby dowiedzieć się, jak używać usługi Microsoft Azure Active Directory dla platformy ASP.NET CoreIdentity, zobacz Identity (repozytorium dotnet/aspnetcore GitHub).

DbSet<Key> Dodaj właściwość o nazwie Keys do każdegoIdentityDbContext, aby spełnić nowe wymaganie ze zaktualizowanej wersji programu IPersistedGrantDbContext. Klucze są wymagane w ramach umowy z magazynami serwera Duende Identity Server.

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

Uwaga

Istniejące migracje muszą być ponownie tworzone dla serwera Duende Identity .

Przykłady kodu migrowane do ASP.NET Core 6.0

Przykłady kodu migrowane do nowego minimalnego modelu hostingu w wersji 6.0

Przeglądanie zmian powodujących niezgodność

Zobacz następujące zasoby:

Identity: Zmieniono domyślną wersję interfejsu użytkownika bootstrap
Zmiany powodujące niezgodność dotyczące migracji z wersji 5.0 do 6.0: obejmuje ASP.NET Core i Entity Framework Core.
Repozytorium Anonsów w usłudze GitHub (aspnet/Anonsy, 6.0.0 etykieta): zawiera informacje powodujące niezgodność i niezgodność.

Typy referencyjne dopuszczane do wartości null (NRT) i statyczna analiza stanu null kompilatora platformy .NET

ASP.NET Core szablony projektów używają typów referencyjnych dopuszczanych wartości null (NRT), a kompilator platformy .NET wykonuje analizę statyczną stanu null. Te funkcje zostały wydane w języku C# 8 i są domyślnie włączone dla aplikacji generowanych przy użyciu platformy ASP.NET Core 6.0 (C# 10) lub nowszej.

Ostrzeżenia dotyczące statycznej analizy stanu null kompilatora platformy .NET mogą służyć jako przewodnik aktualizacji przykładu dokumentacji lub przykładowej aplikacji lokalnie albo być ignorowane. Analizę statyczną stanu null można wyłączyć, ustawiając wartość Nullable na disable w pliku projektu aplikacji, która jest zalecana tylko dla przykładów dokumentacji i przykładowych aplikacji, jeśli ostrzeżenia kompilatora rozpraszają uwagę podczas poznawania platformy .NET. Nie zalecamy wyłączania sprawdzania stanu null w projektach produkcyjnych.

Aby uzyskać więcej informacji na temat numerów NRT, właściwości MSBuild Nullable i aktualizowania aplikacji (w tym #pragma wskazówek), zobacz następujące zasoby w dokumentacji języka C#:

ASP.NET Core Module (ANCM)

Jeśli moduł ASP.NET Core Module (ANCM) nie był wybranym składnikiem, gdy program Visual Studio został zainstalowany lub czy wcześniejsza wersja narzędzia ANCM została zainstalowana w systemie, pobierz najnowszy Instalator pakietu hostingowego platformy .NET Core (pobieranie bezpośrednie) i uruchom instalatora. Aby uzyskać więcej informacji, zobacz Hosting Bundle (Pakiet hostingu).

Zmiana nazwy aplikacji

Na platformie .NET 6 WebApplicationBuilder normalizuje ścieżkę katalogu głównego zawartości, aby zakończyć ciąg .DirectorySeparatorChar Większość aplikacji migrowanych z HostBuilder lub WebHostBuilder nie ma takiej samej nazwy aplikacji, ponieważ nie są znormalizowane. Aby uzyskać więcej informacji, zobacz SetApplicationName

Dodatkowe zasoby

Przykłady kodu migrowane do nowego minimalnego modelu hostingu w wersji 6.0

Migrowanie z ASP.NET Core 5.0 do wersji 6.0

Wymagania wstępne

Aktualizowanie wersji zestawu .NET SDK w programie global.json

Aktualizowanie platformy docelowej

Aktualizowanie odwołań do pakietów

Nowy model hostingu

Aplikacje migrujące do wersji 6.0 lub nowszej nie muszą używać nowego minimalnego modelu hostingu

Korzystanie z uruchamiania z nowym minimalnym modelem hostingu

Różnice między modelami hostingu ASP.NET Core 5 i 6

Kompilowanie bibliotek dla platformy ASP.NET Core 6

Często zadawane pytania

Blazor

Migrowanie projektów SPA

Migrowanie aplikacji Angular z rozszerzeń SPA

Migrowanie aplikacji React z rozszerzeń SPA

Aktualizowanie obrazów platformy Docker

Zmiany w zestawie ASP.NET Core Razor SDK

Szablony projektów używają serwera Duende Identity Server

Przykłady kodu migrowane do ASP.NET Core 6.0

Przeglądanie zmian powodujących niezgodność

Typy referencyjne dopuszczane do wartości null (NRT) i statyczna analiza stanu null kompilatora platformy .NET

ASP.NET Core Module (ANCM)

Zmiana nazwy aplikacji

Dodatkowe zasoby

Opinia

Dodatkowe zasoby