Nyheter i ASP.NET Core i .NET 5

Den här artikeln belyser de viktigaste ändringarna i ASP.NET Core i .NET 5 med länkar till relevant dokumentation.

ASP.NET Core MVC och Razor förbättringar

Modellbindning av DateTime som UTC

Modellbindningen stöder nu bindning av UTC-tidssträngar till DateTime. Om begäran innehåller en UTC-tidssträng binder modellbindningen den till en UTC DateTime. Följande tidssträng är till exempel bunden till UTC DateTime: https://example.com/mycontroller/myaction?time=2019-06-14T02%3A30%3A04.0576719Z

Modellbindning och validering med C# 9-rekordtyper

C# 9-posttyper kan användas med modellbindning i en MVC-styrenhet eller en Razor sida. Rekordtyper är ett bra sätt att ändamålsenligt representera data som överförs via nätverket.

Till exempel använder följande PersonController posttypen Person med modellbindning och formulärverifiering.

public record Person([Required] string Name, [Range(0, 150)] int Age);

public class PersonController
{
   public IActionResult Index() => View();

   [HttpPost]
   public IActionResult Index(Person person)
   {
          // ...
   }
}

Filen Person/Index.cshtml:

@model Person

<label>Name: <input asp-for="Model.Name" /></label>
<span asp-validation-for="Model.Name" />

<label>Age: <input asp-for="Model.Age" /></label>
<span asp-validation-for="Model.Age" />

Förbättringar av DynamicRouteValueTransformer

ASP.NET Core 3.1 introducerades DynamicRouteValueTransformer som ett sätt att använda anpassad slutpunkt för att dynamiskt välja en MVC-kontrollantåtgärd eller en Razor sida. .NET 5-appar kan skicka tillstånd till en DynamicRouteValueTransformer och filtrera den uppsättning slutpunkter som valts.

Miscellaneous

• Attributet [Jämför] kan tillämpas på egenskaper i en Razor sidmodell.
• Parametrar och egenskaper som är bundna från brödtexten anses som standard nödvändiga.

Webb-API

OpenAPI-specifikation på som standard

OpenAPI-specifikation är en branschstandard för att beskriva HTTP-API:er och integrera dem i komplexa affärsprocesser eller med tredje part. OpenAPI stöds i stor utsträckning av alla molnleverantörer och många API-register. Appar som genererar OpenAPI-dokument från webb-API:er har en mängd nya möjligheter där dessa API:er kan användas. I samarbete med underhållarna av projektet Swashbuckle.AspNetCore med öppen källkod innehåller mallen ASP.NET Core API ett NuGet-beroende av Swashbuckle. Swashbuckle är ett populärt NuGet-paket med öppen källkod som genererar OpenAPI-dokument dynamiskt. Swashbuckle gör detta genom att introspektera över API-kontrollanterna och generera OpenAPI-dokumentet vid körning eller vid byggtid med hjälp av Swashbuckle CLI.

I .NET 5 aktiverar webb-API-mallarna OpenAPI-stöd som standard. Så här inaktiverar du OpenAPI:

• Från kommandoraden:

    dotnet new webapi --no-openapi true
  

• Från Visual Studio: Avmarkera Aktivera OpenAPI-stöd.

Alla .csproj filer som skapats för webb-API-projekt innehåller nuget-paketreferensen Swashbuckle.AspNetCore .

<ItemGroup>
    <PackageReference Include="Swashbuckle.AspNetCore" Version="5.5.1" />
</ItemGroup>

Den mallgenererade koden innehåller kod i Startup.ConfigureServices som aktiverar OpenAPI-dokumentgenerering:

public void ConfigureServices(IServiceCollection services)
{

    services.AddControllers();
    services.AddSwaggerGen(c =>
    {
        c.SwaggerDoc("v1", new OpenApiInfo { Title = "WebApp1", Version = "v1" });
    });
}

Metoden Startup.Configure lägger till Swashbuckle-mellanprogrammet, vilket möjliggör följande:

• Dokumentgenereringsprocess.
• Swagger UI:s sida visas som standard i utvecklingsläge.

