Migrowanie z platformy ASP.NET Core na platformie .NET 5 do platformy .NET 6

W tym artykule wyjaśniono, jak zaktualizować istniejący projekt ASP.NET Core na platformie .NET 5 do platformy .NET 6. Aby uzyskać instrukcje dotyczące migracji z platformy ASP.NET Core 3.1 do platformy .NET 6, zobacz Migrowanie z platformy ASP.NET Core 3.1 do platformy .NET 6.

Wymagania wstępne

Program Visual Studio 2022 z obciążeniem tworzenia ASP.NET i aplikacji webowych.
SDK .NET 6

Zaktualizuj wersję zestawu .NET SDK w global.json

Jeśli korzystasz z global.json pliku przeznaczonego dla określonej wersji zestawu .NET SDK, zaktualizuj version właściwość do zainstalowanej wersji zestawu SDK platformy .NET 6. 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 `Microsoft.AspNetCore.*` każdego odwołania pakietu `Microsoft.Extensions.*` i `Version` do wersji 6.0.0 lub nowszej. 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 platformy .NET 6 nie muszą używać nowego minimalnego modelu hostingu. Aby uzyskać więcej informacji, zobacz Aplikacje migrujące do platformy .NET 6 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.
Łączy Startup.cs i Program.cs w jeden plik Program.cs.
Używa instrukcji najwyższego poziomu , aby zminimalizować kod wymagany dla aplikacji.
Używa dyrektyw globalnychusing, aby wyeliminować lub zminimalizować wymaganą liczbę wierszy instrukcjiusing.

Poniższy kod wyświetla pliki Startup.cs oraz Program.cs z szablonu aplikacji webowej .NET 5 (strony Razor) z usuniętymi nieużywanymi instrukcjami using.

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 programie ASP.NET Core na platformie .NET 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 na platformie .NET 6 pokazano, jak:

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

Szczegółowe przykłady migrowania ASP.NET Core w kodzie platformy .NET 5 Startup do platformy .NET 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 zadeklarowany jako typ odwołania dopuszczalny 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 Microsoft z wyjątkiem przestrzeni nazw Microsoft.AspNetCore. Na przykład Microsoft.EntityFrameworkCore jest teraz zapisywany 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 przyjmowania typów referencyjnych dopuszczających wartość null (NRT) i analizy stanu null kompilatora .NET, zobacz sekcję Typy referencyjne dopuszczające wartość null (NRT) i statyczna analiza stanu null kompilatora .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 platformy ASP.NET Core 3.1 i 5.0, jest w pełni obsługiwane.

Korzystaj 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 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 Configure elementu, usługa w Program.cs musi być ręcznie rozwiązana.

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 ten blok jest usuwany, if (env.IsDevelopment()) ponieważ w trybie deweloperskim oprogramowanie pośredniczące dla strony wyjątków dewelopera jest domyślnie włączone. Aby uzyskać więcej informacji, zobacz Różnice między platformą ASP.NET Core w modelach hostingu platformy .NET 5 i .NET 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 obejmuje cały potok oprogramowania pośredniczącego, więc nie ma potrzeby jawnego wywoływania UseRouting lub UseEndpoints w celu rejestrowania tras. UseRouting nadal można użyć do określenia, gdzie odbywa się dopasowywanie tras, ale UseRouting nie musi być jawnie wywoływana, jeśli trasy powinny być dopasowane na początku potoku oprogramowania pośredniczącego.

W poniższym kodzie wywołania UseRouting i UseEndpoints są usuwane z Startup. 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 i okresem istnienia wystąpień klasy Startup.
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 w .NET 5 i .NET 6

W trybie dewelopera oprogramowanie pośredniczące dla strony wyjątku dewelopera jest domyślnie włączone.
Nazwa aplikacji jest domyślnie nazwą zestawu punktu wejścia: Assembly.GetEntryAssembly().GetName().FullName. Podczas korzystania z WebApplicationBuilder w bibliotece, jawnie zmień nazwę aplikacji na nazwę zestawu biblioteki, aby umożliwić poprawne działanie odnajdywania części aplikacji MVC. 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 obsługuje cały potok oprogramowania pośredniczącego, dlatego nie ma potrzeby jawnych wywołań do UseRouting lub UseEndpoints rejestrowania tras. UseRouting nadal można użyć do określenia, gdzie odbywa się dopasowywanie tras, ale UseRouting nie musi być jawnie wywoływana, jeśli trasy powinny być dopasowane na początku potoku oprogramowania pośredniczącego.
Pipeline jest tworzony przed jakimkolwiek IStartupFilter uruchomieniem, dlatego wyjątki powstałe podczas budowania pipeline'u nie są widoczne dla IStartupFilter łańcucha wywołań.
Niektóre narzędzia, takie jak migracje EF, używają Program.CreateHostBuilder do uzyskania dostępu do aplikacji IServiceProvider, aby wykonywać logikę niestandardową 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.
W przeciwieństwie do klasy, minimalny host nie konfiguruje automatycznie zakresu DI podczas instancjowania dostawcy usług. W przypadkach, gdy wymagany jest zakres, należy wywołać IServiceScope używając IServiceScopeFactory.CreateScope, aby utworzyć nowy zakres. 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();

