Modifiche di rilievo di ASP.NET Core per le versioni 3.0 e 3.1

  • Articolo

ASP.NET Core fornisce le funzionalità di sviluppo di app Web usate da .NET Core.

Selezionare uno dei collegamenti seguenti per le modifiche che causano un'interruzione in una versione specifica:

Le modifiche di rilievo seguenti in ASP.NET Core 3.0 e 3.1 sono documentate in questa pagina:

ASP.NET Core 3.1

HTTP: Le modifiche dello stesso sito browser influiscono sull'autenticazione

Alcuni browser, ad esempio Chrome e Firefox, hanno apportato modifiche di rilievo alle loro implementazioni di SameSite per i cookie. Le modifiche influiscono sugli scenari di autenticazione remota, ad esempio OpenID Connect e WS-Federation, che devono rifiutare esplicitamente inviando SameSite=None. Tuttavia, SameSite=None si interrompe in iOS 12 e in alcune versioni precedenti di altri browser. L'app deve eseguire l'analisi di queste versioni e omettere SameSite.

Per informazioni su questo problema, vedere dotnet/aspnetcore#14996.

Versione introdotta

3.1 Preview 1

Comportamento precedente

SameSite è una bozza di estensione standard 2016 per i cookie HTTP. È progettato per attenuare la richiesta cross-site forgery (CSRF). Originariamente progettato come funzionalità, i server potrebbero acconsentire esplicitamente aggiungendo i nuovi parametri. ASP.NET Core 2.0 ha aggiunto il supporto iniziale per SameSite.

Nuovo comportamento

Google ha proposto un nuovo standard bozza che non è compatibile con le versioni precedenti. Lo standard modifica la modalità predefinita in Lax e aggiunge una nuova voce None per rifiutare esplicitamente. Lax è sufficiente per la maggior parte dei cookie dell'app. Tuttavia, interrompe gli scenari tra siti, ad esempio OpenID Connect e l'account di accesso WS-Federation. La maggior parte degli account di accesso OAuth non è interessata a causa delle differenze nel flusso della richiesta. Il nuovo parametro None causa problemi di compatibilità con i client che hanno implementato la bozza dello standard precedente (ad esempio, iOS 12). Chrome 80 includerà le modifiche. Vedere Aggiornamenti SameSite per la sequenza temporale di avvio del prodotto Chrome.

ASP.NET Core 3.1 è stato aggiornato per implementare il nuovo comportamento di SameSite. L'aggiornamento ridefinisce il comportamento di SameSiteMode.None per generare SameSite=None e aggiunge un nuovo valore SameSiteMode.Unspecified per omettere l'attributo SameSite. Tutte le API dei cookie sono ora predefinite su Unspecified, anche se alcuni componenti che usano i valori impostati dai cookie sono più specifici per i relativi scenari, ad esempio la correlazione OpenID Connect e i cookie nonce.

Per altre modifiche recenti in questa area, vedere HTTP: Alcune impostazioni predefinite di SameSite cookie sono state modificate in Nessuno. In ASP.NET Core 3.0, la maggior parte delle impostazioni predefinite è stata modificata da SameSiteMode.Lax a SameSiteMode.None (ma usando ancora lo standard precedente).

Motivo della modifica

Modifiche del browser e delle specifiche, come descritto nel testo precedente.

Le app che interagiscono con siti remoti, ad esempio tramite un account di accesso di terze parti, devono:

  • Testare questi scenari in più browser.
  • Applicare la mitigazione dell'analisi del browser dei criteri dei cookie descritta in Supporto di browser meno recenti.

Per istruzioni su test e analisi del browser, vedere la sezione seguente.

Determinare se si è interessati

Testare l'app Web usando una versione client che può acconsentire esplicitamente al nuovo comportamento. Chrome, Firefox e Microsoft Edge Chromium hanno tutti nuovi flag di funzionalità di consenso esplicito che possono essere usati per i test. Verificare che l'app sia compatibile con le versioni client precedenti dopo aver applicato le patch, in particolare Safari. Per altre informazioni, vedere Supporto di browser meno recenti.

Chrome

Chrome 78 e versioni successive producono risultati di test fuorvianti. Queste versioni hanno una mitigazione temporanea sul posto e consentono i cookie meno di due minuti prima. Con i flag di test appropriati abilitati, Chrome 76 e 77 producono risultati più accurati. Per testare il nuovo comportamento, impostare chrome://flags/#same-site-by-default-cookies su abilitato. È stato segnalato che Chrome 75 e versioni precedenti non funzionano con la nuova None impostazione. Per altre informazioni, vedere Supporto di browser meno recenti.

Google non rende disponibili le versioni precedenti di Chrome. È tuttavia possibile scaricare le versioni precedenti di Chromium, che sarà sufficiente per i test. Seguire le istruzioni in Scaricare Chromium.

Safari

Safari 12 ha implementato rigorosamente la bozza precedente e ha esito negativo se vede il nuovo valore None nei cookie. Questa operazione deve essere evitata tramite il codice di analisi del browser visualizzato in Supporto di browser meno recenti. Assicurarsi di testare Safari 12 e 13, nonché gli account di accesso basati su WebKit in stile sistema operativo usando Microsoft Authentication Library (MSAL), Active Directory Authentication Library (ADAL) o qualsiasi libreria in uso. Il problema dipende dalla versione del sistema operativo sottostante. OSX Mojave 10.14 e iOS 12 sono noti per avere problemi di compatibilità con il nuovo comportamento. L'aggiornamento a OSX Catalina 10.15 o iOS 13 risolve il problema. Safari non dispone attualmente di un flag di consenso esplicito per testare il nuovo comportamento di specifica.

Firefox

Il supporto di Firefox per il nuovo standard può essere testato nella versione 68 e successive acconsentire esplicitamente alla pagina about:config con il flag di funzionalità network.cookie.sameSite.laxByDefault. Non sono stati segnalati problemi di compatibilità sulle versioni precedenti di Firefox.

Microsoft Edge

Anche se Microsoft Edge supporta il vecchio standard SameSite, a partire dalla versione 44 non ha avuto problemi di compatibilità con il nuovo standard.

Microsoft Edge Chromium

Il flag di funzionalità è edge://flags/#same-site-by-default-cookies. Non sono stati rilevati problemi di compatibilità durante i test con Microsoft Edge Chromium 78.

Electron

Le versioni di Electron includono versioni precedenti di Chromium. Ad esempio, la versione di Electron usata da Microsoft Teams è Chromium 66, che mostra il comportamento precedente. Eseguire test di compatibilità personalizzati con la versione di Electron usata dal prodotto. Per altre informazioni, vedere Supporto di browser meno recenti.

Supportare browser meno recenti

Lo standard SameSite 2016 imponeva che i valori sconosciuti venissero considerati come valori SameSite=Strict. Di conseguenza, tutti i browser meno recenti che supportano lo standard originale si possono interrompere quando visualizzano una proprietà SameSite con un valore di None. Le app Web devono implementare l'analisi del browser se intendono supportare questi vecchi browser. ASP.NET Core non implementa l'analisi del browser perché i valori di intestazione della richiesta User-Agent sono altamente instabili e cambiano su base settimanale. Al contrario, un punto di estensione nei criteri cookie consente di aggiungere logica specifica per User-Agent.

In Startup.cs aggiungere le istruzioni seguenti:

private void CheckSameSite(HttpContext httpContext, CookieOptions options)
{
    if (options.SameSite == SameSiteMode.None)
    {
        var userAgent = httpContext.Request.Headers["User-Agent"].ToString();
        // TODO: Use your User Agent library of choice here.
        if (/* UserAgent doesn't support new behavior */)
        {
            options.SameSite = SameSiteMode.Unspecified;
        }
    }
}

public void ConfigureServices(IServiceCollection services)
{
    services.Configure<CookiePolicyOptions>(options =>
    {
        options.MinimumSameSitePolicy = SameSiteMode.Unspecified;
        options.OnAppendCookie = cookieContext =>
            CheckSameSite(cookieContext.Context, cookieContext.CookieOptions);
        options.OnDeleteCookie = cookieContext =>
            CheckSameSite(cookieContext.Context, cookieContext.CookieOptions);
    });
}

public void Configure(IApplicationBuilder app)
{
    // Before UseAuthentication or anything else that writes cookies.
    app.UseCookiePolicy();

    app.UseAuthentication();
    // code omitted for brevity
}
Opzioni di rifiuto esplicito

L'opzione di compatibilità Microsoft.AspNetCore.SuppressSameSiteNone consente di rifiutare temporaneamente il nuovo comportamento dei cookie di ASP.NET Core. Aggiungere il codice JSON seguente a un file runtimeconfig.template.json nel progetto:

{
  "configProperties": {
    "Microsoft.AspNetCore.SuppressSameSiteNone": "true"
  }
}
Altre versioni

Le patch correlate SameSite sono disponibili per:

  • ASP.NET Core 2.1, 2.2 e 3.0
  • Microsoft.Owin 4.1
  • System.Web (per .NET Framework 4.7.2 e versioni successive)

Category

ASP.NET

API interessate

ASP.NET Core 3.0

API obsolete antifalsificazione, CORS, di diagnostica, MVC e di routing rimosse

Le opzioni di compatibilità e i membri obsoleti in ASP.NET Core 2.2 sono stati rimossi.

Versione introdotta

3,0

Motivo della modifica

Miglioramento della superficie dell'API nel tempo.

Quando la destinazione è .NET Core 2.2, seguire le indicazioni contenute nei messaggi di compilazione obsoleti per adottare invece le nuove API.

Category

ASP.NET Core

API interessate

I tipi e i membri seguenti sono stati contrassegnati come obsoleti per ASP.NET Core 2.1 e 2.2:

Tipi

  • Microsoft.AspNetCore.Diagnostics.Views.WelcomePage
  • Microsoft.AspNetCore.DiagnosticsViewPage.Views.AttributeValue
  • Microsoft.AspNetCore.DiagnosticsViewPage.Views.BaseView
  • Microsoft.AspNetCore.DiagnosticsViewPage.Views.HelperResult
  • Microsoft.AspNetCore.Mvc.Formatters.Xml.ProblemDetails21Wrapper
  • Microsoft.AspNetCore.Mvc.Formatters.Xml.ValidationProblemDetails21Wrapper
  • Microsoft.AspNetCore.Mvc.Razor.Compilation.ViewsFeatureProvider
  • Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.PageArgumentBinder
  • Microsoft.AspNetCore.Routing.IRouteValuesAddressMetadata
  • Microsoft.AspNetCore.Routing.RouteValuesAddressMetadata