Den mallgenererade koden kommer inte av misstag att exponera API:ets beskrivning vid publicering till produktionsmiljön.

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
        app.UseSwagger();  // UseSwaggerUI Protected by if (env.IsDevelopment())
        app.UseSwaggerUI(c => c.SwaggerEndpoint("/swagger/v1/swagger.json",
                         "WebApp1 v1"));
    }

    app.UseHttpsRedirection();

    app.UseRouting();

    app.UseAuthorization();

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

Import av Azure API-hantering

När ASP.NET Core API-projekt aktiverar OpenAPI erbjuder Visual Studio 2019 version 16.8 eller senare publicering automatiskt ytterligare ett steg i publiceringsflödet. Utvecklare som använder Azure API Management har möjlighet att automatiskt importera API:erna till Azure API Management under publiceringsflödet:

Bättre startupplevelse för webb-API-projekt

Med OpenAPI aktiverat som standard förbättras appstartupplevelsen (F5) avsevärt för webb-API-utvecklare. Med .NET 5 är webb-API-mallen förkonfigurerad för att läsa in swagger-användargränssnittssidan. Sidan Swagger UI innehåller både dokumentationen som lagts till för det publicerade API:et och aktiverar testning av API:erna med ett enda klick.

Blazor

Prestandaförbättringar

För .NET 5 har vi gjort betydande förbättringar av .NET WebAssembly-körningsprestanda med särskilt fokus på komplex UI-rendering och JSON-serialisering. I våra prestandatester Blazor WebAssembly är i .NET 5 två till tre gånger snabbare för de flesta scenarier. Mer information finns i ASP.NET Blogg: ASP.NET Core-uppdateringar i .NET 5 Release Candidate 1.

CSS-isolering

Blazor har nu stöd för att definiera CSS-format som är begränsade till en viss komponent. Komponentspecifika CSS-format gör det enklare att resonera om formaten i en app och undvika oavsiktliga biverkningar av globala format. Mer information finns i ASP.NET Core Blazor CSS-isolering.

Ny InputFile komponent

Komponenten InputFile tillåter läsning av en eller flera filer som valts av en användare för uppladdning. Mer information finns i ASP.NET Core-filuppladdningarBlazor.

Nya InputRadio komponenter och InputRadioGroup komponenter

Blazor har inbyggda InputRadio och InputRadioGroup komponenter som underlättar databindning till grupper av alternativknappar med integrerad validering. Mer information hittar du i ASP.NET Core Blazor indatakomponenter.

Komponentvirtualisering

Förbättra den upplevda prestandan för komponentrendering med hjälp av Blazor ramverkets inbyggda virtualiseringsstöd. Mer information finns i ASP.NET Core Razor-komponentvirtualisering.

ontoggle händelsesupport

Blazor händelser stöder nu DOM-händelsen ontoggle . Mer information finns i ASP.NET Core Blazor händelsehantering.

Ange fokus för användargränssnittet i Blazor appar

FocusAsync Använd bekvämlighetsmetoden för elementreferenser för att ange användargränssnittets fokus till det elementet. Mer information finns i ASP.NET Core Blazor händelsehantering.

CSS-klassattribut för anpassad validering

CsS-klassattribut för anpassad validering är användbara när du integrerar med CSS-ramverk, till exempel Bootstrap. Mer information finns i ASP.NET Core Blazor formulärverifiering.

Stöd för IAsyncDisposable

Razor komponenter stöder nu IAsyncDisposable-gränssnittet för den asynkrona frisättningen av allokerade resurser.

JavaScript-isolering och objektreferenser

Blazor aktiverar JavaScript-isolering i JavaScript-standardmoduler. Mer information finns i Anropa JavaScript-funktioner från .NET-metoder i ASP.NET Core Blazor.

Formulärkomponenter stöder visningsnamn

Följande inbyggda komponenter stöder visningsnamn med parametern DisplayName :

• InputDate
• InputNumber
• InputSelect

Mer information finns i översikten över ASP.NET Core-formulärBlazor.

Allomfattande vägparametrar

Generella rutparametrar, som hanterar sökvägar över flera mappgränser, stöds i komponenter. Mer information finns i ASP.NET Core-routning Blazor och navigering.

Felsökningsförbättringar