Klasy Startup nie można używać z WebApplicationBuilder.Host lub WebApplicationBuilder.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 na WebApplicationBuilder (WebApplicationBuilder.Host) nie odracza wykonywania metod ConfigureServices, ConfigureAppConfiguration lub ConfigureHostConfiguration. Nieodroczone wykonywanie umożliwia kodowi używającemu WebApplicationBuilder obserwowanie zmian wprowadzanych 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 builder.Host.ConfigureServices jest uruchamiane natychmiast, zamiast być odroczone do momentu wywołania builder.Build. Oznacza to, że Service1 zostaje dodane do IServiceCollection przed Service2 i powoduje, że Service1 zostaje rozwiązane dla IService.

Kompilowanie bibliotek dla platformy ASP.NET Core na platformie .NET 6

Istniejący ekosystem platformy .NET zbudował rozszerzalność wokół IServiceCollection, IHostBuilder oraz IWebHostBuilder. Te właściwości są dostępne na WebApplicationBuilder jako Services, Host i WebHost.

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

Oczekujemy, że autorzy bibliotek będą nadal tworzyć dla IHostBuilder, IWebHostBuilder, IApplicationBuilder i IEndpointRouteBuilder, opracowując składniki specyficzne dla 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.

Najczęściej zadawane pytania (FAQ)

Czy nowy minimalny model hostingu jest mniej zdolny?

Nie. Nowy model hostingu jest funkcjonalnie równoważny 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?

Nie. 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?

Nie. 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ę stosować instrukcje najwyższego poziomu?

Nie. 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 Program wygenerowanej 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 WebApplicationFactory i TestServer nadal działają?

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

Blazor

Po wykonaniu wskazówek we wcześniejszej sekcji tego artykułu, aby zaktualizować aplikację do platformy .NET 6, zastosuj określone funkcje, postępując zgodnie z linkami w temacie Co nowego w programie ASP.NET Core na platformie .NET 6.

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 platformy .NET 6.

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 zgłoszeniu na GitHubie

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 ASP.NET Core w środowisku uruchomieniowym platformy .NET 6. Rozważ następującą docker pull różnicę poleceń między platformą ASP.NET Core na platformie .NET 5 i .NET 6:

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

Zobacz problem na GitHub Breaking Change: domyślny format rejestratora konsoli ustawiony na JSON.

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 opierała się na docelach RazorGenerate i RazorCompile, aby wygenerować kod. 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 jest nadal stosowany do określania 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 AppName.Views.dll były publiczne. W .NET 6 typy aplikacji znajdują się w AppName.dll, ale są internal sealed. Aplikacje dokonujące wykrywania typu na AppName.Views.dll nie będą mogły wykrywać typu na 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.

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: Licencje.

Aby dowiedzieć się, jak używać usługi Microsoft Azure Active Directory dla platformy ASP.NET CoreIdentity, zobacz Identity (repozytorium dotnet/aspnetcore w usłudze 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 ze sklepami serwera Duende Identity.

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

Uwaga / Notatka

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

Przykłady kodu migrowane do platformy ASP.NET Core na platformie .NET 6

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

Zmiany przełomowe

Artykuły w artykule Zmiany powodujące niezgodność na platformie .NET umożliwiają znalezienie zmian powodujących niezgodność, które mogą być stosowane podczas uaktualniania aplikacji do nowszej wersji platformy .NET.

Aby uzyskać więcej informacji, zobacz Anonsy w repozytorium GitHub (aspnet/Announcements, 6.0.0 etykieta): zawiera informacje powodujące niezgodność i niezgodność.

Typy referencyjne mogące przyjmować wartość null (NRT) oraz statyczna analiza stanu null przez kompilator .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 na platformie .NET 6 (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ć ją znakiem 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

Sprzężenie zwrotne

Czy ta strona była pomocna?

Last updated on 2026-01-09