Costruttori

  • Microsoft.AspNetCore.Cors.Infrastructure.CorsService(IOptions{CorsOptions})
  • Microsoft.AspNetCore.Routing.Tree.TreeRouteBuilder(ILoggerFactory,UrlEncoder,ObjectPool{UriBuildingContext},IInlineConstraintResolver)
  • Microsoft.AspNetCore.Mvc.Formatters.OutputFormatterCanWriteContext
  • Microsoft.AspNetCore.Mvc.ApiExplorer.DefaultApiDescriptionProvider(IOptions{MvcOptions},IInlineConstraintResolver,IModelMetadataProvider)
  • Microsoft.AspNetCore.Mvc.ApiExplorer.DefaultApiDescriptionProvider(IOptions{MvcOptions},IInlineConstraintResolver,IModelMetadataProvider,IActionResultTypeMapper)
  • Microsoft.AspNetCore.Mvc.Formatters.FormatFilter(IOptions{MvcOptions})
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.ArrayModelBinder`1(IModelBinder)
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.ByteArrayModelBinder
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.CollectionModelBinder`1(IModelBinder)
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.ComplexTypeModelBinder(IDictionary`2)
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.DictionaryModelBinder`2(IModelBinder,IModelBinder)
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.DoubleModelBinder(System.Globalization.NumberStyles)
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.FloatModelBinder(System.Globalization.NumberStyles)
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.FormCollectionModelBinder
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.FormFileModelBinder
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.HeaderModelBinder
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.KeyValuePairModelBinder`2(IModelBinder,IModelBinder)
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.SimpleTypeModelBinder(System.Type)
  • Microsoft.AspNetCore.Mvc.ModelBinding.ModelAttributes(IEnumerable{System.Object})
  • Microsoft.AspNetCore.Mvc.ModelBinding.ModelAttributes(IEnumerable{System.Object},IEnumerable{System.Object})
  • Microsoft.AspNetCore.Mvc.ModelBinding.ModelBinderFactory(IModelMetadataProvider,IOptions{MvcOptions})
  • Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder(IModelMetadataProvider,IModelBinderFactory,IObjectModelValidator)
  • Microsoft.AspNetCore.Mvc.Routing.KnownRouteValueConstraint()
  • Microsoft.AspNetCore.Mvc.Formatters.XmlDataContractSerializerInputFormatter
  • Microsoft.AspNetCore.Mvc.Formatters.XmlDataContractSerializerInputFormatter(System.Boolean)
  • Microsoft.AspNetCore.Mvc.Formatters.XmlDataContractSerializerInputFormatter(MvcOptions)
  • Microsoft.AspNetCore.Mvc.Formatters.XmlSerializerInputFormatter
  • Microsoft.AspNetCore.Mvc.Formatters.XmlSerializerInputFormatter(System.Boolean)
  • Microsoft.AspNetCore.Mvc.Formatters.XmlSerializerInputFormatter(MvcOptions)
  • Microsoft.AspNetCore.Mvc.TagHelpers.ImageTagHelper(IHostingEnvironment,IMemoryCache,HtmlEncoder,IUrlHelperFactory)
  • Microsoft.AspNetCore.Mvc.TagHelpers.LinkTagHelper(IHostingEnvironment,IMemoryCache,HtmlEncoder,JavaScriptEncoder,IUrlHelperFactory)
  • Microsoft.AspNetCore.Mvc.TagHelpers.ScriptTagHelper(IHostingEnvironment,IMemoryCache,HtmlEncoder,JavaScriptEncoder,IUrlHelperFactory)
  • Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.RazorPageAdapter(RazorPageBase)

Proprietà

  • Microsoft.AspNetCore.Antiforgery.AntiforgeryOptions.CookieDomain
  • Microsoft.AspNetCore.Antiforgery.AntiforgeryOptions.CookieName
  • Microsoft.AspNetCore.Antiforgery.AntiforgeryOptions.CookiePath
  • Microsoft.AspNetCore.Antiforgery.AntiforgeryOptions.RequireSsl
  • Microsoft.AspNetCore.Mvc.ApiBehaviorOptions.AllowInferringBindingSourceForCollectionTypesAsFromQuery
  • Microsoft.AspNetCore.Mvc.ApiBehaviorOptions.SuppressUseValidationProblemDetailsForInvalidModelStateResponses
  • Microsoft.AspNetCore.Mvc.CookieTempDataProviderOptions.CookieName
  • Microsoft.AspNetCore.Mvc.CookieTempDataProviderOptions.Domain
  • Microsoft.AspNetCore.Mvc.CookieTempDataProviderOptions.Path
  • Microsoft.AspNetCore.Mvc.DataAnnotations.MvcDataAnnotationsLocalizationOptions.AllowDataAnnotationsLocalizationForEnumDisplayAttributes
  • Microsoft.AspNetCore.Mvc.Formatters.Xml.MvcXmlOptions.AllowRfc7807CompliantProblemDetailsFormat
  • Microsoft.AspNetCore.Mvc.MvcOptions.AllowBindingHeaderValuesToNonStringModelTypes
  • Microsoft.AspNetCore.Mvc.MvcOptions.AllowCombiningAuthorizeFilters
  • Microsoft.AspNetCore.Mvc.MvcOptions.AllowShortCircuitingValidationWhenNoValidatorsArePresent
  • Microsoft.AspNetCore.Mvc.MvcOptions.AllowValidatingTopLevelNodes
  • Microsoft.AspNetCore.Mvc.MvcOptions.InputFormatterExceptionPolicy
  • Microsoft.AspNetCore.Mvc.MvcOptions.SuppressBindingUndefinedValueToEnumType
  • Microsoft.AspNetCore.Mvc.MvcViewOptions.AllowRenderingMaxLengthAttribute
  • Microsoft.AspNetCore.Mvc.MvcViewOptions.SuppressTempDataAttributePrefix
  • Microsoft.AspNetCore.Mvc.RazorPages.RazorPagesOptions.AllowAreas
  • Microsoft.AspNetCore.Mvc.RazorPages.RazorPagesOptions.AllowDefaultHandlingForOptionsRequests
  • Microsoft.AspNetCore.Mvc.RazorPages.RazorPagesOptions.AllowMappingHeadRequestsToGetHandler

Metodi

Autenticazione: Google+ deprecato e sostituito

Google ha iniziato a disattivare il sistema Accesso a Google+ per le app il 28 gennaio 2019.

Descrizione delle modifiche

ASP.NET 4.x e ASP.NET Core usavano le API di Accesso a Google+ per autenticare gli utenti degli account Google nelle app Web. I pacchetti NuGet interessati sono Microsoft.AspNetCore.Authentication.Google per ASP.NET Core e Microsoft.Owin.Security.Google per Microsoft.Owin con Web Forms ASP.NET e MVC.

Le API di sostituzione di Google usano un'origine dati e un formato differenti. Le mitigazioni e le soluzioni fornite di seguito tengono conto delle modifiche strutturali. Le app devono verificare che i dati continuino a soddisfare i requisiti. Ad esempio, nomi, indirizzi e-mail, collegamenti al profilo e foto del profilo possono fornire valori leggermente diversi rispetto a prima.

Versione introdotta

tutte le versioni. Questa modifica è esterna a ASP.NET Core.

Owin con Web Forms ASP.NET e MVC

Per Microsoft.Owin 3.1.0 e versioni successive, una mitigazione temporanea è illustrata qui. Le app devono completare i test con la mitigazione per rilevare le eventuali modifiche nel formato dei dati. È in programma il rilascio di Microsoft.Owin 4.0.1 con un aggiornamento. Le app che usano qualsiasi versione precedente devono essere aggiornate alla versione 4.0.1.

ASP.NET Core 1.x

La mitigazione in Owin con Web Forms ASP.NET e MVC può essere adattata ad ASP.NET Core 1.x. Non sono previste patch del pacchetto NuGet, perché 1.x ha raggiunto lo stato di fine del ciclo di vita.

ASP.NET Core 2.x

Per Microsoft.AspNetCore.Authentication.Google versione 2.x, sostituire la chiamata esistente a AddGoogle in Startup.ConfigureServices con il codice seguente:

.AddGoogle(o =>
{
    o.ClientId = Configuration["Authentication:Google:ClientId"];
    o.ClientSecret = Configuration["Authentication:Google:ClientSecret"];
    o.UserInformationEndpoint = "https://www.googleapis.com/oauth2/v2/userinfo";
    o.ClaimActions.Clear();
    o.ClaimActions.MapJsonKey(ClaimTypes.NameIdentifier, "id");
    o.ClaimActions.MapJsonKey(ClaimTypes.Name, "name");
    o.ClaimActions.MapJsonKey(ClaimTypes.GivenName, "given_name");
    o.ClaimActions.MapJsonKey(ClaimTypes.Surname, "family_name");
    o.ClaimActions.MapJsonKey("urn:google:profile", "link");
    o.ClaimActions.MapJsonKey(ClaimTypes.Email, "email");
});

Le patch di febbraio delle versioni 2.1 e 2.2 incorporavano la riconfigurazione precedente come nuova impostazione predefinita. Non è prevista alcuna patch per ASP.NET Core 2.0 perché ha raggiunto la fine del ciclo di vita.

ASP.NET Core 3.0

La mitigazione fornita per ASP.NET Core 2.x può essere usata anche per ASP.NET Core 3.0. Nelle prossime anteprime della versione 3.0, il pacchetto Microsoft.AspNetCore.Authentication.Google potrebbe essere rimosso. Gli utenti verrebbero reindirizzati a Microsoft.AspNetCore.Authentication.OpenIdConnect. Il codice seguente mostra come sostituire AddGoogle con AddOpenIdConnect in Startup.ConfigureServices. Questa sostituzione può essere usata con ASP.NET Core 2.0 e versioni successive e può essere adattata per ASP.NET Core 1.x in base alle esigenze.

.AddOpenIdConnect("Google", o =>
{
    o.ClientId = Configuration["Authentication:Google:ClientId"];
    o.ClientSecret = Configuration["Authentication:Google:ClientSecret"];
    o.Authority = "https://accounts.google.com";
    o.ResponseType = OpenIdConnectResponseType.Code;
    o.CallbackPath = "/signin-google"; // Or register the default "/signin-oidc"
    o.Scope.Add("email");
});
JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear();

Category

ASP.NET Core

API interessate

Microsoft.AspNetCore.Authentication.Google

Autenticazione: proprietà HttpContext.Authentication rimossa

La proprietà deprecata Authentication in HttpContext è stata rimossa.

Descrizione delle modifiche

Come parte di dotnet/aspnetcore#6504, la proprietà deprecata Authentication in HttpContext è stata rimossa. La proprietà Authentication è stata deprecata a partire dalla versione 2.0. È stata pubblicata una guida alla migrazione per eseguire la migrazione del codice che usa questa proprietà deprecata alle nuove API sostitutive. Le rimanenti classi/API inutilizzate correlate al vecchio stack di autenticazione ASP.NET Core 1.x sono state rimosse nel commit dotnet/aspnetcore@d7a7c65.

Per informazioni, vedere dotnet/aspnetcore#6533.

Versione introdotta

3,0

Motivo della modifica

Le API ASP.NET Core 1.0 sono state sostituite da metodi di estensione in Microsoft.AspNetCore.Authentication.AuthenticationHttpContextExtensions.

Vedere la guida alla migrazione.

Category

ASP.NET Core

API interessate

Autenticazione: tipi Newtonsoft.Json sostituiti

In ASP.NET Core 3.0, i tipi Newtonsoft.Json usati nelle API di autenticazione sono stati sostituiti con tipi System.Text.Json. Tranne che nei casi seguenti, l'utilizzo di base dei pacchetti di autenticazione rimane invariato:

  • Classi derivate da provider OAuth, ad esempio quelle di aspnet-contrib.
  • Implementazioni avanzate di manipolazione delle attestazioni.

Per altre informazioni, vedere dotnet/aspnetcore#7105. Per informazioni, vedere dotnet/aspnetcore#7289.

Versione introdotta

3,0

Per le implementazioni OAuth derivate, la modifica più comune consiste nel sostituire JObject.Parse con JsonDocument.Parse nell'override CreateTicketAsync, come illustrato qui. JsonDocument implementa IDisposable.

L'elenco seguente illustra le modifiche note:

Category

ASP.NET Core

API interessate

Autenticazione: firma di OAuthHandler.ExchangeCodeAsync modificata

In ASP.NET Core 3.0 la firma di OAuthHandler.ExchangeCodeAsync è stata modificata da:

protected virtual System.Threading.Tasks.Task<Microsoft.AspNetCore.Authentication.OAuth.OAuthTokenResponse> ExchangeCodeAsync(string code, string redirectUri) { throw null; }

Con:

protected virtual System.Threading.Tasks.Task<Microsoft.AspNetCore.Authentication.OAuth.OAuthTokenResponse> ExchangeCodeAsync(Microsoft.AspNetCore.Authentication.OAuth.OAuthCodeExchangeContext context) { throw null; }

Versione introdotta

3,0

Comportamento precedente

Le stringhe code e redirectUri venivano passate come argomenti separati.

Nuovo comportamento

Code e RedirectUri sono proprietà di OAuthCodeExchangeContext che è possibile impostare tramite il costruttore OAuthCodeExchangeContext. Il nuovo tipo di OAuthCodeExchangeContext è l'unico argomento passato a OAuthHandler.ExchangeCodeAsync.

Motivo della modifica

Questa modifica consente di specificare parametri aggiuntivi senza causare interruzioni. Non è necessario creare nuovi overload di ExchangeCodeAsync.

Costruire un elemento OAuthCodeExchangeContext con i valori code e redirectUri appropriati. È necessario specificare un'istanza di AuthenticationProperties. È possibile passare a OAuthHandler.ExchangeCodeAsync questa singola istanza di OAuthCodeExchangeContext anziché più argomenti.

Category

ASP.NET Core

API interessate

OAuthHandler<TOptions>.ExchangeCodeAsync(String, String)

Autorizzazione: overload di AddAuthorization spostato in un assembly diverso

I metodi principali AddAuthorization presenti in genere in Microsoft.AspNetCore.Authorization sono stati rinominati in AddAuthorizationCore. I metodi AddAuthorization precedenti esistono ancora, ma si trovano nell'assembly Microsoft.AspNetCore.Authorization.Policy. Le app che usano entrambi i metodi non dovrebbero subire conseguenze. Si noti che Microsoft.AspNetCore.Authorization.Policy ora viene fornito nel framework condiviso anziché in un pacchetto autonomo, come descritto in Framework condiviso: assembly rimossi da Microsoft.AspNetCore.App.

Versione introdotta

3,0

Comportamento precedente

I metodi AddAuthorization esistevano in Microsoft.AspNetCore.Authorization.

Nuovo comportamento

I metodi AddAuthorization esistono in Microsoft.AspNetCore.Authorization.Policy. AddAuthorizationCore è il nuovo nome dei metodi precedenti.

Motivo della modifica

AddAuthorization è un nome di metodo migliore per l'aggiunta di tutti i servizi comuni necessari per l'autorizzazione.

Aggiungere un riferimento a Microsoft.AspNetCore.Authorization.Policy o usare AddAuthorizationCore.

Category

ASP.NET Core

API interessate

Microsoft.Extensions.DependencyInjection.AuthorizationServiceCollectionExtensions.AddAuthorization(IServiceCollection, Action<AuthorizationOptions>)

Autorizzazione: IAllowAnonymous rimosso da AuthorizationFilterContext.Filters

A partire da ASP.NET Core 3.0, MVC non aggiunge AllowAnonymousFilters per gli attributi [AllowAnonymous] individuati nei controller e nei metodi di azione. Questa modifica viene risolta in locale per i derivati di AuthorizeAttribute, ma si tratta di una modifica che causa un'interruzione per le implementazioni di IAsyncAuthorizationFilter e IAuthorizationFilter. Tali implementazioni, incapsulate in un attributo [TypeFilter] sono un modo diffuso e supportato per ottenere un'autorizzazione basata su attributi fortemente tipizzati quando sono necessari sia la configurazione che l'inserimento delle dipendenze.

Versione introdotta

3,0

Comportamento precedente

IAllowAnonymous compariva nella raccolta AuthorizationFilterContext.Filters. Testare la presenza dell'interfaccia era un approccio valido per eseguire l'override o disabilitare il filtro su singoli metodi del controller.

Nuovo comportamento

IAllowAnonymous non compare più nella raccolta AuthorizationFilterContext.Filters. Le implementazioni di IAsyncAuthorizationFilter dipendenti dal comportamento precedente causano a intermittenza risposte HTTP 401 (accesso non autorizzato) o HTTP 403 (accesso negato).

Motivo della modifica

In ASP.NET Core 3.0 è stata introdotta una nuova strategia di routing degli endpoint.

Cercare i metadati dell'endpoint per IAllowAnonymous. Ad esempio:

var endpoint = context.HttpContext.GetEndpoint();
if (endpoint?.Metadata?.GetMetadata<IAllowAnonymous>() != null)
{
}

Un esempio di questa tecnica si può osservare in questo metodo HasAllowAnonymous.

Category

ASP.NET Core

API interessate

None

Autorizzazione: le implementazioni di IAuthorizationPolicyProvider richiedono un nuovo metodo

In ASP.NET Core 3.0, un nuovo metodo GetFallbackPolicyAsync è stato aggiunto a IAuthorizationPolicyProvider. Questo criterio di fallback viene usato dal middleware di autorizzazione quando non è specificato alcun criterio.

Per altre informazioni, vedere dotnet/aspnetcore#9759.

Versione introdotta

3,0

Comportamento precedente

Le implementazioni di IAuthorizationPolicyProvider non richiedevano un metodo GetFallbackPolicyAsync.

Nuovo comportamento

Le implementazioni di IAuthorizationPolicyProvider richiedono un metodo GetFallbackPolicyAsync.

Motivo della modifica

Per il nuovo AuthorizationMiddleware era necessario un nuovo metodo da usare quando non è specificato alcun criterio.

Aggiungere il metodo GetFallbackPolicyAsync alle implementazioni di IAuthorizationPolicyProvider.

Category

ASP.NET Core

API interessate

Microsoft.AspNetCore.Authorization.IAuthorizationPolicyProvider

Memorizzazione nella cache: proprietà CompactOnMemoryPressure rimossa

Nella versione ASP.NET Core 3.0 sono state rimosse le API MemoryCacheOptions obsolete.

Descrizione delle modifiche

Questa modifica è una conseguenza di aspnet/Caching#221. Per informazioni, vedere dotnet/extensions#1062.

Versione introdotta

3,0

Comportamento precedente

Era disponibile la proprietà MemoryCacheOptions.CompactOnMemoryPressure.

Nuovo comportamento

La proprietà MemoryCacheOptions.CompactOnMemoryPressure è stata rimossa.

Motivo della modifica

La compattazione automatica della cache provocava problemi. Per evitare comportamenti imprevisti, la cache deve essere compattata solo quando è necessario.

Per compattare la cache, eseguire il downcast a MemoryCache e chiamare Compact quando necessario.

Category

ASP.NET Core

API interessate

MemoryCacheOptions.CompactOnMemoryPressure

Memorizzazione nella cache: Microsoft.Extensions.Caching.SqlServer usa un nuovo pacchetto SqlClient

Il pacchetto Microsoft.Extensions.Caching.SqlServer userà il nuovo pacchetto Microsoft.Data.SqlClient anziché il pacchetto System.Data.SqlClient. Questa modifica potrebbe causare modifiche che causano un'interruzione di lieve entità. Per altre informazioni, vedere la presentazione del nuovo Microsoft.Data.SqlClient.

Versione introdotta

3,0

Comportamento precedente

Il pacchetto Microsoft.Extensions.Caching.SqlServer usava il pacchetto System.Data.SqlClient.

Nuovo comportamento

Ora Microsoft.Extensions.Caching.SqlServer usa il pacchetto Microsoft.Data.SqlClient.

Motivo della modifica

Microsoft.Data.SqlClient è un nuovo pacchetto basato su System.Data.SqlClient. È qui che da ora in poi verrà svolto tutto il lavoro delle nuove funzionalità.

I clienti non devono preoccuparsi di questa modifica che causa un'interruzione, a meno che non usino tipi restituiti dal pacchetto Microsoft.Extensions.Caching.SqlServer e ne eseguano il cast a tipi System.Data.SqlClient. Ad esempio, se si eseguiva il cast di un elemento DbConnection al vecchio tipo SqlConnection, è necessario modificare il cast nel nuovo tipo Microsoft.Data.SqlClient.SqlConnection.

Category

ASP.NET Core

API interessate

None

Memorizzazione nella cache: tipi "pubternal" di ResponseCaching modificati in tipi interni

In ASP.NET Core 3.0 i tipi "pubternal" in ResponseCaching sono stati modificati in internal.

Inoltre, le implementazioni predefinite di IResponseCachingPolicyProvider e IResponseCachingKeyProvider non vengono più aggiunte ai servizi come parte del metodo AddResponseCaching.

Descrizione delle modifiche

In ASP.NET Core i tipi "pubternal" vengono dichiarati come public, ma risiedono in uno spazio dei nomi con il suffisso .Internal. Sebbene questi tipi siano pubblici, non hanno criteri di supporto e sono soggetti a modifiche che causano un'interruzione. Sfortunatamente, l'uso accidentale di questi tipi è stato frequente, dando luogo a modifiche che causano interruzioni in questi progetti e limitando la capacità di gestire il framework.

Versione introdotta

3,0

Comportamento precedente

Questi tipi erano visibili pubblicamente, ma non supportati.

Nuovo comportamento

Ora questi tipi sono internal.

Motivo della modifica

L'ambito internal è più idoneo per l'assenza di criteri di supporto.

Copiare i tipi usati dalla propria app o libreria.

Category

ASP.NET Core

API interessate

Protezione dei dati: DataProtection.Blobs usa nuove API di Archiviazione di Azure

Azure.Extensions.AspNetCore.DataProtection.Blobs dipende dalle librerie di Archiviazione di Azure. In queste librerie sono stati rinominati gli assembly, i pacchetti e gli spazi dei nomi. A partire da ASP.NET Core 3.0, Azure.Extensions.AspNetCore.DataProtection.Blobs usa i nuovi pacchetti e le nuove API con prefisso Azure.Storage..

Per domande sulle API di Archiviazione di Azure, usare https://github.com/Azure/azure-storage-net. Per informazioni su questo problema, vedere dotnet/aspnetcore#19570.

Versione introdotta

3,0

Comportamento precedente

Il pacchetto faceva riferimento al pacchetto NuGet WindowsAzure.Storage. Il pacchetto fa riferimento al pacchetto NuGet Microsoft.Azure.Storage.Blob.

Nuovo comportamento

Il pacchetto fa riferimento al pacchetto NuGet Azure.Storage.Blob.

Motivo della modifica

Questa modifica consente a Azure.Extensions.AspNetCore.DataProtection.Blobs di eseguire la migrazione ai pacchetti di Archiviazione di Azure consigliati.

Se è ancora necessario usare le API di Archiviazione di Azure precedenti con ASP.NET Core 3.0, aggiungere una dipendenza diretta al pacchetto WindowsAzure.Storage o Microsoft.Azure.Storage. Questo pacchetto può essere installato insieme alle nuove API Azure.Storage.

In molti casi, l'aggiornamento implica solo la modifica delle istruzioni using in modo da usare i nuovi spazi dei nomi:

- using Microsoft.WindowsAzure.Storage;
- using Microsoft.WindowsAzure.Storage.Blob;
- using Microsoft.Azure.Storage;
- using Microsoft.Azure.Storage.Blob;
+ using Azure.Storage;
+ using Azure.Storage.Blobs;

Category

ASP.NET Core

API interessate

None

Hosting: AspNetCoreModule V1 rimosso dal bundle di hosting Windows

A partire da ASP.NET Core 3.0, il bundle di hosting Windows non conterrà AspNetCoreModule (ANCM) V1.

ANCM V2 è compatibile con le versioni precedenti di ANCM OutOfProcess ed è consigliato per l'uso con le app ASP.NET Core 3.0.

Per informazioni, vedere dotnet/aspnetcore#7095.

Versione introdotta

3,0

Comportamento precedente

ANCM V1 è incluso nel bundle di hosting Windows.

Nuovo comportamento

ANCM V1 non è incluso nel bundle di hosting Windows.

Motivo della modifica

ANCM V2 è compatibile con le versioni precedenti di ANCM OutOfProcess ed è consigliato per l'uso con le app ASP.NET Core 3.0.

Usare ANCM V2 con le app ASP.NET Core 3.0.

Se è necessario ANCM V1, può essere installato usando il bundle di hosting Windows per ASP.NET Core 2.1 o 2.2.

Questa modifica interromperà il funzionamento delle app ASP.NET Core 3.0 che:

  • Hanno acconsentito esplicitamente all'uso di ANCM V1 con <AspNetCoreModuleName>AspNetCoreModule</AspNetCoreModuleName>.
  • Hanno un file web.config personalizzato con <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />.

Category

ASP.NET Core

API interessate

None

Hosting: l'host generico limita l'inserimento del costruttore Startup

Gli unici tipi supportati dall'host generico per l'inserimento del costruttore di classe Startup sono IHostEnvironment, IWebHostEnvironment e IConfiguration. Le app che usano WebHost non sono interessate.

Descrizione delle modifiche

Prima di ASP.NET Core 3.0, era possibile usare l'inserimento del costruttore per i tipi arbitrari nel costruttore della classe Startup. In ASP.NET Core 3.0, lo stack Web è stato migrato alla libreria host generica. La modifica è visibile nel file Program.cs dei modelli:

ASP.NET Core 2.x:

https://github.com/dotnet/aspnetcore/blob/5cb615fcbe8559e49042e93394008077e30454c0/src/Templating/src/Microsoft.DotNet.Web.ProjectTemplates/content/EmptyWeb-CSharp/Program.cs#L20-L22

ASP.NET Core 3.0:

https://github.com/dotnet/aspnetcore/blob/b1ca2c1155da3920f0df5108b9fedbe82efaa11c/src/ProjectTemplates/Web.ProjectTemplates/content/EmptyWeb-CSharp/Program.cs#L19-L24

Host usa un contenitore di inserimento delle dipendenze (DI) per compilare l'app. WebHost usa due contenitori, uno per l'host e uno per l'app. Di conseguenza, il costruttore Startup non supporta più l'inserimento di servizi personalizzati. È possibile inserire solo IHostEnvironment, IWebHostEnvironment e IConfiguration. Questa modifica evita i problemi di inserimento delle dipendenze, ad esempio la creazione duplicata di un servizio singleton.

Versione introdotta

3,0

Motivo della modifica

Questa modifica è una conseguenza della conversione della piattaforma dello stack Web nella libreria host generica.

Inserire i servizi nella firma del metodo Startup.Configure. Ad esempio:

public void Configure(IApplicationBuilder app, IOptions<MyOptions> options)

Category

ASP.NET Core

API interessate

None

Hosting: reindirizzamento HTTPS abilitato per le app IIS out-of-process

La versione 13.0.19218.0 del modulo ASP.NET Core (ANCM) per l'hosting tramite IIS out-of-process abilita una funzionalità di reindirizzamento HTTPS esistente per le app ASP.NET Core 3.0 e 2.2.

Per informazioni, vedere dotnet/AspNetCore#15243.

Versione introdotta

3,0

Comportamento precedente

Il modello di progetto ASP.NET Core 2.1 ha introdotto per la prima volta il supporto per i metodi middleware HTTPS come UseHttpsRedirection e UseHsts. Per abilitare il reindirizzamento HTTPS era necessaria l'aggiunta della configurazione, poiché le app in fase di sviluppo non usano la porta predefinita 443. HTTP Strict Transport Security (HSTS) è attivo solo se la richiesta usa già HTTPS. Localhost viene ignorato per impostazione predefinita.

Nuovo comportamento

In ASP.NET Core 3.0, lo scenario HTTPS di IIS è stato migliorato. Con il miglioramento, un'app poteva individuare le porte HTTPS del server e far funzionare UseHttpsRedirection per impostazione predefinita. Il componente in-process eseguiva l'individuazione delle porte con la funzionalità IServerAddresses; questo influisce solo sulle app ASP.NET Core 3.0 perché la libreria in-process ha la stessa versione del framework. Il componente out-of-process è stato modificato in modo da aggiungere automaticamente la variabile di ambiente ASPNETCORE_HTTPS_PORT. Questa modifica aveva effetto sulle app ASP.NET Core 2.2 e 3.0, perché il componente out-of-process è condiviso a livello globale. Le app ASP.NET Core 2.1 non sono interessate perché usano una versione precedente di ANCM per impostazione predefinita.

In ASP.NET Core 3.0.1 e 3.1.0 Preview 3 il comportamento precedente è stato modificato in modo da annullare le modifiche funzionali apportate in ASP.NET Core 2.x. Queste modifiche influiscono solo sulle app IIS out-of-process.

Come descritto in precedenza, l'installazione di ASP.NET Core 3.0.0 aveva come effetto collaterale anche l'attivazione del middleware UseHttpsRedirection nelle app ASP.NET Core 2.x. In ASP.NET Core 3.0.1 e 3.1.0 Preview 3 è stata apportata una modifica ad ANCM in modo che l'installazione non abbia più questo effetto sulle app ASP.NET Core 2.x. La variabile di ambiente ASPNETCORE_HTTPS_PORT popolata da ANCM in ASP.NET Core 3.0.0 è stata modificata in ASPNETCORE_ANCM_HTTPS_PORT nelle versioni ASP.NET Core 3.0.1 e 3.1.0 Preview 3. In queste versioni è stato aggiornato anche UseHttpsRedirection per comprendere sia le nuove variabili che quelle precedenti. ASP.NET Core 2.x non verrà aggiornato. Di conseguenza, ripristina il comportamento precedente di essere disabilitato per impostazione predefinita.

Motivo della modifica

Miglioramento della funzionalità di ASP.NET Core 3.0.

Se si vuole che tutti i client usino HTTPS, non è necessario alcun intervento. Per consentire ad alcuni client di usare HTTP, eseguire una delle operazioni seguenti:

  • Rimuovere le chiamate a UseHttpsRedirection e UseHsts dal metodo Startup.Configure del progetto e ridistribuire l'app.

  • Nel file web.config impostare la variabile di ambiente ASPNETCORE_HTTPS_PORT su una stringa vuota. Questa modifica può essere apportata direttamente nel server senza ridistribuire l'app. Ad esempio:

    <aspNetCore processPath="dotnet" arguments=".\WebApplication3.dll" stdoutLogEnabled="false" stdoutLogFile="\\?\%home%\LogFiles\stdout" >
    <environmentVariables>
    <environmentVariable name="ASPNETCORE_HTTPS_PORT" value="" />
    </environmentVariables>
</aspNetCore>

UseHttpsRedirection può essere ancora:

  • Attivato manualmente in ASP.NET Core 2.x impostando la variabile di ambiente ASPNETCORE_HTTPS_PORT sul numero di porta appropriato, che nella maggior parte degli scenari di produzione è 443.
  • Disattivato in ASP.NET Core 3.x definendo ASPNETCORE_ANCM_HTTPS_PORT con un valore stringa vuoto. Questo valore si imposta nello stesso modo dell'esempio ASPNETCORE_HTTPS_PORT precedente.

I computer che eseguono app ASP.NET Core 3.0.0 devono installare il runtime ASP.NET Core 3.0.1 prima di installare il modulo ANCM di ASP.NET Core 3.1.0 Preview 3. Questo garantisce che UseHttpsRedirection continui a funzionare come previsto per le app ASP.NET Core 3.0.

In Servizio app di Azure, ANCM viene distribuito separatamente rispetto al runtime a causa della sua natura globale. ANCM è stato distribuito in Azure con queste modifiche dopo la distribuzione di ASP.NET Core 3.0.1 e 3.1.0.

Category

ASP.NET Core

API interessate

HttpsPolicyBuilderExtensions.UseHttpsRedirection(IApplicationBuilder)

Hosting: tipi IHostingEnvironment e IApplicationLifetime sostituiti

Sono stati introdotti nuovi tipi per sostituire i tipi IHostingEnvironment e IApplicationLifetime esistenti.

Versione introdotta

3,0

Comportamento precedente

Esistevano due tipi IHostingEnvironment e IApplicationLifetime diversi provenienti da Microsoft.Extensions.Hosting e Microsoft.AspNetCore.Hosting.

Nuovo comportamento

I tipi precedenti sono stati contrassegnati come obsoleti e sostituiti con nuovi tipi.

Motivo della modifica

Quando Microsoft.Extensions.Hosting è stato introdotto in ASP.NET Core 2.1, alcuni tipi come IHostingEnvironment e IApplicationLifetime sono stati copiati da Microsoft.AspNetCore.Hosting. A seguito di alcune modifiche di ASP.NET Core 3.0, le app includono entrambi gli spazi dei nomi Microsoft.Extensions.Hosting e Microsoft.AspNetCore.Hosting. Qualsiasi uso di questi tipi duplicati causa un errore del compilatore "riferimento ambiguo" quando viene fatto riferimento a entrambi gli spazi dei nomi.

Sostituire tutti gli utilizzi dei tipi precedenti con i nuovi tipi introdotti, come indicato di seguito:

Tipi obsoleti (avviso):

Nuovi tipi:

I nuovi metodi di estensione IHostEnvironmentIsDevelopment e IsProduction si trovano nello spazio dei nomi Microsoft.Extensions.Hosting. Può essere necessario aggiungere tale spazio dei nomi al progetto.

Category

ASP.NET Core

API interessate

Hosting: ObjectPoolProvider rimosso dalle dipendenze di WebHostBuilder

Per rendere ASP.NET Core più efficiente, ObjectPoolProvider è stato rimosso dal set di dipendenze principale. Ora gli specifici componenti che si basano su ObjectPoolProvider vengono aggiunti automaticamente.

Per informazioni, vedere dotnet/aspnetcore#5944.

Versione introdotta

3,0

Comportamento precedente

WebHostBuilder fornisce ObjectPoolProvider per impostazione predefinita nel contenitore di inserimento delle dipendenze.

Nuovo comportamento

WebHostBuilder non fornisce più ObjectPoolProvider per impostazione predefinita nel contenitore di inserimento delle dipendenze.

Motivo della modifica

Questa modifica è stata apportata per rendere ASP.NET Core più efficiente.

Se il componente richiede ObjectPoolProvider, va aggiunto alle dipendenze tramite IServiceCollection.

Category

ASP.NET Core

API interessate

None

HTTP: estendibilità di DefaultHttpContext rimossa

Nell'ambito dei miglioramenti delle prestazioni di ASP.NET Core 3.0, l'estendibilità di DefaultHttpContext è stata rimossa. La classe è ora sealed. Per altre informazioni, vedere dotnet/aspnetcore#6504.

Se gli unit test usano Mock<DefaultHttpContext>, usare Mock<HttpContext> o new DefaultHttpContext().

Per informazioni, vedere dotnet/aspnetcore#6534.

Versione introdotta

3,0

Comportamento precedente

Le classi possono derivare da DefaultHttpContext.

Nuovo comportamento

Le classi non possono derivare da DefaultHttpContext.

Motivo della modifica

Inizialmente, l'estendibilità è stata fornita per consentire il pooling di HttpContext, ma ha introdotto una complessità non necessaria e ha impedito altre ottimizzazioni.

Se si usa Mock<DefaultHttpContext> negli unit test, iniziare a usare Mock<HttpContext>.

Category

ASP.NET Core

API interessate

Microsoft.AspNetCore.Http.DefaultHttpContext

HTTP: costanti HeaderNames modificate in statiche di sola lettura

A partire da ASP.NET Core 3.0 Preview 5, i campi in Microsoft.Net.Http.Headers.HeaderNames sono passati da const a static readonly.

Per informazioni, vedere dotnet/aspnetcore#9514.

Versione introdotta

3,0

Comportamento precedente

Questi campi erano const.

Nuovo comportamento

Ora questi campi sono static readonly.

Motivo della modifica

La modifica:

  • Impedisce che i valori vengano incorporati tra limiti di assembly, consentendo la correzione dei valori in base alle esigenze.
  • Permette di eseguire controlli di uguaglianza dei riferimenti più veloci.

Ricompilare per la versione 3.0. Il codice sorgente che usa questi campi nei modi seguenti non può più farlo:

  • Come argomento di un attributo
  • Come case in un'istruzione switch
  • Quando si definisce un altro valore const

Per ovviare a questa modifica che causa un'interruzione, passare all'uso di costanti del nome di intestazione autodefinite o valori letterali stringa.

Category

ASP.NET Core

API interessate

Microsoft.Net.Http.Headers.HeaderNames

HTTP: modifiche all'infrastruttura del corpo della risposta

L'infrastruttura che supporta il corpo della risposta HTTP è stata modificata. Se si usa HttpResponse direttamente, non è necessario apportare modifiche al codice. Continuare a leggere se si esegue il wrapping o la sostituzione di HttpResponse.Body o si accede a HttpContext.Features.

Versione introdotta

3,0

Comportamento precedente

Al corpo della risposta HTTP erano associate tre API:

  • IHttpResponseFeature.Body
  • IHttpSendFileFeature.SendFileAsync
  • IHttpBufferingFeature.DisableResponseBuffering

Nuovo comportamento

Se si sostituisce HttpResponse.Body, sostituisce l'intera interfaccia IHttpResponseBodyFeature con un wrapper intorno al flusso specificato, usando StreamResponseBodyFeature per fornire implementazioni predefinite per tutte le API previste. Il ripristino del flusso originale annulla questa modifica.

Motivo della modifica

La motivazione è combinare le API del corpo della risposta in un'unica nuova interfaccia di funzionalità.

Usare IHttpResponseBodyFeature dove in precedenza si usava IHttpResponseFeature.Body, IHttpSendFileFeature o IHttpBufferingFeature.

Category

ASP.NET Core

API interessate

SameSite è un'opzione per i cookie utile per mitigare alcuni attacchi di richiesta intersito falsa. Quando questa opzione è stata introdotta per la prima volta, nelle varie API ASP.NET Core sono state usate impostazioni predefinite incoerenti. Questa incoerenza ha generato risultati confusi. A partire da ASP.NET Core 3.0, queste impostazioni predefinite sono più allineate. È necessario acconsentire esplicitamente a questa funzionalità per ogni singolo componente.

Versione introdotta

3,0

Comportamento precedente

API ASP.NET Core simili usavano valori predefiniti di SameSiteMode diversi. Un esempio di questa incoerenza compare in HttpResponse.Cookies.Append(String, String) e HttpResponse.Cookies.Append(String, String, CookieOptions), che usavano rispettivamente i valori predefiniti SameSiteMode.None e SameSiteMode.Lax.

Nuovo comportamento

Tutte le API interessate usano per impostazione predefinita SameSiteMode.None.

Motivo della modifica

Il valore predefinito è stato modificato per rendere SameSite una funzionalità che prevede il consenso esplicito.

Ogni componente che genera cookie deve decidere se SameSite è appropriato per i propri scenari. Esaminare l'utilizzo delle API interessate e riconfigurare SameSite in base alle esigenze.

Category

ASP.NET Core

API interessate

HTTP: I/O sincrono disabilitato in tutti i server

A partire da ASP.NET Core 3.0, le operazioni server sincrone sono disabilitate per impostazione predefinita.

Descrizione delle modifiche

AllowSynchronousIO è un'opzione presente in ogni server che abilita o disabilita le API di I/O sincrone come HttpRequest.Body.Read, HttpResponse.Body.Write e Stream.Flush. Queste API sono state a lungo la causa di blocchi delle app e mancanza di risorse dei thread. A partire da ASP.NET Core 3.0 Preview 3, queste operazioni sincrone sono disabilitate per impostazione predefinita.

Server interessati:

  • Kestrel
  • HttpSys
  • IIS in-process
  • TestServer

Si prevedono errori simili a:

  • Synchronous operations are disallowed. Call ReadAsync or set AllowSynchronousIO to true instead.
  • Synchronous operations are disallowed. Call WriteAsync or set AllowSynchronousIO to true instead.
  • Synchronous operations are disallowed. Call FlushAsync or set AllowSynchronousIO to true instead.

Ogni server ha un'opzione AllowSynchronousIO che controlla questo comportamento e il valore predefiniti per tutti i server è ora false.

Come mitigazione temporanea, il comportamento può anche essere sottoposto a override in base a singole richieste. Ad esempio:

var syncIOFeature = HttpContext.Features.Get<IHttpBodyControlFeature>();
if (syncIOFeature != null)
{
    syncIOFeature.AllowSynchronousIO = true;
}

Se si verificano problemi con un elemento TextWriter o un altro flusso che chiama un'API sincrona in Dispose, chiamare invece la nuova API DisposeAsync.

Per informazioni, vedere dotnet/aspnetcore#7644.

Versione introdotta

3,0

Comportamento precedente

Le API HttpRequest.Body.Read, HttpResponse.Body.Write e Stream.Flush erano consentite per impostazione predefinita.

Nuovo comportamento

Queste API sincrone non sono consentite per impostazione predefinita:

Si prevedono errori simili a:

  • Synchronous operations are disallowed. Call ReadAsync or set AllowSynchronousIO to true instead.
  • Synchronous operations are disallowed. Call WriteAsync or set AllowSynchronousIO to true instead.
  • Synchronous operations are disallowed. Call FlushAsync or set AllowSynchronousIO to true instead.

Motivo della modifica

Queste API sincrone sono state a lungo la causa di blocchi delle app e mancanza di risorse dei thread. A partire da ASP.NET Core 3.0 Preview 3, le operazioni sincrone sono disabilitate per impostazione predefinita.

Usare le versioni asincrone dei metodi. Come mitigazione temporanea, il comportamento può anche essere sottoposto a override in base a singole richieste.

var syncIOFeature = HttpContext.Features.Get<IHttpBodyControlFeature>();
if (syncIOFeature != null)
{
    syncIOFeature.AllowSynchronousIO = true;
}

Category

ASP.NET Core

API interessate

Identity: overload del metodo AddDefaultUI rimosso

A partire da ASP.NET Core 3.0, l'overload del metodo IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework) non esiste più.

Versione introdotta

3,0

Motivo della modifica

Questa modifica è stata il risultato dell'adozione della funzionalità degli asset Web statici.

Chiamare IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder) anziché l'overload che accetta due argomenti. Se si usa Bootstrap 3, aggiungere anche la riga seguente a un elemento <PropertyGroup> nel file di progetto:

<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>

Category

ASP.NET Core

API interessate

IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework)

Identity: versione predefinita di Bootstrap dell'interfaccia utente modificata

A partire da ASP.NET Core 3.0, l'interfaccia utente di Identity usa per impostazione predefinita la versione 4 di Bootstrap.

Versione introdotta

3,0

Comportamento precedente

La chiamata al metodo services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(); equivaleva a services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap3);

Nuovo comportamento

La chiamata al metodo services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(); equivale a services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap4);

Motivo della modifica

Bootstrap 4 è stato rilasciato durante il periodo di ASP.NET Core 3.0.

Si è interessati da questa modifica se si usa l'interfaccia utente predefinita di Identity e la si è aggiunta in Startup.ConfigureServices, come illustrato nell'esempio seguente:

services.AddDefaultIdentity<IdentityUser>().AddDefaultUI();

Effettua una delle seguenti azioni:

  • Eseguire la migrazione dell'app all'uso di Bootstrap 4 usando la guida alla migrazione.

  • Aggiornare Startup.ConfigureServices in modo da imporre l'utilizzo di Bootstrap 3. Ad esempio:

    services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap3);

Category

ASP.NET Core

API interessate

None

Identity: SignInAsync genera un'eccezione per l'identità non autenticata

Per impostazione predefinita, SignInAsync genera un'eccezione per le entità di sicurezza/identità in cui IsAuthenticated è false.

Versione introdotta

3,0

Comportamento precedente

SignInAsync accetta qualsiasi entità di sicurezza/identità, incluse le identità in cui IsAuthenticated è false.

Nuovo comportamento

Per impostazione predefinita, SignInAsync genera un'eccezione per le entità di sicurezza/identità in cui IsAuthenticated è false. È disponibile un nuovo flag per eliminare questo comportamento, ma il comportamento predefinito è cambiato.

Motivo della modifica

Il comportamento precedente causava problemi perché, per impostazione predefinita, queste entità erano rifiutate da [Authorize] / RequireAuthenticatedUser().

In ASP.NET Core 3.0 Preview 6 c'è un flag RequireAuthenticatedSignIn in AuthenticationOptions che per impostazione predefinita è true. Impostare questo flag su false per ripristinare il comportamento precedente.

Category

ASP.NET Core

API interessate

None

Identity: il costruttore SignInManager accetta un nuovo parametro

A partire da ASP.NET Core 3.0, al costruttore SignInManager è stato aggiunto un nuovo parametro IUserConfirmation<TUser>. Per altre informazioni, vedere dotnet/aspnetcore#8356.

Versione introdotta

3,0

Motivo della modifica

Il motivo della modifica è stato l'aggiunta del supporto per i nuovi flussi di posta elettronica/conferma in Identity.

Se si costruisce manualmente un elemento SignInManager, fornire un'implementazione di IUserConfirmation o recuperarne una da fornire dall'inserimento delle dipendenze.

Category

ASP.NET Core

API interessate

SignInManager<TUser>

Identity: l'interfaccia utente usa la funzionalità degli asset Web statici

In ASP.NET Core 3.0 è stata introdotta una funzionalità di asset Web statici e l'interfaccia utente di Identity l'ha adottata.

Descrizione delle modifiche

In seguito all'adozione della funzionalità degli asset Web statici nell'interfaccia utente di Identity:

  • La selezione del framework viene eseguita usando la proprietà IdentityUIFrameworkVersion nel file di progetto.
  • Bootstrap 4 è il framework di interfaccia utente predefinito per l'interfaccia utente di Identity. Bootstrap 3 ha raggiunto la fine del ciclo di vita ed è consigliabile eseguire la migrazione a una versione supportata.

Versione introdotta

3,0

Comportamento precedente

Il framework di interfaccia utente predefinito per l'interfaccia utente di Identity era Bootstrap 3. Si poteva configurare il framework di interfaccia utente usando un parametro per la chiamata al metodo AddDefaultUI in Startup.ConfigureServices.

Nuovo comportamento

Il framework di interfaccia utente predefinito per l'interfaccia utente di Identity è Bootstrap 4. Il framework di interfaccia utente deve essere configurato nel file di progetto anziché nella chiamata al metodo AddDefaultUI.

Motivo della modifica

L'adozione della funzionalità degli asset Web statici richiedeva che la configurazione del framework di interfaccia utente passasse a MSBuild. La decisione su quale framework incorporare è una decisione da prendere in fase di compilazione, non in fase di runtime.

Esaminare l'interfaccia utente del sito per assicurarsi che i nuovi componenti Bootstrap 4 siano compatibili. Se necessario, usare la proprietà IdentityUIFrameworkVersion di MSBuild per ripristinare Bootstrap 3. Aggiungere la proprietà a un elemento <PropertyGroup> nel file di progetto:

<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>

Category

ASP.NET Core

API interessate

IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder, UIFramework)

Kestrel: adapter di connessione rimossi

Nell'ambito della modifica delle API "pubternal" in public, il concetto di IConnectionAdapter è stato rimosso da Kestrel. Gli adapter di connessione sono stati sostituiti dal middleware di connessione (simile al middleware HTTP nella pipeline di ASP.NET Core, ma per le connessioni di livello inferiore). La registrazione delle connessioni e HTTPS sono stati spostati dagli adapter di connessione al middleware di connessione. Questi metodi di estensione dovrebbero continuare a funzionare senza problemi, ma i dettagli di implementazione sono cambiati.

Per altre informazioni, vedere dotnet/aspnetcore#11412. Per informazioni, vedere dotnet/aspnetcore#11475.

Versione introdotta

3,0

Comportamento precedente

I componenti di estendibilità di Kestrel erano creati usando IConnectionAdapter.

Nuovo comportamento

I componenti di estendibilità di Kestrel vengono creati come middleware.

Motivo della modifica

Questa modifica ha lo scopo di offrire un'architettura di estendibilità più flessibile.

Convertire tutte le implementazioni di IConnectionAdapter all'uso del nuovo modello middleware, come illustrato qui.

Category

ASP.NET Core

API interessate

Microsoft.AspNetCore.Server.Kestrel.Core.Adapter.Internal.IConnectionAdapter

Kestrel: assembly HTTPS vuoto rimosso

L'assembly Microsoft.AspNetCore.Server.Kestrel.Https è stato rimosso.

Versione introdotta

3,0

Motivo della modifica

In ASP.NET Core 2.1, il contenuto di Microsoft.AspNetCore.Server.Kestrel.Https è stato spostato in Microsoft.AspNetCore.Server.Kestrel.Core. Questa modifica è stata eseguita in una modalità che non causa interruzioni usando attributi [TypeForwardedTo].

  • Le librerie che fanno riferimento a Microsoft.AspNetCore.Server.Kestrel.Https 2.0 devono aggiornare tutte le dipendenze di ASP.NET Core alla versione 2.1 o successiva. In caso contrario, possono bloccarsi quando vengono caricate in un'app ASP.NET Core 3.0.
  • Le app e le librerie destinate ad ASP.NET Core 2.1 e versioni successive devono rimuovere qualunque riferimento diretto al pacchetto NuGet Microsoft.AspNetCore.Server.Kestrel.Https.

Category

ASP.NET Core

API interessate

None

Kestrel: intestazioni Trailer della richiesta spostate in una nuova raccolta

Nelle versioni precedenti, Kestrel aggiungeva intestazioni Trailer in blocchi HTTP/1.1 nella raccolta delle intestazioni delle richieste quando il corpo della richiesta veniva letto in corrispondenza della fine. Questo comportamento causava preoccupazioni sull'ambiguità tra intestazioni e trailer. È stata presa la decisione di spostare i trailer in una nuova raccolta.

I trailer delle richieste HTTP/2 non erano disponibili in ASP.NET Core 2.2, ma ora sono disponibili in questa nuova raccolta in ASP.NET Core 3.0.

Sono stati aggiunti nuovi metodi di estensione della richiesta per accedere a questi trailer.

I trailer HTTP/1.1 sono disponibili dopo la lettura dell'intero corpo della richiesta.

I trailer HTTP/2 sono disponibili una volta ricevuti dal client. Il client non invierà i trailer finché l'intero corpo della richiesta non è stato almeno memorizzato nel buffer dal server. Può essere necessario leggere il corpo della richiesta per liberare spazio di buffer. I trailer sono sempre disponibili se si legge il corpo della richiesta nella parte finale. I trailer contrassegnano la fine del corpo.

Versione introdotta

3,0

Comportamento precedente

Le intestazioni Trailer della richiesta venivano aggiunte alla raccolta HttpRequest.Headers.

Nuovo comportamento

Le intestazioni Trailer della richiesta non sono presenti nella raccolta HttpRequest.Headers. Usare i metodi di estensione seguenti in HttpRequest per accedervi:

  • GetDeclaredTrailers() - Ottiene l'intestazione "Trailer" della richiesta che elenca i trailer previsti dopo il corpo.
  • SupportsTrailers() - Indica se la richiesta supporta la ricezione di intestazioni Trailer.
  • CheckTrailersAvailable() - Determina se la richiesta supporta i trailer e se sono disponibili per la lettura.
  • GetTrailer(string trailerName) - Ottiene l'intestazione Trailer richiesta dalla risposta.

Motivo della modifica

I trailer sono una funzionalità chiave in scenari come gRPC. L'unione dei trailer alle intestazioni delle richieste causava confusione negli utenti.

Usare i metodi di estensione correlati ai trailer in HttpRequest per accedere ai trailer.

Category

ASP.NET Core

API interessate

HttpRequest.Headers

Kestrel: astrazioni di trasporto rimosse e rese pubbliche

Nel quadro dell'abbandono delle API "pubternal", le API del livello di trasporto di Kestrel vengono esposte come interfaccia pubblica nella libreria Microsoft.AspNetCore.Connections.Abstractions.

Versione introdotta

3,0

Comportamento precedente

  • Le astrazioni correlate al trasporto erano disponibili nella libreria Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions.
  • Era disponibile la proprietà ListenOptions.NoDelay.

Nuovo comportamento

  • L'interfaccia IConnectionListener è stata introdotta nella libreria Microsoft.AspNetCore.Connections.Abstractions per esporre le funzionalità più usate dalla libreria ...Transport.Abstractions.
  • Ora nelle opzioni di trasporto è disponibile NoDelay (LibuvTransportOptions e SocketTransportOptions).
  • SchedulingMode non è più disponibile.

Motivo della modifica

ASP.NET Core 3.0 ha abbandonato l'uso delle API "pubternal".

Category

ASP.NET Core

API interessate

None

Localizzazione: ResourceManagerWithCultureStringLocalizer e WithCulture contrassegnati come obsoleti

La classe ResourceManagerWithCultureStringLocalizer e il membro dell'interfaccia WithCulture sono spesso fonte di confusione per gli utenti della localizzazione, in particolare quando creano la propria implementazione di IStringLocalizer. Questi elementi danno all'utente l'impressione che un'istanza di IStringLocalizer sia per lingua e per risorsa. In realtà, le istanze devono essere solo per risorsa. Il linguaggio cercato è determinato dall'elemento CultureInfo.CurrentUICulture in fase di esecuzione. Per eliminare la causa di confusione, le API sono state contrassegnate come obsolete in ASP.NET Core 3.0 Preview 3. Le API verranno rimosse in una versione futura.

Per il contesto, vedere dotnet/aspnetcore#3324. Per informazioni, vedere dotnet/aspnetcore#7756.

Versione introdotta

3,0

Comportamento precedente

I metodi non sono stati contrassegnati come Obsolete.

Nuovo comportamento

I metodi sono contrassegnati come Obsolete.

Motivo della modifica

Le API rappresentavano un caso d'uso non consigliato. C'era confusione sulla progettazione della localizzazione.

È consigliabile usare ResourceManagerStringLocalizer. Lasciare che le impostazioni cultura siano impostate da CurrentCulture. Se non è possibile, creare e usare una copia di ResourceManagerWithCultureStringLocalizer.

Category

ASP.NET Core

API interessate

Registrazione: classe DebugLogger resa interna

Prima di ASP.NET Core 3.0, il modificatore di accesso di DebugLogger era public. In ASP.NET Core 3.0 il modificatore di accesso è diventato internal.

Versione introdotta

3,0

Motivo della modifica

La modifica è stata apportata per:

  • Garantire la coerenza con altre implementazioni del logger, ad esempio ConsoleLogger.
  • Ridurre la superficie dell'API.

Usare il metodo di estensione ILoggingBuilder di AddDebug per abilitare la registrazione di debug. DebugLoggerProvider è ancora public, nel caso in cui il servizio debba essere registrato manualmente.

Category

ASP.NET Core

API interessate

Microsoft.Extensions.Logging.Debug.DebugLogger

MVC: suffisso Async rimosso dai nomi delle azioni del controller

Come parte della soluzione del problema dotnet/aspnetcore#4849, ASP.NET Core MVC elimina il suffisso Async dai nomi delle azioni per impostazione predefinita. A partire da ASP.NET Core 3.0, questa modifica influisce sia sul routing che sulla generazione di collegamenti.

Versione introdotta

3,0

Comportamento precedente

Considerare il controller ASP.NET Core MVC seguente:

public class ProductController : Controller
{
    public async IActionResult ListAsync()
    {
        var model = await DbContext.Products.ToListAsync();
        return View(model);
    }
}

L'azione è instradabile tramite Product/ListAsync. Per la generazione di collegamenti occorre specificare il suffisso Async. Ad esempio:

<a asp-controller="Product" asp-action="ListAsync">List</a>

Nuovo comportamento

In ASP.NET Core 3.0 l'azione può essere instradata tramite Product/List. Il codice di generazione del collegamento deve omettere il suffisso Async. Ad esempio:

<a asp-controller="Product" asp-action="List">List</a>

Questa modifica non influisce sui nomi specificati usando l'attributo [ActionName]. È possibile disabilitare il nuovo comportamento impostando MvcOptions.SuppressAsyncSuffixInActionNames su false in Startup.ConfigureServices:

services.AddMvc(options =>
{
   options.SuppressAsyncSuffixInActionNames = false;
});

Motivo della modifica

Per convenzione, i metodi .NET asincroni hanno il suffisso Async. Tuttavia, quando un metodo definisce un'azione MVC, non è consigliabile usare il suffisso Async.

Se per l'app è necessario che le azioni MVC conservino il suffisso Async del nome, scegliere una delle mitigazioni seguenti:

  • Usare l'attributo [ActionName] per mantenere il nome originale.
  • Disabilitare completamente la ridenominazione impostando MvcOptions.SuppressAsyncSuffixInActionNames su false in Startup.ConfigureServices:
services.AddMvc(options =>
{
   options.SuppressAsyncSuffixInActionNames = false;
});

Category

ASP.NET Core

API interessate

None

MVC: JsonResult spostato in Microsoft.AspNetCore.Mvc.Core

JsonResult è stato spostato nell'assembly Microsoft.AspNetCore.Mvc.Core. Questo tipo era definito in Microsoft.AspNetCore.Mvc.Formatters.Json. Per risolvere questo problema per la maggior parte degli utenti, in Microsoft.AspNetCore.Mvc.Formatters.Json è stato aggiunto un attributo [TypeForwardedTo] a livello di assembly. Le app che usano librerie di terze parti possono riscontrare problemi.

Versione introdotta

3.0 Preview 6

Comportamento precedente

Un'app che usa una libreria basata su 2.2 viene compilata correttamente.

Nuovo comportamento

La compilazione di un'app che usa una libreria basata su 2.2 non riesce. Viene visualizzato un errore contenente un errore simile al seguente:

The type 'JsonResult' exists in both 'Microsoft.AspNetCore.Mvc.Core, Version=3.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' and 'Microsoft.AspNetCore.Mvc.Formatters.Json, Version=2.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'

Per un esempio di questo tipo di problema, vedere dotnet/aspnetcore#7220.

Motivo della modifica

Modifiche a livello di piattaforma alla composizione di ASP.NET Core, come descritto in aspnet/Announcements#325.

Potrebbe essere necessario ricompilare le librerie compilate per la versione 2.2 di Microsoft.AspNetCore.Mvc.Formatters.Json per risolvere il problema per tutti i consumer. Se si è interessati dal problema, rivolgersi all'autore della libreria. Chiedere la ricompilazione della libreria per la destinazione ASP.NET Core 3.0.

Category

ASP.NET Core

API interessate

Microsoft.AspNetCore.Mvc.JsonResult

MVC: strumento di precompilazione deprecato

In ASP.NET Core 1.1 è stato introdotto il pacchetto Microsoft.AspNetCore.Mvc.Razor.ViewCompilation (strumento di precompilazione MVC) per aggiungere il supporto per la compilazione in fase di pubblicazione dei file Razor (.cshtml). In ASP.NET Core 2.1 è stato introdotto Razor SDK, per ampliare le funzionalità dello strumento di precompilazione. Razor SDK ha aggiunto il supporto per la compilazione di file Razor in fase di compilazione e pubblicazione. L'SDK verifica la correttezza dei file.cshtml in fase di compilazione, migliorando inoltre il tempo di avvio dell'app. Razor SDK è attivato per impostazione predefinita e non è necessario alcun intervento per iniziare a usarlo.

In ASP.NET Core 3.0, lo strumento di precompilazione MVC di ASP.NET Core 1.1 è stato rimosso. Le versioni precedenti del pacchetto continueranno a ricevere importanti correzioni di bug e per sicurezza nelle versioni patch.

Versione introdotta

3,0

Comportamento precedente

Il pacchetto Microsoft.AspNetCore.Mvc.Razor.ViewCompilation era usato per precompilare le visualizzazioni Razor di MVC.

Nuovo comportamento

Razor SDK supporta questa funzionalità in modo nativo. Il pacchetto Microsoft.AspNetCore.Mvc.Razor.ViewCompilation non viene più aggiornato.

Motivo della modifica

Razor SDK offre più funzionalità e verifica la correttezza dei file .cshtml in fase di compilazione. L'SDK migliora anche il tempo di avvio dell'app.

Per gli utenti di ASP.NET Core 2.1 o versione successiva, eseguire l'aggiornamento in modo da usare il supporto nativo per la precompilazione in Razor SDK. Se la presenza di bug o la mancanza di funzionalità impediscono la migrazione a Razor SDK, aprire un problema in dotnet/aspnetcore.

Category

ASP.NET Core

API interessate

None

MVC: tipi "pubternal" modificati in interni

In ASP.NET Core 3.0 tutti i tipi "pubternal" di MVC sono stati aggiornati per essere public in uno spazio dei nomi supportato oppure internal in base alle esigenze.

Descrizione delle modifiche

In ASP.NET Core i tipi "pubternal" vengono dichiarati come public, ma risiedono in uno spazio dei nomi con suffisso .Internal. Sebbene questi tipi siano public, non hanno criteri di supporto e sono soggetti a modifiche che causano un'interruzione. Sfortunatamente, l'uso accidentale di questi tipi è stato frequente, dando luogo a modifiche che causano interruzioni in questi progetti e limitando la capacità di gestire il framework.

Versione introdotta

3,0

Comportamento precedente

Alcuni tipi in MVC erano public, ma in uno spazio dei nomi .Internal. Questi tipi non avevano criteri di supporto ed erano soggetti a modifiche causano un'interruzione.

Nuovo comportamento

Tutti questi tipi vengono aggiornati in modo che siano public in uno spazio dei nomi supportato oppure contrassegnati come internal.

Motivo della modifica

L'uso accidentale dei tipi "pubternal" è stato frequente, dando luogo a modifiche che causano un'interruzione in questi progetti e limitando la capacità di gestire il framework.

Se si usano tipi che sono diventati realmente public e sono stati spostati in un nuovo spazio dei nomi supportato, aggiornare i riferimenti in modo che corrispondano ai nuovi spazi dei nomi.

Se si usano tipi che sono stati contrassegnati come internal, sarà necessario trovare un'alternativa. I tipi precedentemente "pubternal" non sono mai stati supportati per l'utilizzo pubblico. Se in questi spazi dei nomi sono presenti tipi specifici di importanza critica per le app, segnalare il problema alla pagina dotnet/aspnetcore. Si potrebbe valutare di rendere public i tipi richiesti.

Category

ASP.NET Core

API interessate

Questa modifica include i tipi negli spazi dei nomi seguenti:

  • Microsoft.AspNetCore.Mvc.Cors.Internal
  • Microsoft.AspNetCore.Mvc.DataAnnotations.Internal
  • Microsoft.AspNetCore.Mvc.Formatters.Internal
  • Microsoft.AspNetCore.Mvc.Formatters.Json.Internal
  • Microsoft.AspNetCore.Mvc.Formatters.Xml.Internal
  • Microsoft.AspNetCore.Mvc.Internal
  • Microsoft.AspNetCore.Mvc.ModelBinding.Internal
  • Microsoft.AspNetCore.Mvc.Razor.Internal
  • Microsoft.AspNetCore.Mvc.RazorPages.Internal
  • Microsoft.AspNetCore.Mvc.TagHelpers.Internal
  • Microsoft.AspNetCore.Mvc.ViewFeatures.Internal

MVC: shim di compatibilità API Web rimosso

A partire da ASP.NET Core 3.0, il pacchetto Microsoft.AspNetCore.Mvc.WebApiCompatShim non è più disponibile.

Descrizione delle modifiche

Il pacchetto Microsoft.AspNetCore.Mvc.WebApiCompatShim (WebApiCompatShim) offre compatibilità parziale in ASP.NET Core con l'API Web 2 di ASP.NET 4.x per semplificare la migrazione delle implementazioni di API Web esistenti ad ASP.NET Core. Tuttavia, le app che usano WebApiCompatShim non traggono vantaggio dalle funzionalità correlate alle API disponibili nelle versioni recenti di ASP.NET Core. Tali funzionalità includono il miglioramento della generazione della specifica OpenAPI, la gestione degli errori standardizzata e la generazione di codice client. Per focalizzare meglio le iniziative rivolte alle API nella versione 3.0, WebApiCompatShim è stato rimosso. Le app esistenti che usano WebApiCompatShim devono eseguire la migrazione al modello più recente di [ApiController].

Versione introdotta

3,0

Motivo della modifica

Lo shim di compatibilità dell'API Web era uno strumento di migrazione. Limita l'accesso degli utenti alle nuove funzionalità aggiunte in ASP.NET Core.

Rimuovere l'utilizzo di questo shim ed eseguire direttamente la migrazione alla funzionalità analoga in ASP.NET Core stesso.

Category

ASP.NET Core

API interessate

Microsoft.AspNetCore.Mvc.WebApiCompatShim

Razor: API RazorTemplateEngine rimossa

L'API RazorTemplateEngine è stata rimossa e sostituita con Microsoft.AspNetCore.Razor.Language.RazorProjectEngine.

Per informazioni, vedere il problema GitHub dotnet/aspnetcore#25215.

Versione introdotta

3,0

Comportamento precedente

È possibile creare un motore di modelli e usarlo per analizzare e generare codice per i file Razor.

Nuovo comportamento

È possibile creare un'API RazorProjectEngine a cui fornire lo stesso tipo di informazioni di RazorTemplateEngine per analizzare e generare codice per i file Razor. RazorProjectEngine fornisce anche livelli di configurazione aggiuntivi.

Motivo della modifica

L'API RazorTemplateEngine era accoppiata troppo strettamente alle implementazioni esistenti. Questo accoppiamento stretto generava ulteriori problemi nel tentativo di configurare correttamente una pipeline di analisi/generazione Razor.

Usare RazorProjectEngine invece di RazorTemplateEngine. Si considerino gli esempi seguenti.

Creare e configurare RazorProjectEngine
RazorProjectEngine projectEngine =
    RazorProjectEngine.Create(RazorConfiguration.Default,
        RazorProjectFileSystem.Create(@"C:\source\repos\ConsoleApp4\ConsoleApp4"),
        builder =>
        {
            builder.ConfigureClass((document, classNode) =>
            {
                classNode.ClassName = "MyClassName";

                // Can also configure other aspects of the class here.
            });

            // More configuration can go here
        });
Generare codice per un file Razor
RazorProjectItem item = projectEngine.FileSystem.GetItem(
    @"C:\source\repos\ConsoleApp4\ConsoleApp4\Example.cshtml",
    FileKinds.Legacy);
RazorCodeDocument output = projectEngine.Process(item);

// Things available
RazorSyntaxTree syntaxTree = output.GetSyntaxTree();
DocumentIntermediateNode intermediateDocument =
    output.GetDocumentIntermediateNode();
RazorCSharpDocument csharpDocument = output.GetCSharpDocument();

Category

ASP.NET Core

API interessate

  • RazorTemplateEngine
  • RazorTemplateEngineOptions

Razor: compilazione in fase di esecuzione spostata in un pacchetto

Il supporto per la compilazione in fase di esecuzione di visualizzazioni Razor e Razor Pages è stato spostato in un pacchetto separato.

Versione introdotta

3,0

Comportamento precedente

La compilazione in fase di esecuzione è disponibile senza bisogno di altri pacchetti.

Nuovo comportamento

La funzionalità è stata spostata nel pacchetto Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation.

In precedenza erano disponibili le API seguenti in Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions per supportare la compilazione in fase di esecuzione. Ora le API sono disponibili tramite Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation.MvcRazorRuntimeCompilationOptions.

  • RazorViewEngineOptions.FileProviders è ora MvcRazorRuntimeCompilationOptions.FileProviders
  • RazorViewEngineOptions.AdditionalCompilationReferences è ora MvcRazorRuntimeCompilationOptions.AdditionalReferencePaths

Inoltre, Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions.AllowRecompilingViewsOnFileChange è stato rimosso. La ricompilazione alla modifica dei file è abilitata per impostazione predefinita facendo riferimento al pacchetto Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation.

Motivo della modifica

Questa modifica è stata necessaria per rimuovere la dipendenza del framework condiviso di ASP.NET Core da Roslyn.

Per le app che richiedono la compilazione in fase di esecuzione o la ricompilazione dei file Razor occorre seguire questa procedura:

  1. Aggiungere un riferimento al pacchetto Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation.

  2. Aggiornare il metodo Startup.ConfigureServices del progetto per includere una chiamata a AddRazorRuntimeCompilation. Ad esempio:

    services.AddMvc()
    .AddRazorRuntimeCompilation();

Category

ASP.NET Core

API interessate

Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions

Stato sessione: API obsolete rimosse

Le API obsolete per la configurazione dei cookie di sessione sono state rimosse. Per altre informazioni, vedere aspnet/Announcements#257.

Versione introdotta

3,0

Motivo della modifica

Questa modifica assicura la coerenza tra le API per la configurazione delle funzionalità che usano i cookie.

Eseguire la migrazione delle app all'utilizzo delle nuove API al posto di quelle rimosse. Si consideri l'esempio seguente in Startup.ConfigureServices:

public void ConfigureServices(ServiceCollection services)
{
    services.AddSession(options =>
    {
        // Removed obsolete APIs
        options.CookieName = "SessionCookie";
        options.CookieDomain = "contoso.com";
        options.CookiePath = "/";
        options.CookieHttpOnly = true;
        options.CookieSecure = CookieSecurePolicy.Always;

        // new API
        options.Cookie.Name = "SessionCookie";
        options.Cookie.Domain = "contoso.com";
        options.Cookie.Path = "/";
        options.Cookie.HttpOnly = true;
        options.Cookie.SecurePolicy = CookieSecurePolicy.Always;
    });
}

Category

ASP.NET Core

API interessate

Framework condiviso: assembly rimossi da Microsoft.AspNetCore.App

A partire da ASP.NET Core 3.0, il framework condiviso ASP.NET Core (Microsoft.AspNetCore.App) contiene solo assembly proprietari completamente sviluppati, supportati e mantenuti da Microsoft.

Descrizione delle modifiche

Si può considerare la modifica una ridefinizione dei limiti per la "piattaforma" ASP.NET Core. Tramite GitHub, chiunque potrà compilare il codice sorgente del framework condiviso, che continuerà a offrire gli attuali vantaggi dei framework condivisi di .NET Core alle app. Alcuni di questi vantaggi includono dimensioni di distribuzione minori, applicazione centralizzata delle patch e tempi di avvio più rapidi.

Come parte della modifica, in Microsoft.AspNetCore.App sono state introdotte alcune modifiche di rilievo che causano un'interruzione.

Versione introdotta

3,0

Comportamento precedente

I progetti facevano riferimento a Microsoft.AspNetCore.App tramite un elemento <PackageReference> nel file di progetto.

Inoltre, Microsoft.AspNetCore.App conteneva i sottocomponenti seguenti:

  • Json.NET (Newtonsoft.Json)
  • Entity Framework Core (assembly con prefisso Microsoft.EntityFrameworkCore.)
  • Roslyn (Microsoft.CodeAnalysis)

Nuovo comportamento

Un riferimento a Microsoft.AspNetCore.App non richiede più un elemento <PackageReference> nel file di progetto. .NET Core SDK supporta un nuovo elemento denominato <FrameworkReference>, che sostituisce l'uso di <PackageReference>.

Per altre informazioni, vedere dotnet/aspnetcore#3612.

Entity Framework Core viene distribuito sotto forma di pacchetti NuGet. Questa modifica allinea il modello di distribuzione a quello di tutte le altre librerie di accesso ai dati in .NET. Fornisce a Entity Framework Core il percorso più semplice per continuare a innovare supportando le varie piattaforme .NET. Lo spostamento di Entity Framework Core all'esterno del framework condiviso non ha alcun impatto sul suo stato di libreria sviluppata, supportata e mantenuta da Microsoft. I criteri di supporto di .NET Core continuano a coprirla.

Json.NET ed Entity Framework Core continuano a funzionare con ASP.NET Core. Non saranno tuttavia inclusi nel framework condiviso.

Per altre informazioni, vedere Il futuro di JSON in .NET Core 3.0. Vedere anche l'elenco completo dei file binari rimossi dal framework condiviso.

Motivo della modifica

Questa modifica semplifica l'utilizzo di Microsoft.AspNetCore.App e riduce la duplicazione tra pacchetti NuGet e framework condivisi.

Per altre informazioni sul motivo di questa modifica, vedere questo post di blog.

A partire da ASP.NET Core 3.0, non è più necessario per i progetti utilizzare gli assembly in Microsoft.AspNetCore.App come pacchetti NuGet. Per semplificare la scelta della destinazione e l'utilizzo del framework condiviso di ASP.NET Core, molti pacchetti NuGet forniti a partire da ASP.NET Core 1.0 non vengono più prodotti. Le API fornite da tali pacchetti sono ancora disponibili per le app usando un elemento <FrameworkReference> per fare riferimento a Microsoft.AspNetCore.App. Alcuni esempi di API comuni includono Kestrel, MVC e Razor.

Questa modifica non si applica a tutti i file binari a cui viene fatto riferimento tramite Microsoft.AspNetCore.App in ASP.NET Core 2.x. Le eccezioni rilevanti includono:

  • Le librerie Microsoft.Extensions che continuano a essere destinate a .NET Standard e che sono disponibili come pacchetti NuGet (vedere https://github.com/dotnet/extensions).
  • Le API prodotte dal team ASP.NET Core che non fanno parte di Microsoft.AspNetCore.App. Ad esempio, i componenti seguenti sono disponibili come pacchetti NuGet:
  • Le estensioni a MVC che mantengono il supporto per Json.NET. Per supportare l'uso di Json.NET e MVC è disponibile un'API fornita come pacchetto NuGet. Per altri dettagli, vedere la guida alla migrazione di ASP.NET Core.
  • Il client .NET di SignalR continua a supportare .NET Standard e viene fornito come pacchetto NuGet. È progettato per l'utilizzo in molti runtime .NET, ad esempio Xamarin e UWP.

Per altre informazioni, vedere Interrompere la produzione di pacchetti per assembly del framework condiviso nella versione 3.0. Per informazioni, vedere dotnet/aspnetcore#3757.

Category

ASP.NET Core

API interessate

Framework condiviso: Microsoft.AspNetCore.All rimosso

A partire da ASP.NET Core 3.0, il metapacchetto Microsoft.AspNetCore.All e il framework condiviso corrispondente Microsoft.AspNetCore.All non vengono più prodotti. Questo pacchetto è disponibile in ASP.NET Core 2.2 e continuerà a ricevere aggiornamenti di manutenzione in ASP.NET Core 2.1.

Versione introdotta

3,0

Comportamento precedente

Le app possono usare il metapacchetto Microsoft.AspNetCore.All per specificare come destinazione il framework condiviso Microsoft.AspNetCore.All in .NET Core.

Nuovo comportamento

.NET Core 3.0 non include un framework condiviso Microsoft.AspNetCore.All.

Motivo della modifica

Il metapacchetto Microsoft.AspNetCore.All includeva un numero elevato di dipendenze esterne.

Eseguire la migrazione del progetto per usare il framework Microsoft.AspNetCore.App. I componenti precedentemente disponibili in Microsoft.AspNetCore.All sono ancora disponibili in NuGet. Ora questi componenti vengono distribuiti con l'app anziché essere inclusi nel framework condiviso.

Category

ASP.NET Core

API interessate

None

SignalR: HandshakeProtocol.SuccessHandshakeData sostituito

Il campo HandshakeProtocol.SuccessHandshakeData è stato rimosso e sostituito con un metodo helper che genera una risposta handshake riuscito in funzione di uno specifico IHubProtocol.

Versione introdotta

3,0

Comportamento precedente

HandshakeProtocol.SuccessHandshakeData era un campo public static ReadOnlyMemory<byte>.

Nuovo comportamento

HandshakeProtocol.SuccessHandshakeData è stato sostituito da un metodo staticGetSuccessfulHandshake(IHubProtocol protocol) che restituisce un elemento ReadOnlyMemory<byte> in base al protocollo specificato.

Motivo della modifica

Alla risposta handshake sono stati aggiunti campi non costanti, che cambiano a seconda del protocollo selezionato.

Nessuno. Questo tipo non è progettato per l'uso a partire dal codice utente. È public, quindi può essere condiviso tra il server SignalR e il client. Può essere usato anche dai client SignalR dei clienti scritti in .NET. Gli utenti di SignalR non dovrebbero essere interessati da questa modifica.

Category

ASP.NET Core

API interessate

HandshakeProtocol.SuccessHandshakeData

SignalR: metodi ResetSendPing e ResetTimeout di HubConnection rimossi

I metodi ResetSendPing e ResetTimeout sono stati rimossi dall'API HubConnection di SignalR. Questi metodi erano originariamente progettati solo per l'uso interno, ma sono stati resi pubblici in ASP.NET Core 2.2. A partire dalla versione ASP.NET Core 3.0 Preview 4, non saranno più disponibili. Per informazioni, vedere dotnet/aspnetcore#8543.

Versione introdotta

3,0

Comportamento precedente

Le API erano disponibili.

Nuovo comportamento

Le API sono state rimosse.

Motivo della modifica

Questi metodi in origine erano progettati solo per l'uso interno, ma sono stati resi pubblici in ASP.NET Core 2.2.

Non usare questi metodi.

Category

ASP.NET Core

API interessate

SignalR: costruttori HubConnectionContext modificati

I costruttori HubConnectionContext di SignalR sono stati modificati in modo da accettare un tipo options anziché più parametri, per garantire la possibilità di aggiungere opzioni in futuro. Questa modifica sostituisce due costruttori con un singolo costruttore che accetta un tipo Options.

Versione introdotta

3,0

Comportamento precedente

HubConnectionContext ha due costruttori:

public HubConnectionContext(ConnectionContext connectionContext, TimeSpan keepAliveInterval, ILoggerFactory loggerFactory);
public HubConnectionContext(ConnectionContext connectionContext, TimeSpan keepAliveInterval, ILoggerFactory loggerFactory, TimeSpan clientTimeoutInterval);

Nuovo comportamento

I due costruttori sono stati rimossi e sostituiti con un costruttore:

public HubConnectionContext(ConnectionContext connectionContext, HubConnectionContextOptions contextOptions, ILoggerFactory loggerFactory)

Motivo della modifica

Il nuovo costruttore usa un nuovo oggetto Options. Di conseguenza, in futuro sarà possibile espandere le funzionalità di HubConnectionContext senza creare altri costruttori e apportare modifiche che causano un'interruzione.

Anziché usare il costruttore seguente:

HubConnectionContext connectionContext = new HubConnectionContext(
    connectionContext,
    keepAliveInterval: TimeSpan.FromSeconds(15),
    loggerFactory,
    clientTimeoutInterval: TimeSpan.FromSeconds(15));

Usare il costruttore seguente:

HubConnectionContextOptions contextOptions = new HubConnectionContextOptions()
{
    KeepAliveInterval = TimeSpan.FromSeconds(15),
    ClientTimeoutInterval = TimeSpan.FromSeconds(15)
};
HubConnectionContext connectionContext = new HubConnectionContext(connectionContext, contextOptions, loggerFactory);

Category

ASP.NET Core

API interessate

SignalR: modifica del nome del pacchetto client JavaScript

In ASP.NET Core 3.0 Preview 7 il nome del pacchetto client JavaScript di SignalR è cambiato da @aspnet/signalr a @microsoft/signalr. La modifica del nome riflette il fatto che SignalR non è utile soltanto per le app ASP.NET Core, grazie al Servizio Azure SignalR.

Per reagire a questa modifica, modificare i riferimenti nei file package.json, nelle istruzioni require e nelle istruzioni import ECMAScript. Nessuna API verrà modificata come parte di questa ridenominazione.

Per informazioni, vedere dotnet/aspnetcore#11637.

Versione introdotta

3,0

Comportamento precedente

Il pacchetto client era denominato @aspnet/signalr.

Nuovo comportamento

Il pacchetto client è denominato @microsoft/signalr.

Motivo della modifica

La modifica del nome chiarisce il fatto che SignalR è utile anche oltre le app ASP.NET Core, grazie al Servizio Azure SignalR.

Passare al nuovo pacchetto @microsoft/signalr.

Category

ASP.NET Core

API interessate

None

SignalR: metodi UseSignalR e UseConnections contrassegnati come obsoleti

I metodi UseConnections e UseSignalR e le classi ConnectionsRouteBuilder e HubRouteBuilder sono contrassegnati come obsoleti in ASP.NET Core 3.0.

Versione introdotta

3,0

Comportamento precedente

Il routing dell'hub di SignalR veniva configurato usando UseSignalR o UseConnections.

Nuovo comportamento

Il vecchio modo di configurare il routing è diventato obsoleto ed è stato sostituito con il routing degli endpoint.

Motivo della modifica

Il middleware sta passando al nuovo sistema di routing degli endpoint. Il vecchio modo di aggiungere il middleware sta diventando obsoleto.

Sostituire UseSignalR con UseEndpoints:

Codice precedente:

app.UseSignalR(routes =>
{
    routes.MapHub<SomeHub>("/path");
});

Nuovo codice:

app.UseEndpoints(endpoints =>
{
    endpoints.MapHub<SomeHub>("/path");
});

Category

ASP.NET Core

API interessate

Applicazioni a pagina singola: SpaServices e NodeServices contrassegnati come obsoleti

Il contenuto dei pacchetti NuGet seguenti non è più necessario a partire da ASP.NET Core 2.1. Di conseguenza, i pacchetti seguenti sono contrassegnati come obsoleti:

Per lo stesso motivo, i moduli npm seguenti vengono contrassegnati come deprecati:

I pacchetti e i moduli npm precedenti verranno successivamente rimossi in .NET 5.

Versione introdotta

3,0

Comportamento precedente

I pacchetti e i moduli npm deprecati erano progettati per integrare ASP.NET Core con vari framework per app a pagina singola. Tali framework includono Angular, React e React con Redux.

Nuovo comportamento

È disponibile un nuovo meccanismo di integrazione nel pacchetto NuGet Microsoft.AspNetCore.SpaServices.Extensions. Il pacchetto resta la base dei modelli di progetto Angular e React a partire da ASP.NET Core 2.1.

Motivo della modifica

ASP.NET Core supporta l'integrazione con vari framework per app a pagina singola, tra cui Angular, React e React con Redux. Inizialmente, l'integrazione con questi framework veniva eseguita con componenti specifici di ASP.NET Core che gestivano scenari come il rendering preliminare lato server e l'integrazione con Webpack. Col passare del tempo, gli standard del settore sono cambiati. Tutti i framework per app a pagina singola hanno rilasciato le proprie interfacce della riga di comando standard, ad esempio, Angular CLI e create-react-app.

Quando è stato rilasciato ASP.NET Core 2.1, nel maggio 2018, il team ha risposto alla modifica degli standard. È stato fornito un modo più semplice e nuovo per l'integrazione con le toolchain proprietarie dei framework per app a pagina singola. Il nuovo meccanismo di integrazione si trova nel pacchetto Microsoft.AspNetCore.SpaServices.Extensions e rimane la base dei modelli di progetto Angular e React a partire da ASP.NET Core 2.1.

Per chiarire che i componenti specifici di ASP.NET Core precedenti sono irrilevanti e non sono consigliati:

  • Il meccanismo di integrazione precedente alla versione 2.1 è contrassegnato come obsoleto.
  • I pacchetti npm di supporto sono contrassegnati come deprecati.

Se si usano questi pacchetti, aggiornare le app in modo da usare la funzionalità:

  • Nel pacchetto Microsoft.AspNetCore.SpaServices.Extensions.
  • Fornita dai framework per app a pagina singola in uso

Per abilitare funzionalità come il rendering preliminare lato server e il ricaricamento rapido dei moduli, vedere la documentazione del framework per app a pagina singola corrispondente. La funzionalità in Microsoft.AspNetCore.SpaServices.Extensionsnon è obsoleta e continuerà a essere supportata.

Category

ASP.NET Core

API interessate

Applicazioni a pagina singola: SpaServices e NodeServices non eseguono più il fallback al logger della console

Microsoft.AspNetCore.SpaServices e Microsoft.AspNetCore.NodeServices non visualizzeranno i log della console a meno che non sia configurata la registrazione.

Versione introdotta

3,0

Comportamento precedente

Microsoft.AspNetCore.SpaServices e Microsoft.AspNetCore.NodeServices creavano automaticamente un logger della console quando la registrazione non è configurata.

Nuovo comportamento

Microsoft.AspNetCore.SpaServices e Microsoft.AspNetCore.NodeServices non visualizzeranno i log della console a meno che non sia configurata la registrazione.

Motivo della modifica

È necessario allineare il modo in cui gli altri pacchetti ASP.NET Core implementano la registrazione.

Se è necessario il comportamento precedente, per configurare la registrazione della console aggiungere services.AddLogging(builder => builder.AddConsole()) al metodoSetup.ConfigureServices.

Category

ASP.NET Core

API interessate

None

Framework di destinazione: supporto di .NET Framework rimosso

A partire da ASP.NET Core 3.0, .NET Framework è un framework di destinazione non supportato.

Descrizione delle modifiche

.NET Framework 4.8 è l'ultima versione principale di .NET Framework. Le nuove app ASP.NET Core devono essere basate su .NET Core. A partire dalla versione .NET Core 3.0, si può considerare ASP.NET Core 3.0 come parte di .NET Core.

I clienti che usano ASP.NET Core con .NET Framework possono continuare in una modalità completamente supportata usando la versione 2.1 LTS. Il supporto e la manutenzione per la versione 2.1 proseguiranno fino al 21 agosto 2021. Questa data è di tre anni successiva alla dichiarazione della versione LTS in base ai criteri di supporto di .NET. Il supporto per i pacchetti ASP.NET Core 2.1 in .NET Framework continuerà a tempo indeterminato, in modo analogo ai criteri di manutenzione di altri framework ASP.NET basati su pacchetti.

Per altre informazioni sulla conversione da .NET Framework a .NET Core, vedere Conversione a .NET Core.

I Microsoft.Extensions pacchetti, ad esempio per la registrazione, l'inserimento delle dipendenze e la configurazione, ed Entity Framework Core non sono interessati. Continueranno a supportare .NET Standard.

Per altre informazioni sul motivo di questa modifica, vedere il post di blog originale.

Versione introdotta

3,0

Comportamento precedente

Le app ASP.NET Core potevano essere eseguite in .NET Core o in .NET Framework.

Nuovo comportamento

Le app ASP.NET Core possono essere eseguite solo in .NET Core.

Effettua una delle seguenti azioni:

  • Mantenere l'app in ASP.NET Core 2.1.
  • Eseguire la migrazione dell'app e delle dipendenze a .NET Core.

Category

ASP.NET Core

API interessate

Nessuno