Felsökning av Blazor WebAssembly appar har förbättrats i .NET 5. Dessutom stöds felsökning nu i Visual Studio för Mac. Mer information finns i Felsöka ASP.NET Core Blazor-appar.

Microsoft Identity v2.0 och MSAL v2.0

Blazor säkerhet använder nu Microsoft Identity v2.0 (Microsoft.Identity.Web och Microsoft.Identity.Web.UI) och MSAL v2.0. För mer information, se ämnena i Blazor Säkerhet och Identity noden.

Skyddad webbläsarlagring för Blazor Server

Blazor Server appar kan nu använda inbyggt stöd för att lagra apptillstånd i webbläsaren som har skyddats från manipulering med hjälp av ASP.NET Core-dataskydd. Data kan lagras i antingen lokal webbläsarlagring eller sessionslagring. Mer information finns i översikten över ASP.NET Core Blazor State Management och ASP.NET Core-tillståndshantering Blazor på serversidan.

Blazor WebAssembly förberäkning

Komponentintegrering har förbättrats mellan värdmodeller och Blazor WebAssembly appar kan nu förrendera utdata på servern.

Förbättringar av trimning/länkning

Blazor WebAssembly utför trimning/länkning av mellanliggande språk (IL) under en byggprocess för att trimma onödig IL-kod från appens utmatningssamlingar. Med lanseringen av .NET 5, utför Blazor WebAssembly förbättrad trimning med ytterligare konfigurationsalternativ. Mer information finns i Konfigurera Trimmer för ASP.NET Core Blazor - och Trimningsalternativ.

Kompatibilitetsanalys för webbläsare

Blazor WebAssembly appar riktar sig mot hela .NET API-ytan, men inte alla .NET-API:er stöds på WebAssembly på grund av webbläsarens sandbox-begränsningar. API:er som inte stöds genererar PlatformNotSupportedException när de körs på WebAssembly. En plattformskompatibilitetsanalys varnar utvecklaren när appen använder API:er som inte stöds av appens målplattformar. Mer information finns i Razor.

Lazy load-sammansättningar

Blazor WebAssembly Appstartprestanda kan förbättras genom att skjuta upp inläsningen av vissa programsammansättningar tills de krävs. Mer information finns i Lazy load assemblies in ASP.NET Core Blazor WebAssembly.

Stöd för globalisering har uppdaterats

Globaliseringsstöd är tillgängligt för Blazor WebAssembly baserat på Internationella komponenter för Unicode (ICU). Mer information finns i ASP.NET Core Blazor globalisering och lokalisering.

gRPC

Många prestandaförbättringar har gjorts i gRPC. Mer information finns i gRPC-prestandaförbättringar i .NET 5.

Mer gRPC-information finns i Översikt för gRPC på .NET.

SignalR

SignalR Hubbfilter

SignalR Hubbfilter, som kallas hubbpipelines i ASP.NET SignalR, är en funktion som gör att kod kan köras före och efter hubbmetoder anropas. Att köra kod före och efter hubbmetoder anropas liknar hur mellanprogram har möjlighet att köra kod före och efter en HTTP-begäran. Vanliga användningsområden är loggning, felhantering och argumentverifiering.

Mer information finns i Använda hubbfilter i ASP.NET Core SignalR.

SignalR parallell hubanrop

ASP.NET Core SignalR kan nu hantera parallella hubbanrop. Standardbeteendet kan ändras så att klienter kan anropa fler än en hubbmetod i taget:

public void ConfigureServices(IServiceCollection services)
{
    services.AddSignalR(options =>
    {
        options.MaximumParallelInvocationsPerClient = 5;
    });
}

Stöd för Messagepack har lagts till i SignalR Java-klienten

Ett nytt paket, com.microsoft.signalr.messagepack, lägger till MessagePack-stöd till SignalR Java-klienten. Om du vill använda protokollet MessagePack hub lägger du till .withHubProtocol(new MessagePackHubProtocol()) i anslutningsverktyget:

HubConnection hubConnection = HubConnectionBuilder.create(
                           "http://localhost:53353/MyHub")
               .withHubProtocol(new MessagePackHubProtocol())
               .build();

Kestrel

• Inläsningsbara slutpunkter via konfiguration: Kestrel kan identifiera ändringar i konfigurationen som skickas till KestrelServerOptions.Configure och ta bort bindning från befintliga slutpunkter och binda till nya slutpunkter utan att kräva en omstart av programmet när parametern reloadOnChange är true. Som standard när du använder ConfigureWebHostDefaults eller CreateDefaultBuilder, Kestrel binds till konfigurationsunderavsnittet "Kestrel" med reloadOnChange aktiverat. Appar måste skicka reloadOnChange: true när de anropar KestrelServerOptions.Configure manuellt för att få inläsningsbara slutpunkter.

• Förbättringar av HTTP/2-svarshuvuden. Mer information finns i Prestandaförbättringar i nästa avsnitt.

• Stöd för ytterligare slutpunktstyper i sockets-transporten: Om du lägger till det nya API:et som introducerades i System.Net.Socketstillåter sockets standardtransporten i Kestrel bindning till både befintliga filhandtag och Unix-domänsocketer. Stöd för bindning till befintliga filhandtag möjliggör användning av den befintliga Systemd integreringen utan att transporten libuv krävs.

• Anpassad dekodning av sidhuvuden i Kestrel: Appar kan ange vilken Encoding som ska användas för att tolka inkommande headers baserat på rubriknamnet istället för att använda UTF-8 som standard. Ange vilken Microsoft.AspNetCore.Server.Kestrel.KestrelServerOptions.RequestHeaderEncodingSelector kodning som ska användas för egenskapen:

  public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.ConfigureKestrel(options =>
            {
                options.RequestHeaderEncodingSelector = encoding =>
                {
                      return encoding switch
                      {
                          "Host" => System.Text.Encoding.Latin1,
                          _ => System.Text.Encoding.UTF8,
                      };
                };
            });
            webBuilder.UseStartup<Startup>();
        });
  

Kestrel slutpunktsspecifika alternativ via konfiguration

Stöd har lagts till för att Kestrelkonfigurera slutpunktsspecifika alternativ via konfiguration. De slutpunktsspecifika konfigurationerna innehåller:

• HTTP-protokoll som används
• TLS-protokoll som används
• Certifikatet har valts
• Klientcertifikatläge

Med konfigurationen kan du ange vilket certifikat som väljs baserat på det angivna servernamnet. Servernamnet är en del av SNI-tillägget (Server Name Indication) till TLS-protokollet som anges av klienten. KestrelKonfigurationen stöder också ett jokerteckenprefix i värdnamnet.

I följande exempel visas hur du anger slutpunktsspecifik med hjälp av en konfigurationsfil:

{
  "Kestrel": {
    "Endpoints": {
      "EndpointName": {
        "Url": "https://*",
        "Sni": {
          "a.example.org": {
            "Protocols": "Http1AndHttp2",
            "SslProtocols": [ "Tls11", "Tls12"],
            "Certificate": {
              "Path": "testCert.pfx",
              "Password": "testPassword"
            },
            "ClientCertificateMode" : "NoCertificate"
          },
          "*.example.org": {
            "Certificate": {
              "Path": "testCert2.pfx",
              "Password": "testPassword"
            }
          },
          "*": {
            // At least one sub-property needs to exist per
            // SNI section or it cannot be discovered via
            // IConfiguration
            "Protocols": "Http1",
          }
        }
      }
    }
  }
}

Servernamnindikering (SNI) är ett TLS-tillägg för att inkludera en virtuell domän som en del av SSL-förhandling. Det innebär i praktiken att det virtuella domännamnet, eller ett värdnamn, kan användas för att identifiera nätverksslutpunkten.

Prestandaförbättringar

HTTP/2

• Betydande minskningar av allokeringar i HTTP/2-kodvägen.

• Stöd för dynamisk HPack-komprimering av HTTP/2-svarshuvuden i Kestrel. Mer information finns i Rubriktabellstorlek och HPACK: den tysta mördaren (funktionen) i HTTP/2.

• Skicka HTTP/2 PING-ramar: HTTP/2 har en mekanism för att skicka PING-ramar för att säkerställa att en inaktiv anslutning fortfarande fungerar. Att säkerställa en livskraftig anslutning är särskilt användbart när du arbetar med långlivade strömmar som ofta är inaktiva men bara tillfälligt ser aktivitet, till exempel gRPC-strömmar. Appar kan skicka periodiska PING-ramar genom att Kestrel ange gränser för KestrelServerOptions.

  public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.ConfigureKestrel(options =>
            {
                options.Limits.Http2.KeepAlivePingInterval =
                                               TimeSpan.FromSeconds(10);
                options.Limits.Http2.KeepAlivePingTimeout =
                                               TimeSpan.FromSeconds(1);
            });
            webBuilder.UseStartup<Startup>();
        });
  

Containers

Innan .NET 5, skapa och publicera en Dockerfile för en ASP.NET Core-app krävs att du hämtar hela .NET Core SDK och ASP.NET Core-avbildningen. Med den här versionen minskas hämtning av bytes för SDK-avbildningar och bytes som hämtas för ASP.NET Core-avbildningen elimineras nästan helt. Mer information finns i den här GitHub-problemkommentären.

Autentisering och auktorisering

Microsoft Entra ID-autentisering med Microsoft.Identity. webb

De ASP.NET Core-projektmallarna integreras nu med Microsoft.Identity.Web för att hantera autentisering med Microsoft Entra-ID. Microsoft.Identity. Webbpaketet innehåller:

• En bättre upplevelse för autentisering via Microsoft Entra-ID.
• Ett enklare sätt att komma åt Azure-resurser på uppdrag av dina användare, inklusive Microsoft Graph. Se Microsoft.Identity. Webbexempel, som börjar med en enkel inloggning och avancerar via multitenans, använder Azure API:er, Microsoft Graph och skyddar dina egna API:er. Microsoft.Identity.Web är tillgängligt tillsammans med .NET 5.

Tillåt anonym åtkomst till en slutpunkt

Tilläggsmetoden AllowAnonymous tillåter anonym åtkomst till en slutpunkt:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    app.UseRouting();

    app.UseAuthentication();
    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapGet("/", async context =>
        {
            await context.Response.WriteAsync("Hello World!");
        })
        .AllowAnonymous();
    });
}

Anpassad hantering av auktoriseringsfel

Anpassad hantering av auktoriseringsfel är nu enklare med det nya IAuthorizationMiddlewareResultHandler gränssnittet som anropas av Authorization Middleware (UseAuthorization). Standardimplementeringen är densamma, men en anpassad hanterare kan registreras med beroendeinmatning, vilket tillåter anpassade HTTP-svar baserat på ett auktoriseringsfel. Se SampleAuthorizationMiddlewareResultHandler.cs (referenskälla) för en demonstration av IAuthorizationMiddlewareResultHandler.

Auktorisering vid användning av slutpunktsroutning

Auktorisering när du använder slutpunktsroutning tar nu emot HttpContext snarare än slutpunktsinstansen. Detta gör att mellanprogrammet för auktorisering kan komma åt RouteData och andra egenskaper för de HttpContext som inte var tillgängliga i Endpoint klassen. Slutpunkten kan hämtas från context med hjälp av context.GetEndpoint.

Rollbaserad åtkomstkontroll med Kerberos-autentisering och LDAP i Linux

Se Kerberos-autentisering och rollbaserad åtkomstkontroll (RBAC)

API-förbättringar

JSON-tilläggsmetoder för HttpRequest och HttpResponse

JSON-data kan läsas och skrivas till från en HttpRequest och HttpResponse med hjälp av de nya ReadFromJsonAsync metoderna och WriteAsJsonAsync tilläggsmetoderna. Dessa tilläggsmetoder använder System.Text.Json-serialiseraren för att hantera JSON-data. Den nya HasJsonContentType tilläggsmetoden kan också kontrollera om en begäran har en JSON-innehållstyp.

JSON-tilläggsmetoderna kan kombineras med slutpunktsroutning för att skapa JSON-API:er i ett programmeringsformat som vi anropar väg till kod. Det är ett nytt alternativ för utvecklare som vill skapa grundläggande JSON-API:er på ett enkelt sätt. Till exempel kan en webbapp som bara har en handfull slutpunkter välja att använda väg till kod i stället för de fullständiga funktionerna i ASP.NET Core MVC:

endpoints.MapGet("/weather/{city:alpha}", async context =>
{
    var city = (string)context.Request.RouteValues["city"];
    var weather = GetFromDatabase(city);

    await context.Response.WriteAsJsonAsync(weather);
});

System.Diagnostics.Activity

Standardformatet för System.Diagnostics.Activity är nu W3C-formatet som standard. Detta gör distribuerat spårningsstöd i ASP.NET Core interoperabelt med fler ramverk som standard.

FromBodyAttribute

FromBodyAttribute har nu stöd för att konfigurera ett alternativ som gör att dessa parametrar eller egenskaper kan betraktas som valfria:

public IActionResult Post([FromBody(EmptyBodyBehavior = EmptyBodyBehavior.Allow)]
                          MyModel model)
{
    ...
}

Diverse förbättringar

Vi har börjat tillämpa ogiltiga anteckningar på ASP.NET Core-sammansättningar. Vi planerar att kommentera det mesta av den gemensamma offentliga API-ytan i .NET 5-ramverket.

Kontrollera aktiveringen av startklassen

En ytterligare UseStartup överbelastning har lagts till som gör att en app kan tillhandahålla en fabriksmetod för att kontrollera aktivering av Startup klasser. Det är användbart att styra Startup klassaktiveringen för att skicka ytterligare parametrar till Startup som initieras tillsammans med värden:

public class Program
{
    public static async Task Main(string[] args)
    {
        var logger = CreateLogger();
        var host = Host.CreateDefaultBuilder()
            .ConfigureWebHost(builder =>
            {
                builder.UseStartup(context => new Startup(logger));
            })
            .Build();

        await host.RunAsync();
    }
}

Automatisk uppdatering med dotnet watch

I .NET 5 startar körning av dotnet watch på ett ASP.NET Core-projekt både standardwebbläsaren och uppdaterar webbläsaren automatiskt när ändringar görs i koden. Det innebär att du kan:

• Öppna ett ASP.NET Core-projekt i en textredigerare.
• Kör dotnet watch.
• Fokusera på kodändringarna medan verktygen hanterar återskapande, omstart och inläsning av appen igen.

Formatterare för konsolloggar

Förbättringar har gjorts för konsolloggprovidern i Microsoft.Extensions.Logging biblioteket. Utvecklare kan nu implementera en anpassad ConsoleFormatter för att utöva fullständig kontroll över formatering och färgläggning av konsolutdata. Formaterings-API:erna tillåter omfattande formatering genom att implementera en delmängd av VT-100-escape-sekvenserna. VT-100 stöds av de flesta moderna terminaler. Konsolloggaren kan parsa ut escape-sekvenser på terminaler som inte stöds så att utvecklare kan skapa en enda formatering för alla terminaler.

Konsolloggare för JSON

Förutom stöd för anpassade formateringar har vi även lagt till en inbyggd JSON-formaterare som genererar strukturerade JSON-loggar till konsolen. Följande kod visar hur du växlar från standardloggaren till JSON:

public static IHostBuilder CreateHostBuilder(string[] args) =>
           Host.CreateDefaultBuilder(args)
  .ConfigureLogging(logging =>
  {
     logging.AddJsonConsole(options =>
     {
         options.JsonWriterOptions = new JsonWriterOptions()
         { Indented = true };
     });
  })
  .ConfigureWebHostDefaults(webBuilder =>
  {
    webBuilder.UseStartup<Startup>();
  });

Loggmeddelanden som skickas till konsolen är JSON-formaterade:

{
  "EventId": 0,
  "LogLevel": "Information",
  "Category": "Microsoft.Hosting.Lifetime",
  "Message": "Now listening on: https://localhost:5001",
  "State": {
    "Message": "Now listening on: https://localhost:5001",
    "address": "https://localhost:5001",
    "{OriginalFormat}": "Now listening on: {address}"
  }
}

Brytande förändringar

Använd artiklarna i Icke-bakåtkompatibla ändringar i .NET för att hitta icke-bakåtkompatibla ändringar som kan gälla när du uppgraderar en app till en nyare version av .NET.