Icke-bakåtkompatibla ändringar i .NET Core 3.0

  • Artikel

Om du migrerar till version 3.0 av .NET Core, ASP.NET Core eller EF Core kan de icke-bakåtkompatibla ändringarna som anges i den här artikeln påverka din app.

ASP.NET Core

Föråldrade API:er för förfalskning mot förfalskning, CORS, diagnostik, MVC och routning har tagits bort

Föråldrade medlemmar och kompatibilitetsväxlar i ASP.NET Core 2.2 har tagits bort.

Version introducerad

3,0

Orsak till ändringen

Förbättring av API-ytan över tid.

När du riktar in dig på .NET Core 2.2 följer du vägledningen i de föråldrade byggmeddelandena för att använda nya API:er i stället.

Kategori

ASP.NET Core

Berörda API:er

Följande typer och medlemmar har markerats som föråldrade för ASP.NET Core 2.1 och 2.2:

Typer

  • 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

Konstruktörer

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

Egenskaper

  • 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

Metoder

"Pubternal"-API:er har tagits bort

För att bättre underhålla den offentliga API-ytan för ASP.NET Core har de flesta typerna i *.Internal namnområden (kallas "pubternal" API:er) blivit verkligt interna. Medlemmar i dessa namnområden var aldrig avsedda att stödjas som offentliga API:er. API:erna kan brytas i mindre versioner och gjorde det ofta. Kod som är beroende av dessa API:er bryts vid uppdatering till ASP.NET Core 3.0.

Mer information finns i dotnet/aspnetcore#4932 och dotnet/aspnetcore#11312.

Version introducerad

3,0

Gammalt beteende

De berörda API:erna markeras med public åtkomstmodifieraren och finns i *.Internal namnområden.

Nytt beteende

De berörda API:erna markeras med den interna åtkomstmodifieraren och kan inte längre användas av kod utanför sammansättningen.

Orsak till ändringen

Vägledningen för dessa "pubternal" API:er var att de:

  • Kan ändras utan förvarning.
  • Var inte föremål för .NET-principer för att förhindra icke-bakåtkompatibla ändringar.

Att lämna API:erna public (även i *.Internal namnrymderna) var förvirrande för kunderna.

Sluta använda dessa "pubternal" API:er. Om du har frågor om alternativa API:er öppnar du ett problem på dotnet/aspnetcore-lagringsplatsen .

Tänk dig till exempel följande HTTP-begärandebuffertningskod i ett ASP.NET Core 2.2-projekt. Tilläggsmetoden EnableRewind finns i Microsoft.AspNetCore.Http.Internal namnområdet.

HttpContext.Request.EnableRewind();

I ett ASP.NET Core 3.0-projekt ersätter du anropet EnableRewind med ett anrop till EnableBuffering tilläggsmetoden. Funktionen för buffring av begäranden fungerar som den gjorde tidigare. EnableBuffering anropar nu-API internal :et.

HttpContext.Request.EnableBuffering();

Kategori

ASP.NET Core

Berörda API:er

Alla API:er i Microsoft.AspNetCore.* namnrymderna och Microsoft.Extensions.* som har ett Internal segment i namnområdets namn. Till exempel:

  • Microsoft.AspNetCore.Authentication.Internal
  • Microsoft.AspNetCore.Builder.Internal
  • Microsoft.AspNetCore.DataProtection.Cng.Internal
  • Microsoft.AspNetCore.DataProtection.Internal
  • Microsoft.AspNetCore.Hosting.Internal
  • Microsoft.AspNetCore.Http.Internal
  • Microsoft.AspNetCore.Mvc.Core.Infrastructure
  • Microsoft.AspNetCore.Mvc.Core.Internal
  • 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
  • Microsoft.AspNetCore.Rewrite.Internal
  • Microsoft.AspNetCore.Routing.Internal
  • Microsoft.AspNetCore.Server.Kestrel.Core.Adapter.Internal
  • Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http
  • Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Infrastructure
  • Microsoft.AspNetCore.Server.Kestrel.Https.Internal

Autentisering: Google+ inaktuellt och ersatt

Google börjar stänga av Google+ Inloggning för appar redan den 28 januari 2019.

Ändra beskrivning

ASP.NET 4.x och ASP.NET Core har använt API:erna för Google+ inloggning för att autentisera Google-kontoanvändare i webbappar. De aktuella NuGet-paketen är Microsoft.AspNetCore.Authentication.Google för ASP.NET Core och Microsoft.Owin.Security.Google för Microsoft.Owin med ASP.NET Web Forms och MVC.

Googles ersättnings-API:er använder en annan datakälla och ett annat format. De åtgärder och lösningar som tillhandahålls nedan tar hänsyn till de strukturella förändringarna. Appar bör kontrollera att själva data fortfarande uppfyller sina krav. Namn, e-postadresser, profillänkar och profilfoton kan till exempel ge andra värden än tidigare.

Version introducerad

Alla versioner. Den här ändringen är extern för ASP.NET Core.

Owin med ASP.NET Webbformulär och MVC

För Microsoft.Owin 3.1.0 och senare beskrivs en tillfällig åtgärd här. Appar bör slutföra testningen med åtgärden för att söka efter ändringar i dataformatet. Det finns planer på att släppa Microsoft.Owin 4.0.1 med en korrigering. Appar som använder en tidigare version bör uppdateras till version 4.0.1.

ASP.NET Core 1.x

Åtgärden i Owin med ASP.NET Web Forms och MVC kan anpassas till ASP.NET Core 1.x. NuGet-paketkorrigeringar är inte planerade eftersom 1.x har nått statusen slut på livslängden .

ASP.NET Core 2.x

För Microsoft.AspNetCore.Authentication.Google version 2.x ersätter du ditt befintliga anrop till AddGoogle i Startup.ConfigureServices med följande kod:

.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");
});

Korrigeringarna 2.1 och 2.2 februari inkorporerade den föregående omkonfigurationen som det nya standardvärdet. Ingen korrigering planeras för ASP.NET Core 2.0 eftersom den har nått slutet av livet.

ASP.NET Core 3.0

Den åtgärd som ges för ASP.NET Core 2.x kan också användas för ASP.NET Core 3.0. I framtida förhandsversioner Microsoft.AspNetCore.Authentication.Google av 3.0 kan paketet tas bort. Användare dirigeras till Microsoft.AspNetCore.Authentication.OpenIdConnect i stället. Följande kod visar hur du ersätter AddGoogle med AddOpenIdConnect i Startup.ConfigureServices. Den här ersättningen kan användas med ASP.NET Core 2.0 och senare och kan anpassas för ASP.NET Core 1.x efter behov.

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

Kategori

ASP.NET Core

Berörda API:er

Microsoft.AspNetCore.Authentication.Google

Autentisering: Egenskapen HttpContext.Authentication har tagits bort

Den inaktuella Authentication egenskapen på HttpContext har tagits bort.

Ändra beskrivning

Som en del av dotnet/aspnetcore#6504 har den inaktuella Authentication egenskapen på HttpContext tagits bort. Egenskapen Authentication har varit inaktuell sedan 2.0. En migreringsguide publicerades för att migrera kod med den här inaktuella egenskapen till de nya ersättnings-API:erna. De återstående oanvända klasserna/API:erna som är relaterade till den gamla ASP.NET Core 1.x-autentiseringsstacken togs bort i commit dotnet/aspnetcore@d7a7c65.

Mer information finns i dotnet/aspnetcore#6533.

Version introducerad

3,0

Orsak till ändringen

ASP.NET Core 1.0 API:er har ersatts med tilläggsmetoder i Microsoft.AspNetCore.Authentication.AuthenticationHttpContextExtensions.

Se migreringsguiden.

Kategori

ASP.NET Core

Berörda API:er

Autentisering: Newtonsoft.Json-typer ersatta

I ASP.NET Core 3.0 Newtonsoft.Json har typer som används i autentiserings-API:er ersatts med System.Text.Json typer. Förutom i följande fall påverkas inte grundläggande användning av autentiseringspaketen:

  • Klasser som härleds från OAuth-leverantörerna, till exempel de från aspnet-contrib.
  • Avancerade implementeringar av anspråksmanipulering.

Mer information finns i dotnet/aspnetcore#7105. Mer information finns i dotnet/aspnetcore#7289.

Version introducerad

3,0

För härledda OAuth-implementeringar är den vanligaste ändringen att ersätta JObject.Parse med JsonDocument.Parse i åsidosättningen CreateTicketAsync enligt nedan. JsonDocument implementerar IDisposable.

I följande lista beskrivs kända ändringar:

Kategori

ASP.NET Core

Berörda API:er

Autentisering: OAuthHandler ExchangeCodeAsync-signaturen har ändrats

I ASP.NET Core 3.0 ändrades signaturen OAuthHandler.ExchangeCodeAsync för från:

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

Till:

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

Version introducerad

3,0

Gammalt beteende

Strängarna code och redirectUri skickades som separata argument.

Nytt beteende

Code och RedirectUri är egenskaper på OAuthCodeExchangeContext som kan anges via OAuthCodeExchangeContext konstruktorn. Den nya OAuthCodeExchangeContext typen är det enda argumentet som skickas till OAuthHandler.ExchangeCodeAsync.

Orsak till ändringen

Den här ändringen gör att ytterligare parametrar kan tillhandahållas på ett icke-icke-bakåtkompatibelt sätt. Du behöver inte skapa nya ExchangeCodeAsync överlagringar.

Konstruera en OAuthCodeExchangeContext med lämpliga code värden och redirectUri värden. En AuthenticationProperties instans måste anges. Den här enskilda OAuthCodeExchangeContext instansen kan skickas till i stället för OAuthHandler.ExchangeCodeAsync flera argument.

Kategori

ASP.NET Core

Berörda API:er

OAuthHandler<TOptions>.ExchangeCodeAsync(String, String)

Auktorisering: Överlagring av AddAuthorization har flyttats till en annan sammansättning

De kärnmetoder AddAuthorization som användes för att finnas i Microsoft.AspNetCore.Authorization har bytt namn till AddAuthorizationCore. De gamla AddAuthorization metoderna finns fortfarande, men finns i sammansättningen i Microsoft.AspNetCore.Authorization.Policy stället. Appar som använder båda metoderna bör inte se någon inverkan. Observera att Microsoft.AspNetCore.Authorization.Policy nu levereras i det delade ramverket i stället för ett fristående paket enligt beskrivningen i Delat ramverk: Sammansättningar som tagits bort från Microsoft.AspNetCore.App.

Version introducerad

3,0

Gammalt beteende

AddAuthorization metoder fanns i Microsoft.AspNetCore.Authorization.

Nytt beteende

AddAuthorization metoder finns i Microsoft.AspNetCore.Authorization.Policy. AddAuthorizationCore är det nya namnet på de gamla metoderna.

Orsak till ändringen

AddAuthorization är ett bättre metodnamn för att lägga till alla vanliga tjänster som behövs för auktorisering.

Lägg antingen till en referens till Microsoft.AspNetCore.Authorization.Policy eller använd AddAuthorizationCore i stället.

Kategori

ASP.NET Core

Berörda API:er

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

Auktorisering: IAllowAnonymous har tagits bort från AuthorizationFilterContext.Filters

Från och med ASP.NET Core 3.0 lägger MVC inte till AllowAnonymousFilters för [AllowAnonymous] -attribut som identifierades på kontrollanter och åtgärdsmetoder. Den här ändringen åtgärdas lokalt för derivat av AuthorizeAttribute, men det är en icke-bakåtkompatibel ändring för IAsyncAuthorizationFilter och IAuthorizationFilter implementeringar. Sådana implementeringar omslutna i ett [TypeFilter] -attribut är ett populärt sätt som stöds för att uppnå starkt skrivskyddad, attributbaserad auktorisering när både konfiguration och beroendeinmatning krävs.

Version introducerad

3,0

Gammalt beteende

IAllowAnonymous visades i samlingen AuthorizationFilterContext.Filters . Testning av gränssnittets närvaro var en giltig metod för att åsidosätta eller inaktivera filtret på enskilda kontrollantmetoder.

Nytt beteende

IAllowAnonymous visas inte längre i AuthorizationFilterContext.Filters samlingen. IAsyncAuthorizationFilter implementeringar som är beroende av det gamla beteendet orsakar vanligtvis tillfälliga HTTP 401-otillåtna eller HTTP 403-otillåtna svar.

Orsak till ändringen

En ny strategi för slutpunktsroutning introducerades i ASP.NET Core 3.0.

Sök efter slutpunktsmetadata för IAllowAnonymous. Till exempel:

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

Ett exempel på den här tekniken visas i den här Metoden HasAllowAnonymous.

Kategori

ASP.NET Core

Berörda API:er

Ingen

Auktorisering: IAuthorizationPolicyProvider-implementeringar kräver ny metod

I ASP.NET Core 3.0 lades en ny GetFallbackPolicyAsync metod till i IAuthorizationPolicyProvider. Den här återställningsprincipen används av mellanprogrammet för auktorisering när ingen princip har angetts.

Mer information finns i dotnet/aspnetcore#9759.

Version introducerad

3,0

Gammalt beteende

Implementeringar av IAuthorizationPolicyProvider krävde GetFallbackPolicyAsync ingen metod.

Nytt beteende

Implementeringar av IAuthorizationPolicyProvider kräver en GetFallbackPolicyAsync metod.

Orsak till ändringen

En ny metod behövdes för att den nya AuthorizationMiddleware ska kunna användas när ingen princip har angetts.

Lägg till metoden i GetFallbackPolicyAsync implementeringarna av IAuthorizationPolicyProvider.

Kategori

ASP.NET Core

Berörda API:er

Microsoft.AspNetCore.Authorization.IAuthorizationPolicyProvider

Cachelagring: Egenskapen CompactOnMemoryPressure har tagits bort

Versionen ASP.NET Core 3.0 tog bort föråldrade API:er för MemoryCacheOptions.

Ändra beskrivning

Den här ändringen är en uppföljning till aspnet/Cachelagring#221. Mer information finns i dotnet/extensions#1062.

Version introducerad

3,0

Gammalt beteende

MemoryCacheOptions.CompactOnMemoryPressure egenskapen var tillgänglig.

Nytt beteende

Egenskapen MemoryCacheOptions.CompactOnMemoryPressure har tagits bort.

Orsak till ändringen

Att komprimera cacheminnet automatiskt orsakade problem. För att undvika oväntat beteende bör cachen bara komprimeras när det behövs.

Komprimera cachen genom att nedarbeta till MemoryCache och anropa Compact vid behov.

Kategori

ASP.NET Core

Berörda API:er

MemoryCacheOptions.CompactOnMemoryPressure

Cachelagring: Microsoft.Extensions. Cachelagring. SqlServer använder nytt SqlClient-paket

Paketet Microsoft.Extensions.Caching.SqlServer använder det nya Microsoft.Data.SqlClient paketet i stället System.Data.SqlClient för paketet. Den här ändringen kan orsaka mindre beteendemässiga icke-bakåtkompatibla ändringar. Mer information finns i Introduktion till nya Microsoft.Data.SqlClient.

Version introducerad

3,0

Gammalt beteende

Paketet Microsoft.Extensions.Caching.SqlServer använde System.Data.SqlClient paketet.

Nytt beteende

Microsoft.Extensions.Caching.SqlServer använder nu paketet Microsoft.Data.SqlClient .

Orsak till ändringen

Microsoft.Data.SqlClient är ett nytt paket som är byggt av System.Data.SqlClient. Det är där allt nytt funktionsarbete kommer att göras från och med nu.

Kunder bör inte behöva oroa sig för den här icke-bakåtkompatibla ändringen om de inte använder typer som returneras av Microsoft.Extensions.Caching.SqlServer paketet och gjuter dem till System.Data.SqlClient typer. Om någon till exempel kastade en DbConnection till den gamla Sql Anslut ion-typen, skulle de behöva ändra casten till den nya Microsoft.Data.SqlClient.SqlConnection typen.

Kategori

ASP.NET Core

Berörda API:er

Ingen

Cachelagring: Svar Cachelagring "pubternal"-typer har ändrats till interna

I ASP.NET Core 3.0 har "pubternal"-typerna i ResponseCaching ändrats till internal.

Dessutom läggs standardimplementeringar av IResponseCachingPolicyProvider och IResponseCachingKeyProvider inte längre till i tjänster som en del av AddResponseCaching metoden.

Ändra beskrivning

I ASP.NET Core deklareras "pubternal"-typer som public men finns i ett namnområdessuffix med .Internal. Även om dessa typer är offentliga har de ingen supportprincip och kan komma att ändras. Tyvärr har oavsiktlig användning av dessa typer varit vanligt, vilket resulterar i icke-bakåtkompatibla ändringar i dessa projekt och begränsar möjligheten att underhålla ramverket.

Version introducerad

3,0

Gammalt beteende

Dessa typer var offentligt synliga, men stöds inte.

Nytt beteende

Dessa typer är nu internal.

Orsak till ändringen

Omfånget internal återspeglar bättre principen som inte stöds.

Kopiera typer som används av din app eller ditt bibliotek.

Kategori

ASP.NET Core

Berörda API:er

Dataskydd: DataProtection.Blobs använder nya Azure Storage-API:er

Azure.Extensions.AspNetCore.DataProtection.Blobsberor på Azure Storage-biblioteken. Biblioteken bytte namn på sina sammansättningar, paket och namnområden. Från och med ASP.NET Core 3.0 Azure.Extensions.AspNetCore.DataProtection.Blobs använder du de nya Azure.Storage.PREFIX-API:erna och paketen.

Om du vill ha frågor om Azure Storage-API:er använder du https://github.com/Azure/azure-storage-net. Information om det här problemet finns i dotnet/aspnetcore#19570.

Version introducerad

3,0

Gammalt beteende

Paketet refererade till NuGet-paketet WindowsAzure.Storage . Paketet refererar till NuGet-paketet Microsoft.Azure.Storage.Blob .

Nytt beteende

Paketet refererar till NuGet-paketet Azure.Storage.Blob .

Orsak till ändringen

Med den här ändringen kan Azure.Extensions.AspNetCore.DataProtection.Blobs du migrera till de rekommenderade Azure Storage-paketen.

Om du fortfarande behöver använda äldre Azure Storage-API:er med ASP.NET Core 3.0 lägger du till ett direkt beroende till paketet WindowsAzure.Storage eller Microsoft.Azure.Storage. Det här paketet kan installeras tillsammans med de nya Azure.Storage API:erna.

I många fall innebär uppgraderingen endast att du ändrar using instruktionerna så att de nya namnrymderna används:

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

Kategori

ASP.NET Core

Berörda API:er

Ingen

Värd: AspNetCoreModule V1 har tagits bort från Windows Hosting Bundle

Från och med ASP.NET Core 3.0 innehåller Windows Hosting Bundle inte AspNetCoreModule (ANCM) V1.

ANCM V2 är bakåtkompatibelt med ANCM OutOfProcess och rekommenderas för användning med ASP.NET Core 3.0-appar.

Mer information finns i dotnet/aspnetcore#7095.

Version introducerad

3,0

Gammalt beteende

ANCM V1 ingår i Windows-värdpaketet.

Nytt beteende

ANCM V1 ingår inte i Windows-värdpaketet.

Orsak till ändringen

ANCM V2 är bakåtkompatibelt med ANCM OutOfProcess och rekommenderas för användning med ASP.NET Core 3.0-appar.

Använd ANCM V2 med ASP.NET Core 3.0-appar.

Om ANCM V1 krävs kan det installeras med hjälp av ASP.NET Core 2.1 eller 2.2 Windows Hosting Bundle.

Den här ändringen bryter ASP.NET Core 3.0-appar som:

  • Uttryckligen valt att använda ANCM V1 med <AspNetCoreModuleName>AspNetCoreModule</AspNetCoreModuleName>.
  • Ha en anpassad web.config-fil med <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />.

Kategori

ASP.NET Core

Berörda API:er

Ingen

Värd: Allmän värd begränsar startkonstruktorinmatning

De enda typer som den generiska värden stöder för Startup klasskonstruktorinmatning är IHostEnvironment, IWebHostEnvironmentoch IConfiguration. Appar som använder WebHost påverkas inte.

Ändra beskrivning

Före ASP.NET Core 3.0 kan konstruktorinmatning användas för godtyckliga typer i Startup klassens konstruktor. I ASP.NET Core 3.0 omplatformades webbstacken till det allmänna värdbiblioteket. Du kan se ändringen i Program.cs-filen för mallarna:

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 använder en di-container (dependency injection) för att skapa appen. WebHost använder två containrar: en för värden och en för appen. Därför Startup stöder konstruktorn inte längre anpassad tjänstinmatning. Endast IHostEnvironment, IWebHostEnvironment, och IConfiguration kan matas in. Den här ändringen förhindrar DI-problem, till exempel duplicerade skapande av en singleton-tjänst.

Version introducerad

3,0

Orsak till ändringen

Den här ändringen är en följd av att webbstacken har omformats till det allmänna värdbiblioteket.

Mata in tjänster i metodsignaturen Startup.Configure . Till exempel:

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

Kategori

ASP.NET Core

Berörda API:er

Ingen

Värd: HTTPS-omdirigering aktiverad för IIS-appar utan processer

Version 13.0.19218.0 av ASP.NET Core Module (ANCM) för värd via IIS out-of-process möjliggör en befintlig HTTPS-omdirigeringsfunktion för ASP.NET Core 3.0- och 2.2-appar.

Mer information finns i dotnet/AspNetCore#15243.

Version introducerad

3,0

Gammalt beteende

Projektmallen ASP.NET Core 2.1 introducerade först stöd för HTTPS-mellanprogramsmetoder som UseHttpsRedirection och UseHsts. Att aktivera HTTPS-omdirigering krävde tillägg av konfigurationen, eftersom appar under utveckling inte använder standardporten 443. HTTP Strict Transport Security (HSTS) är endast aktivt om begäran redan använder HTTPS. Localhost hoppas över som standard.

Nytt beteende

I ASP.NET Core 3.0 förbättrades IIS HTTPS-scenariot. Med förbättringen kan en app identifiera serverns HTTPS-portar och få det att UseHttpsRedirection fungera som standard. Den processbaserade komponenten utförde portidentifiering med IServerAddresses funktionen, som endast påverkar ASP.NET Core 3.0-appar eftersom det pågående biblioteket är versionshanterat med ramverket. Komponenten out-of-process ändrades för att automatiskt lägga till ASPNETCORE_HTTPS_PORT miljövariabeln. Den här ändringen påverkade både ASP.NET Core 2.2- och 3.0-appar eftersom out-of-process-komponenten delas globalt. ASP.NET Core 2.1-appar påverkas inte eftersom de använder en tidigare version av ANCM som standard.

Föregående beteende ändrades i ASP.NET Core 3.0.1 och 3.1.0 Preview 3 för att ändra beteendeändringarna i ASP.NET Core 2.x. Dessa ändringar påverkar bara IIS-appar som inte är i processen.

Som beskrivs ovan hade installationen av ASP.NET Core 3.0.0 bieffekten UseHttpsRedirection av att även aktivera mellanprogrammet i ASP.NET Core 2.x-appar. En ändring gjordes i ANCM i ASP.NET Core 3.0.1 och 3.1.0 Preview 3 så att installation av dem inte längre har den här effekten på ASP.NET Core 2.x-appar. Miljövariabeln ASPNETCORE_HTTPS_PORT som ANCM fyllde i i ASP.NET Core 3.0.0 ändrades till ASPNETCORE_ANCM_HTTPS_PORT i ASP.NET Core 3.0.1 och 3.1.0 Preview 3. UseHttpsRedirection uppdaterades också i dessa versioner för att förstå både de nya och gamla variablerna. ASP.NET Core 2.x uppdateras inte. Det innebär att den återgår till det tidigare beteendet att inaktiveras som standard.

Orsak till ändringen

Förbättrade funktioner i ASP.NET Core 3.0.

Ingen åtgärd krävs om du vill att alla klienter ska använda HTTPS. Gör något av följande för att tillåta att vissa klienter använder HTTP:

  • Ta bort anropen till UseHttpsRedirection och UseHsts från projektets Startup.Configure metod och distribuera om appen.

  • I filen web.config anger du ASPNETCORE_HTTPS_PORT miljövariabeln till en tom sträng. Den här ändringen kan ske direkt på servern utan att omdistribuera appen. Till exempel:

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

UseHttpsRedirection kan fortfarande vara:

  • Aktiveras manuellt i ASP.NET Core 2.x genom att ställa in ASPNETCORE_HTTPS_PORT miljövariabeln på lämpligt portnummer (443 i de flesta produktionsscenarier).
  • Inaktiverad i ASP.NET Core 3.x genom att ASPNETCORE_ANCM_HTTPS_PORT definiera med ett tomt strängvärde. Det här värdet anges på samma sätt som föregående ASPNETCORE_HTTPS_PORT exempel.

Datorer som kör ASP.NET Core 3.0.0-appar bör installera ASP.NET Core 3.0.1-körningen innan du installerar ASP.NET Core 3.1.0 Förhandsversion 3 ANCM. Detta säkerställer att fortsätter att UseHttpsRedirection fungera som förväntat för ASP.NET Core 3.0-appar.

I Azure App Service distribuerar ANCM enligt ett separat schema från körningen på grund av dess globala karaktär. ANCM distribuerades till Azure med dessa ändringar efter att ASP.NET Core 3.0.1 och 3.1.0 distribuerats.

Kategori

ASP.NET Core

Berörda API:er

HttpsPolicyBuilderExtensions.UseHttpsRedirection(IApplicationBuilder)

Värd: IHostingEnvironment- och IApplicationLifetime-typer markerade föråldrade och ersatta

Nya typer har introducerats för att ersätta befintliga IHostingEnvironment och IApplicationLifetime typer.

Version introducerad

3,0

Gammalt beteende

Det fanns två olika IHostingEnvironment typer från IApplicationLifetimeMicrosoft.Extensions.Hosting och Microsoft.AspNetCore.Hosting.

Nytt beteende

De gamla typerna har markerats som föråldrade och ersatta med nya typer.

Orsak till ändringen

När Microsoft.Extensions.Hosting introducerades i ASP.NET Core 2.1 kopierades vissa typer som IHostingEnvironment och IApplicationLifetime från Microsoft.AspNetCore.Hosting. Vissa ASP.NET Core 3.0-ändringar gör att appar inkluderar både namnrymderna Microsoft.Extensions.Hosting och Microsoft.AspNetCore.Hosting . All användning av dessa dubbletter orsakar ett "tvetydigt referensfel" när båda namnrymderna refereras.

Ersatte alla användningar av de gamla typerna med de nyligen introducerade typerna enligt nedan:

Föråldrade typer (varning):

Nya typer:

De nya IHostEnvironmentIsDevelopment metoderna och IsProduction tilläggsmetoderna Microsoft.Extensions.Hosting finns i namnområdet. Namnområdet kan behöva läggas till i projektet.

Kategori

ASP.NET Core

Berörda API:er

Värd: ObjectPoolProvider har tagits bort från WebHostBuilder-beroenden

Som en del av att göra ASP.NET Core mer betala för spel, ObjectPoolProvider togs bort från huvuduppsättningen av beroenden. Specifika komponenter som förlitar sig på ObjectPoolProvider lägger nu till det själva.

Mer information finns i dotnet/aspnetcore#5944.

Version introducerad

3,0

Gammalt beteende

WebHostBuilder tillhandahåller ObjectPoolProvider som standard i DI-containern.

Nytt beteende

WebHostBuilder tillhandahåller ObjectPoolProvider inte längre som standard i DI-containern.

Orsak till ändringen

Den här ändringen gjordes för att göra ASP.NET Core mer betala för spel.

Om komponenten kräver ObjectPoolProvidermåste den läggas till i dina beroenden IServiceCollectionvia .

Kategori

ASP.NET Core

Berörda API:er

Ingen

HTTP: Utökningsbarheten defaultHttpContext har tagits bort

Som en del av ASP.NET Core 3.0-prestandaförbättringar togs utökningsbarheten DefaultHttpContext bort. Klassen är nu sealed. Mer information finns i dotnet/aspnetcore#6504.

Om enhetstesterna använder använder Mock<DefaultHttpContext>du Mock<HttpContext> eller new DefaultHttpContext() i stället.

Mer information finns i dotnet/aspnetcore#6534.

Version introducerad

3,0

Gammalt beteende

Klasser kan härledas från DefaultHttpContext.

Nytt beteende

Klasser kan inte härledas från DefaultHttpContext.

Orsak till ändringen

Utökningsbarheten tillhandahölls ursprungligen för att tillåta poolning av HttpContext, men det introducerade onödig komplexitet och hindrade andra optimeringar.

Om du använder Mock<DefaultHttpContext> i enhetstesterna börjar du använda Mock<HttpContext> i stället.

Kategori

ASP.NET Core

Berörda API:er

Microsoft.AspNetCore.Http.DefaultHttpContext

HTTP: HeaderNames-konstanter har ändrats till statiska skrivskyddade

Från och med ASP.NET Core 3.0 Preview 5 ändrades fälten i Microsoft.Net.Http.Headers.HeaderNames från const till static readonly.

Mer information finns i dotnet/aspnetcore#9514.

Version introducerad

3,0

Gammalt beteende

Dessa fält brukade vara const.

Nytt beteende

Dessa fält är nu static readonly.

Orsak till ändringen

Ändringen:

  • Förhindrar att värdena bäddas in över sammansättningsgränser, vilket möjliggör värdekorrigeringar efter behov.
  • Möjliggör snabbare referensjämlikhetskontroller.

Kompilera om mot 3.0. Källkod med hjälp av dessa fält på följande sätt kan inte längre göra det:

  • Som ett attributargument
  • Som en case i en switch instruktion
  • När du definierar en annan const

Om du vill kringgå den icke-bakåtkompatibla ändringen växlar du till att använda självdefinierade rubriknamnskonstanter eller strängliteraler.

Kategori

ASP.NET Core

Berörda API:er

Microsoft.Net.Http.Headers.HeaderNames

HTTP: Infrastrukturändringar för svarstext

Infrastrukturen som stöder en HTTP-svarstext har ändrats. Om du använder HttpResponse direkt bör du inte behöva göra några kodändringar. Läs vidare om du omsluter eller ersätter HttpResponse.Body eller kommer åt HttpContext.Features.

Version introducerad

3,0

Gammalt beteende

Det fanns tre API:er associerade med HTTP-svarstexten:

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

Nytt beteende

Om du ersätter HttpResponse.Bodyersätter den hela IHttpResponseBodyFeature med en omslutning runt din angivna ström med hjälp StreamResponseBodyFeature av för att tillhandahålla standardimplementeringar för alla förväntade API:er. Om du ställer in den ursprungliga strömmen återställs den här ändringen.

Orsak till ändringen

Motivationen är att kombinera API:er för svarstext till ett enda nytt funktionsgränssnitt.

Använd IHttpResponseBodyFeature där du tidigare använde IHttpResponseFeature.Body, IHttpSendFileFeature, eller IHttpBufferingFeature.

Kategori

ASP.NET Core

Berörda API:er

SameSite är ett alternativ för cookies som kan hjälpa till att minimera vissa CSRF-attacker (Cross-Site Request Forgery). När det här alternativet ursprungligen introducerades användes inkonsekventa standardvärden för olika ASP.NET Core-API:er. Inkonsekvensen har lett till förvirrande resultat. Från och med ASP.NET Core 3.0 är dessa standardvärden bättre justerade. Du måste välja den här funktionen per komponent.

Version introducerad

3,0

Gammalt beteende

Liknande ASP.NET Core-API:er använde olika standardvärden SameSiteMode . Ett exempel på inkonsekvensen visas i HttpResponse.Cookies.Append(String, String) och HttpResponse.Cookies.Append(String, String, CookieOptions), som standardvärdet SameSiteMode.None och SameSiteMode.Lax, respektive.

Nytt beteende

Alla berörda API:er är som standard SameSiteMode.None.

Orsak till ändringen

Standardvärdet ändrades för att göra SameSite en opt-in-funktion.

Varje komponent som genererar cookies måste avgöra om SameSite det är lämpligt för dess scenarier. Granska din användning av de berörda API:erna och konfigurera om SameSite efter behov.

Kategori

ASP.NET Core

Berörda API:er

HTTP: Synkron I/O inaktiverad på alla servrar

Från och med ASP.NET Core 3.0 inaktiveras synkrona serveråtgärder som standard.

Ändra beskrivning

AllowSynchronousIO är ett alternativ på varje server som aktiverar eller inaktiverar synkrona I/O-API:er som HttpRequest.Body.Read, HttpResponse.Body.Writeoch Stream.Flush. Dessa API:er har länge varit en källa till trådsvältning och applåsningar. Från och med ASP.NET Core 3.0 Preview 3 inaktiveras dessa synkrona åtgärder som standard.

Berörda servrar:

  • Kestrel
  • HttpSys
  • IIS pågår
  • TestServer

Förvänta dig fel som liknar:

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

Varje server har ett AllowSynchronousIO alternativ som styr det här beteendet och standardvärdet för alla är nu false.

Beteendet kan också åsidosättas per begäran som en tillfällig åtgärd. Till exempel:

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

Om du har problem med att en TextWriter eller annan ström anropar ett synkront API i anropar du det nya DisposeAsync API:et i Disposestället.

Mer information finns i dotnet/aspnetcore#7644.

Version introducerad

3,0

Gammalt beteende

HttpRequest.Body.Read, HttpResponse.Body.Writeoch Stream.Flush tilläts som standard.

Nytt beteende

Dessa synkrona API:er tillåts inte som standard:

Förvänta dig fel som liknar:

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

Orsak till ändringen

Dessa synkrona API:er har länge varit en källa till trådsvältning och applåsningar. Från och med ASP.NET Core 3.0 Preview 3 inaktiveras synkrona åtgärder som standard.

Använd de asynkrona versionerna av metoderna. Beteendet kan också åsidosättas per begäran som en tillfällig åtgärd.

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

Kategori

ASP.NET Core

Berörda API:er

Identitet: Överlagring av AddDefaultUI-metod har tagits bort

Från och med ASP.NET Core 3.0 finns inte längre överlagring av metoden IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework).

Version introducerad

3,0

Orsak till ändringen

Den här ändringen var ett resultat av införandet av funktionen för statiska webbtillgångar.

Anropa IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder) i stället för den överlagring som tar två argument. Om du använder Bootstrap 3 lägger du också till följande rad i ett <PropertyGroup> element i projektfilen:

<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>

Kategori

ASP.NET Core

Berörda API:er

IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework)

Identitet: Standardversionen av användargränssnittet för Bootstrap har ändrats

Från och med ASP.NET Core 3.0 använder identitetsgränssnittet standardversion 4 av Bootstrap.

Version introducerad

3,0

Gammalt beteende

Metodanropet services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(); var detsamma som services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap3);

Nytt beteende

Metodanropet services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(); är detsamma som services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap4);

Orsak till ändringen

Bootstrap 4 släpptes under ASP.NET Core 3.0-tidsram.

Du påverkas av den här ändringen om du använder standardgränssnittet för identitet och har lagt till det i Startup.ConfigureServices som du ser i följande exempel:

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

Välj en av följande åtgärder:

  • Migrera din app för att använda Bootstrap 4 med hjälp av deras migreringsguide.

  • Uppdatera Startup.ConfigureServices för att framtvinga användning av Bootstrap 3. Till exempel:

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

Kategori

ASP.NET Core

Berörda API:er

Ingen

Identitet: SignInAsync genererar undantag för oautentiserad identitet

Som standard SignInAsync genererar ett undantag för huvudnamn/identiteter där IsAuthenticated är false.

Version introducerad

3,0

Gammalt beteende

SignInAsync accepterar alla huvudnamn/identiteter, inklusive identiteter där IsAuthenticated är false.

Nytt beteende

Som standard SignInAsync genererar ett undantag för huvudnamn/identiteter där IsAuthenticated är false. Det finns en ny flagga för att förhindra det här beteendet, men standardbeteendet har ändrats.

Orsak till ändringen

Det gamla beteendet var problematiskt eftersom dessa huvudnamn som standard avvisades av [Authorize] / RequireAuthenticatedUser().

I ASP.NET Core 3.0 Preview 6 finns det en RequireAuthenticatedSignIn flagga på AuthenticationOptions som standard true . Ange den här flaggan till false för att återställa det gamla beteendet.

Kategori

ASP.NET Core

Berörda API:er

Ingen

Identitet: SignInManager-konstruktorn accepterar ny parameter

Från och med ASP.NET Core 3.0 lades en ny IUserConfirmation<TUser> parameter till i SignInManager konstruktorn. Mer information finns i dotnet/aspnetcore#8356.

Version introducerad

3,0

Orsak till ändringen

Motiveringen till ändringen var att lägga till stöd för nya e-post-/bekräftelseflöden i identiteten.

Om du skapar en SignInManagermanuellt anger du en implementering av IUserConfirmation eller hämtar en från beroendeinmatningen som ska tillhandahållas.

Kategori

ASP.NET Core

Berörda API:er

SignInManager<TUser>

Identitet: Användargränssnittet använder funktionen för statiska webbtillgångar

ASP.NET Core 3.0 introducerade en funktion för statiska webbtillgångar och Identity UI har antagit den.

Ändra beskrivning

Som ett resultat av att identitetsgränssnittet implementerar funktionen för statiska webbtillgångar:

  • Du kan välja ramverk med hjälp IdentityUIFrameworkVersion av egenskapen i projektfilen.
  • Bootstrap 4 är standardgränssnittsramverket för identitetsgränssnittet. Bootstrap 3 har nått slutet av livet och du bör överväga att migrera till en version som stöds.

Version introducerad

3,0

Gammalt beteende

Standardgränssnittsramverket för identitetsgränssnittet var Bootstrap 3. UI-ramverket kan konfigureras med hjälp av en parameter till metodanropet AddDefaultUI i Startup.ConfigureServices.

Nytt beteende

Standardgränssnittsramverket för identitetsgränssnittet är Bootstrap 4. UI-ramverket måste konfigureras i projektfilen i stället för i metodanropet AddDefaultUI .

Orsak till ändringen

Införandet av funktionen för statiska webbtillgångar kräver att UI Framework-konfigurationen flyttas till MSBuild. Beslutet om vilket ramverk som ska bäddas in är ett beslut om byggtid, inte ett körningsbeslut.

Granska webbplatsgränssnittet för att se till att de nya Bootstrap 4-komponenterna är kompatibla. Om det behövs använder du IdentityUIFrameworkVersion egenskapen MSBuild för att återgå till Bootstrap 3. Lägg till egenskapen i ett <PropertyGroup> element i projektfilen:

<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>

Kategori

ASP.NET Core

Berörda API:er

IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder, UIFramework)

Kestrel: Anslut ionskort har tagits bort

Som en del av övergången till att flytta "pubternal" API:er till public, togs begreppet en IConnectionAdapter bort från Kestrel. Anslut ionskort ersätts med anslutningsmellanprogram (liknar HTTP-mellanprogram i ASP.NET Core-pipelinen, men för anslutningar på lägre nivå). HTTPS och anslutningsloggning har flyttats från anslutningskort till anslutningsmellanprogram. Dessa tilläggsmetoder bör fortsätta att fungera sömlöst, men implementeringsinformationen har ändrats.

Mer information finns i dotnet/aspnetcore#11412. Diskussion finns i dotnet/aspnetcore#11475.

Version introducerad

3,0

Gammalt beteende

Kestrel-utökningskomponenter skapades med hjälp av IConnectionAdapter.

Nytt beteende

Kestrel-utökningskomponenter skapas som mellanprogram.

Orsak till ändringen

Den här ändringen är avsedd att ge en mer flexibel utökningsarkitektur.

Konvertera alla implementeringar av IConnectionAdapter för att använda det nya mellanprogramsmönstret som du ser här.

Kategori

ASP.NET Core

Berörda API:er

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

Kestrel: Tom HTTPS-sammansättning har tagits bort

Sammansättningen Microsoft.AspNetCore.Server.Kestrel.Https har tagits bort.

Version introducerad

3,0

Orsak till ändringen

I ASP.NET Core 2.1 flyttades innehållet Microsoft.AspNetCore.Server.Kestrel.Https i till Microsoft.AspNetCore.Server.Kestrel.Core. Den här ändringen gjordes på ett icke-icke-banbrytande sätt med hjälp av [TypeForwardedTo] attribut.

  • Bibliotek som refererar Microsoft.AspNetCore.Server.Kestrel.Https till 2.0 bör uppdatera alla ASP.NET Core-beroenden till 2.1 eller senare. Annars kan de brytas när de läses in i en ASP.NET Core 3.0-app.
  • Appar och bibliotek som riktar sig till ASP.NET Core 2.1 och senare bör ta bort alla direkta referenser till Microsoft.AspNetCore.Server.Kestrel.Https NuGet-paketet.

Kategori

ASP.NET Core

Berörda API:er

Ingen

Kestrel: Begär att trailerhuvuden flyttas till ny samling

I tidigare versioner lade Kestrel till HTTP/1.1 segmenterade trailerhuvuden i samlingen med begärandehuvuden när begärandetexten lästes till slutet. Det här beteendet orsakade oro för tvetydighet mellan huvuden och trailers. Beslutet togs att flytta släpvagnarna till en ny kollektion.

HTTP/2-begärandetrailrar var inte tillgängliga i ASP.NET Core 2.2 men är nu också tillgängliga i den här nya samlingen i ASP.NET Core 3.0.

Nya metoder för förfrågningstillägg har lagts till för åtkomst till dessa släpvagnar.

HTTP/1.1-trailers är tillgängliga när hela begärandetexten har lästs.

HTTP/2-trailers är tillgängliga när de tas emot från klienten. Klienten skickar inte trailers förrän hela begärandetexten har buffrats av servern. Du kan behöva läsa begärandetexten för att frigöra buffertutrymme. Släpvagnar är alltid tillgängliga om du läser begärandetexten till slutet. Släpvagnarna markerar kroppens ände.

Version introducerad

3,0

Gammalt beteende

Begärandehuvuden för trailer läggs till i HttpRequest.Headers samlingen.

Nytt beteende

Begärandehuvuden HttpRequest.Headers för trailer finns inte i samlingen. Använd följande tilläggsmetoder för HttpRequest att komma åt dem:

  • GetDeclaredTrailers() - Hämtar begäran "Trailer"-rubriken som listar vilka trailers som ska förväntas efter brödtexten.
  • SupportsTrailers() – Anger om begäran har stöd för att ta emot trailerhuvuden.
  • CheckTrailersAvailable() – Avgör om begäran stöder släpvagnar och om de är tillgängliga för läsning.
  • GetTrailer(string trailerName) – Hämtar den begärda avslutande rubriken från svaret.

Orsak till ändringen

Trailers är en viktig funktion i scenarier som gRPC. Att slå samman trailers för att begära rubriker var förvirrande för användarna.

Använd de släpvagnsrelaterade tilläggsmetoderna på HttpRequest för att få åtkomst till släpvagnar.

Kategori

ASP.NET Core

Berörda API:er

HttpRequest.Headers

Kestrel: Transportabstraktioner har tagits bort och offentliggjorts

Som en del av att flytta från "pubternal" API:er exponeras Kestrel-API:erna för transportskiktet som ett offentligt gränssnitt i Microsoft.AspNetCore.Connections.Abstractions biblioteket.

Version introducerad

3,0

Gammalt beteende

  • Transportrelaterade abstraktioner fanns tillgängliga i biblioteket Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions .
  • Egenskapen ListenOptions.NoDelay var tillgänglig.

Nytt beteende

  • Gränssnittet IConnectionListener introducerades i Microsoft.AspNetCore.Connections.Abstractions biblioteket för att exponera de mest använda funktionerna från ...Transport.Abstractions biblioteket.
  • NoDelay Är nu tillgänglig i transportalternativ (LibuvTransportOptions och SocketTransportOptions).
  • SchedulingMode är inte längre tillgängligt.

Orsak till ändringen

ASP.NET Core 3.0 har flyttats från "pubternal" API:er.

Kategori

ASP.NET Core

Berörda API:er

Ingen

Lokalisering: ResourceManagerWithCultureStringLocalizer och WithCulture markerade som föråldrade

Klassen ResourceManagerWithCultureStringLocalizer och WithCulture-gränssnittsmedlemmen är ofta förvirringskällor för lokaliseringsanvändare, särskilt när de skapar en egen IStringLocalizer implementering. Dessa objekt ger användaren intrycket att en IStringLocalizer instans är "per språk, per resurs". I verkligheten bör instanserna bara vara "per resurs". Det språk som söks efter bestäms av CultureInfo.CurrentUICulture vid körningstillfället. För att eliminera förvirringskällan har API:erna markerats som föråldrade i ASP.NET Core 3.0 Preview 3. API:erna tas bort i en framtida version.

Sammanhang finns i dotnet/aspnetcore#3324. Mer information finns i dotnet/aspnetcore#7756.

Version introducerad

3,0

Gammalt beteende

Metoderna har inte markerats som Obsolete.

Nytt beteende

Metoderna är markerade Obsolete.

Orsak till ändringen

API:erna representerade ett användningsfall som inte rekommenderas. Det rådde förvirring kring utformningen av lokaliseringen.

Rekommendationen är att använda ResourceManagerStringLocalizer i stället. Låt kulturen anges av CurrentCulture. Om det inte är ett alternativ skapar och använder du en kopia av ResourceManagerWithCultureStringLocalizer.

Kategori

ASP.NET Core

Berörda API:er

Loggning: DebugLogger-klassen har gjorts intern

Innan ASP.NET Core 3.0 DebugLoggervar publicåtkomstmodifieraren . I ASP.NET Core 3.0 ändrades åtkomstmodifieraren till internal.

Version introducerad

3,0

Orsak till ändringen

Ändringen görs för att:

  • Framtvinga konsekvens med andra loggningsimplementeringar, till exempel ConsoleLogger.
  • Minska API-ytan.

AddDebugILoggingBuilder Använd tilläggsmetoden för att aktivera felsökningsloggning. DebugLoggerProvider är också fortfarande public i händelse av att tjänsten måste registreras manuellt.

Kategori

ASP.NET Core

Berörda API:er

Microsoft.Extensions.Logging.Debug.DebugLogger

MVC: Async-suffix trimmat från kontrollantens åtgärdsnamn

Som en del av hanteringen av dotnet/aspnetcore#4849 trimmar ASP.NET Core MVC suffixet Async från åtgärdsnamn som standard. Från och med ASP.NET Core 3.0 påverkar den här ändringen både routning och länkgenerering.

Version introducerad

3,0

Gammalt beteende

Överväg följande ASP.NET Core MVC-styrenhet:

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

Åtgärden kan dirigeras via Product/ListAsync. Länkgenerering kräver att du anger suffixet Async . Till exempel:

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

Nytt beteende

I ASP.NET Core 3.0 kan åtgärden dirigeras via Product/List. Länkgenereringskoden bör utelämna suffixet Async . Till exempel:

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

Den här ändringen påverkar inte namn som anges med hjälp av attributet [ActionName] . Det nya beteendet kan inaktiveras genom att ange MvcOptions.SuppressAsyncSuffixInActionNames i falseStartup.ConfigureServices:

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

Orsak till ändringen

Enligt konventionen är asynkrona .NET-metoder suffix med Async. Men när en metod definierar en MVC-åtgärd är det inte önskvärt att använda suffixet Async .

Om din app är beroende av MVC-åtgärder som bevarar namnets Async suffix väljer du någon av följande åtgärder:

  • Använd attributet [ActionName] för att bevara det ursprungliga namnet.
  • Inaktivera namnbytet helt genom att ange MvcOptions.SuppressAsyncSuffixInActionNames i Startup.ConfigureServicesfalse :
services.AddMvc(options =>
{
   options.SuppressAsyncSuffixInActionNames = false;
});

Kategori

ASP.NET Core

Berörda API:er

Ingen

MVC: JsonResult har flyttats till Microsoft.AspNetCore.Mvc.Core

JsonResult har flyttats till Microsoft.AspNetCore.Mvc.Core sammansättningen. Den här typen brukade definieras i Microsoft.AspNetCore.Mvc.Formatters.Json. Ett attribut på sammansättningsnivå [TypeForwardedTo] lades till för att Microsoft.AspNetCore.Mvc.Formatters.Json åtgärda problemet för de flesta användare. Appar som använder bibliotek från tredje part kan stöta på problem.

Version introducerad

3.0 Förhandsversion 6

Gammalt beteende

En app som använder ett 2,2-baserat bibliotek har skapats.

Nytt beteende

En app som använder ett 2,2-baserat bibliotek misslyckas med kompilering. Ett fel som innehåller en variant av följande text anges:

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'

Ett exempel på ett sådant problem finns i dotnet/aspnetcore#7220.

Orsak till ändringen

Ändringar på plattformsnivå i sammansättningen av ASP.NET Core enligt beskrivningen i aspnet/Announcements#325.

Bibliotek som kompilerats mot 2.2-versionen av Microsoft.AspNetCore.Mvc.Formatters.Json kan behöva kompileras om för att lösa problemet för alla konsumenter. Kontakta biblioteksförfattaren om det påverkas. Begär omkompilering av biblioteket för att rikta in sig på ASP.NET Core 3.0.

Kategori

ASP.NET Core

Berörda API:er

Microsoft.AspNetCore.Mvc.JsonResult

MVC: Förkompileringsverktyget är inaktuellt

I ASP.NET Core 1.1 Microsoft.AspNetCore.Mvc.Razor.ViewCompilation introducerades paketet (MVC-förkompileringsverktyget) för att lägga till stöd för publiceringstidskompilering av Razor-filer (.cshtml-filer ). I ASP.NET Core 2.1 introducerades Razor SDK för att utöka funktionerna i förkompileringsverktyget. Razor SDK har lagt till stöd för kompilering och publiceringstid av Razor-filer. SDK:t verifierar korrektheten i .cshtml-filer vid byggtiden och förbättrar starttiden för appen. Razor SDK är aktiverat som standard och ingen gest krävs för att börja använda det.

I ASP.NET Core 3.0 togs MVC-förkompileringsverktyget ASP.NET Core 1.1-eran bort. Tidigare paketversioner fortsätter att ta emot viktiga bugg- och säkerhetskorrigeringar i korrigeringsversionen.

Version introducerad

3,0

Gammalt beteende

Paketet Microsoft.AspNetCore.Mvc.Razor.ViewCompilation användes för att förkompilera MVC Razor-vyer.

Nytt beteende

Razor SDK har inbyggt stöd för den här funktionen. Paketet Microsoft.AspNetCore.Mvc.Razor.ViewCompilation uppdateras inte längre.

Orsak till ändringen

Razor SDK ger fler funktioner och verifierar korrektheten i .cshtml-filer vid byggtillfället. SDK:et förbättrar även appens starttid.

För användare av ASP.NET Core 2.1 eller senare uppdaterar du för att använda det interna stödet för förkompilering i Razor SDK. Om buggar eller saknade funktioner förhindrar migrering till Razor SDK öppnar du ett problem på dotnet/aspnetcore.

Kategori

ASP.NET Core

Berörda API:er

Ingen

MVC: "Pubternal"-typer har ändrats till interna

I ASP.NET Core 3.0 uppdaterades alla "pubternal"-typer i MVC till antingen public i ett namnområde som stöds eller internal efter behov.

Ändra beskrivning

I ASP.NET Core deklareras "pubternal"-typer som public men finns i ett .Internalnamnområde med -suffix. Även om dessa typer är publichar de ingen supportprincip och kan komma att ändras. Tyvärr har oavsiktlig användning av dessa typer varit vanligt, vilket resulterar i icke-bakåtkompatibla ändringar i dessa projekt och begränsar möjligheten att underhålla ramverket.

Version introducerad

3,0

Gammalt beteende

Vissa typer i MVC fanns public bara i ett .Internal namnområde. De här typerna hade ingen supportprincip och kan komma att ändras.

Nytt beteende

Alla sådana typer uppdateras antingen för att vara public i ett namnområde som stöds eller markeras som internal.

Orsak till ändringen

Oavsiktlig användning av "pubternal"-typerna har varit vanligt, vilket har resulterat i icke-bakåtkompatibla ändringar i dessa projekt och begränsar möjligheten att underhålla ramverket.

Om du använder typer som har blivit verkligt public och har flyttats till ett nytt namnområde som stöds uppdaterar du dina referenser så att de matchar de nya namnrymderna.

Om du använder typer som har markerats som internalmåste du hitta ett alternativ. De tidigare "pubternal"-typerna stöddes aldrig för offentligt bruk. Om det finns specifika typer i dessa namnområden som är viktiga för dina appar kan du skicka ett problem till dotnet/aspnetcore. Överväganden kan göras för att göra de begärda typerna public.

Kategori

ASP.NET Core

Berörda API:er

Den här ändringen innehåller typer i följande namnområden:

  • 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: Kompatibilitetsshim för webb-API har tagits bort

Från och med ASP.NET Core 3.0 Microsoft.AspNetCore.Mvc.WebApiCompatShim är paketet inte längre tillgängligt.

Ändra beskrivning

Microsoft.AspNetCore.Mvc.WebApiCompatShim Paketet (WebApiCompatShim) ger partiell kompatibilitet i ASP.NET Core med ASP.NET 4.x Web API 2 för att förenkla migreringen av befintliga webb-API-implementeringar till ASP.NET Core. Appar som använder WebApiCompatShim drar dock inte nytta av API-relaterade funktioner som levereras i de senaste ASP.NET Core-versionerna. Sådana funktioner omfattar förbättrad generering av Open API-specifikation, standardiserad felhantering och generering av klientkod. WebApiCompatShim togs bort för att bättre fokusera API-insatserna i 3.0. Befintliga appar som använder WebApiCompatShim ska migreras till den nyare [ApiController] modellen.

Version introducerad

3,0

Orsak till ändringen

Webb-API-kompatibilitetsshim var ett migreringsverktyg. Det begränsar användaråtkomsten till nya funktioner som läggs till i ASP.NET Core.

Ta bort användningen av denna shim och migrera direkt till liknande funktioner i själva ASP.NET Core.

Kategori

ASP.NET Core

Berörda API:er

Microsoft.AspNetCore.Mvc.WebApiCompatShim

Razor: RazorTemplateEngine API har tagits bort

API:et RazorTemplateEngine har tagits bort och ersatts med Microsoft.AspNetCore.Razor.Language.RazorProjectEngine.

Mer information finns i GitHub-problem med dotnet/aspnetcore#25215.

Version introducerad

3,0

Gammalt beteende

En mallmotor kan skapas och användas för att parsa och generera kod för Razor-filer.

Nytt beteende

RazorProjectEngine kan skapas och tillhandahålla samma typ av information som RazorTemplateEngine för att parsa och generera kod för Razor-filer. RazorProjectEngine ger också extra konfigurationsnivåer.

Orsak till ändringen

RazorTemplateEngine var alltför nära kopplat till de befintliga implementeringarna. Den här snäva kopplingen ledde till fler frågor när du försökte konfigurera en Razor-parsnings-/generationspipeline korrekt.

Använd RazorProjectEngine i stället för RazorTemplateEngine. Tänk på följande exempel.

Skapa och konfigurera 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
        });
Generera kod för en Razor-fil
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();

Kategori

ASP.NET Core

Berörda API:er

  • RazorTemplateEngine
  • RazorTemplateEngineOptions

Razor: Runtime-kompilering har flyttats till ett paket

Stöd för körningskompilering av Razor-vyer och Razor Pages har flyttats till ett separat paket.

Version introducerad

3,0

Gammalt beteende

Runtime-kompilering är tillgängligt utan att behöva ytterligare paket.

Nytt beteende

Funktionen har flyttats till paketet Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation .

Följande API:er var tidigare tillgängliga för Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions att stödja körningskompilering. API:erna är nu tillgängliga via Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation.MvcRazorRuntimeCompilationOptions.

  • RazorViewEngineOptions.FileProviders är nu MvcRazorRuntimeCompilationOptions.FileProviders
  • RazorViewEngineOptions.AdditionalCompilationReferences är nu MvcRazorRuntimeCompilationOptions.AdditionalReferencePaths

Dessutom Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions.AllowRecompilingViewsOnFileChange har tagits bort. Omkompilering av filändringar aktiveras som standard genom att Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation referera till paketet.

Orsak till ändringen

Den här ändringen var nödvändig för att ta bort det delade ASP.NET Core-ramverksberoendet för Roslyn.

Appar som kräver körningskompilering eller omkompilering av Razor-filer bör utföra följande steg:

  1. Lägg till en referens till Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation paketet.

  2. Uppdatera projektets Startup.ConfigureServices metod så att den innehåller ett anrop till AddRazorRuntimeCompilation. Till exempel:

    services.AddMvc()
    .AddRazorRuntimeCompilation();

Kategori

ASP.NET Core

Berörda API:er

Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions

Sessionstillstånd: Föråldrade API:er har tagits bort

Föråldrade API:er för att konfigurera sessionscookies har tagits bort. Mer information finns i aspnet/Announcements#257.

Version introducerad

3,0

Orsak till ändringen

Den här ändringen tillämpar konsekvens mellan API:er för att konfigurera funktioner som använder cookies.

Migrera användningen av de borttagna API:erna till deras nyare ersättningar. Överväg följande exempel i 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;
    });
}

Kategori

ASP.NET Core

Berörda API:er

Delat ramverk: Sammansättningar som tagits bort från Microsoft.AspNetCore.App

Från och med ASP.NET Core 3.0 innehåller det delade ASP.NET Core-ramverket (Microsoft.AspNetCore.App) endast sammansättningar från första part som är fullt utvecklade, stöds och kan användas av Microsoft.

Ändra beskrivning

Tänk på förändringen som omdefiniering av gränser för ASP.NET Core"-plattformen. Det delade ramverket kan skapas av vem som helst via GitHub och fortsätter att erbjuda de befintliga fördelarna med delade .NET Core-ramverk till dina appar. Vissa fördelar är mindre distributionsstorlek, centraliserad korrigering och snabbare starttid.

Som en del av ändringen introduceras några viktiga icke-bakåtkompatibla ändringar i Microsoft.AspNetCore.App.

Version introducerad

3,0

Gammalt beteende

Projekt som refereras Microsoft.AspNetCore.App via ett <PackageReference> element i projektfilen.

Dessutom Microsoft.AspNetCore.App innehöll följande underkomponenter:

  • Json.NET (Newtonsoft.Json)
  • Entity Framework Core (sammansättningar med prefixet Microsoft.EntityFrameworkCore.)
  • Roslyn (Microsoft.CodeAnalysis)

Nytt beteende

En referens till Microsoft.AspNetCore.App kräver inte längre ett <PackageReference> element i projektfilen. .NET Core SDK stöder ett nytt element med namnet <FrameworkReference>, som ersätter användningen av <PackageReference>.

Mer information finns i dotnet/aspnetcore#3612.

Entity Framework Core levereras som NuGet-paket. Den här ändringen justerar leveransmodellen med alla andra dataåtkomstbibliotek på .NET. Det ger Entity Framework Core den enklaste vägen för att fortsätta att förnya samtidigt som du stöder de olika .NET-plattformarna. Flytten av Entity Framework Core från det delade ramverket påverkar inte dess status som ett Microsoft-utvecklat, stödt och användbart bibliotek. .NET Core-supportprincipen fortsätter att täcka den.

Json.NET och Entity Framework Core fortsätter att arbeta med ASP.NET Core. De kommer dock inte att ingå i det delade ramverket.

Mer information finns i Framtiden för JSON i .NET Core 3.0. Se även den fullständiga listan över binärfiler som tagits bort från det delade ramverket.

Orsak till ändringen

Den här ändringen förenklar förbrukningen av Microsoft.AspNetCore.App och minskar dupliceringen mellan NuGet-paket och delade ramverk.

Mer information om motivationen för den här ändringen finns i det här blogginlägget.

Från och med ASP.NET Core 3.0 är det inte längre nödvändigt för projekt att använda sammansättningar i Microsoft.AspNetCore.App som NuGet-paket. För att förenkla mål och användning av det delade ASP.NET Core-ramverket levereras många NuGet-paket eftersom ASP.NET Core 1.0 inte längre produceras. DE API:er som paketen tillhandahåller är fortfarande tillgängliga för appar med hjälp av till <FrameworkReference>Microsoft.AspNetCore.App. Vanliga API-exempel är Kestrel, MVC och Razor.

Den här ändringen gäller inte för alla binärfiler som refereras via Microsoft.AspNetCore.App i ASP.NET Core 2.x. Några viktiga undantag är:

  • Microsoft.Extensions bibliotek som fortsätter att rikta in sig på .NET Standard är tillgängliga som NuGet-paket (se https://github.com/dotnet/extensions).
  • API:er som produceras av ASP.NET Core-teamet som inte ingår Microsoft.AspNetCore.Appi . Följande komponenter är till exempel tillgängliga som NuGet-paket:
  • Tillägg till MVC som har stöd för Json.NET. Ett API tillhandahålls som ett NuGet-paket för att stödja med hjälp av Json.NET och MVC. Mer information finns i migreringsguiden för ASP.NET Core.
  • SignalR .NET-klienten fortsätter att stödja .NET Standard och levereras som ett NuGet-paket. Den är avsedd för användning på många .NET-körningar, till exempel Xamarin och UWP.

Mer information finns i Sluta producera paket för delade ramverkssammansättningar i 3.0. Mer information finns i dotnet/aspnetcore#3757.

Kategori

ASP.NET Core

Berörda API:er

Delat ramverk: Microsoft.AspNetCore.All har tagits bort

Från och med ASP.NET Core 3.0 Microsoft.AspNetCore.All skapas inte längre metapaketet och det matchande Microsoft.AspNetCore.All delade ramverket. Det här paketet är tillgängligt i ASP.NET Core 2.2 och fortsätter att ta emot underhållsuppdateringar i ASP.NET Core 2.1.

Version introducerad

3,0

Gammalt beteende

Appar kan använda Microsoft.AspNetCore.All metapaketet för att rikta in sig på det delade ramverket Microsoft.AspNetCore.All på .NET Core.

Nytt beteende

.NET Core 3.0 innehåller Microsoft.AspNetCore.All inget delat ramverk.

Orsak till ändringen

Metapaketet Microsoft.AspNetCore.All innehöll ett stort antal externa beroenden.

Migrera ditt projekt för att använda ramverket Microsoft.AspNetCore.App . Komponenter som tidigare var tillgängliga i Microsoft.AspNetCore.All är fortfarande tillgängliga på NuGet. Dessa komponenter distribueras nu med din app i stället för att ingå i det delade ramverket.

Kategori

ASP.NET Core

Berörda API:er

Ingen

SignalR: HandshakeProtocol.SuccessHandshakeData ersatt

Fältet HandshakeProtocol.SuccessHandshakeData togs bort och ersattes med en hjälpmetod som genererar ett lyckat handskakningssvar med en specifik IHubProtocol.

Version introducerad

3,0

Gammalt beteende

HandshakeProtocol.SuccessHandshakeData var ett public static ReadOnlyMemory<byte> fält.

Nytt beteende

HandshakeProtocol.SuccessHandshakeData har ersatts av en staticGetSuccessfulHandshake(IHubProtocol protocol) metod som returnerar en ReadOnlyMemory<byte> baserad på det angivna protokollet.

Orsak till ändringen

Ytterligare fält lades till i handskakningssvaret som inte är konstanta och ändras beroende på det valda protokollet.

Inga. Den här typen är inte avsedd för användning från användarkod. Det är public, så det kan delas mellan SignalR-servern och klienten. Det kan också användas av kundens SignalR-klienter som skrivits i .NET. Användare av SignalR bör inte påverkas av den här ändringen.

Kategori

ASP.NET Core

Berörda API:er

HandshakeProtocol.SuccessHandshakeData

SignalR: Metoderna Hub Anslut ion ResetSendPing och ResetTimeout har tagits bort

Metoderna ResetSendPing och ResetTimeout togs bort från SignalR-API HubConnection :et. Dessa metoder var ursprungligen endast avsedda för internt bruk men offentliggjordes i ASP.NET Core 2.2. De här metoderna är inte tillgängliga från och med ASP.NET Core 3.0 Preview 4-versionen. Mer information finns i dotnet/aspnetcore#8543.

Version introducerad

3,0

Gammalt beteende

API:er var tillgängliga.

Nytt beteende

API:er tas bort.

Orsak till ändringen

Dessa metoder var ursprungligen endast avsedda för internt bruk men offentliggjordes i ASP.NET Core 2.2.

Använd inte dessa metoder.

Kategori

ASP.NET Core

Berörda API:er

SignalR: Hub Anslut ionContext-konstruktorer har ändrats

SignalR:s konstruktorer ändrades för att acceptera en alternativtyp, snarare än flera parametrar, till framtidssäkra HubConnectionContext tilläggsalternativ. Den här ändringen ersätter två konstruktorer med en enda konstruktor som accepterar en alternativtyp.

Version introducerad

3,0

Gammalt beteende

HubConnectionContext har två konstruktorer:

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

Nytt beteende

De två konstruktorerna togs bort och ersattes med en konstruktor:

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

Orsak till ändringen

Den nya konstruktorn använder ett nytt alternativobjekt. Därför kan funktionerna HubConnectionContext i utökas i framtiden utan att göra fler konstruktorer och icke-bakåtkompatibla ändringar.

I stället för att använda följande konstruktor:

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

Använd följande konstruktor:

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

Kategori

ASP.NET Core

Berörda API:er

SignalR: JavaScript-klientpaketets namn har ändrats

I ASP.NET Core 3.0 Preview 7 ändrades SignalR JavaScript-klientpaketnamnet från @aspnet/signalr till @microsoft/signalr. Namnändringen återspeglar det faktum att SignalR är användbart i mer än bara ASP.NET Core-appar, tack vare Azure SignalR Service.

Om du vill reagera på den här ändringen ändrar du referenser i dina package.json-filer , require -instruktioner och ECMAScript-instruktioner import . Inget API ändras som en del av detta namnbyte.

Mer information finns i dotnet/aspnetcore#11637.

Version introducerad

3,0

Gammalt beteende

Klientpaketet hette @aspnet/signalr.

Nytt beteende

Klientpaketet heter @microsoft/signalr.

Orsak till ändringen

Namnändringen klargör att SignalR är användbart utöver ASP.NET Core-appar, tack vare Azure SignalR Service.

Växla till det nya paketet @microsoft/signalr.

Kategori

ASP.NET Core

Berörda API:er

Ingen

SignalR: UseSignalR- och Use Anslut ions-metoder markerade som föråldrade

Metoderna UseConnections och UseSignalR klasserna ConnectionsRouteBuilder och HubRouteBuilder markeras som föråldrade i ASP.NET Core 3.0.

Version introducerad

3,0

Gammalt beteende

SignalR Hub-routning har konfigurerats med eller UseSignalRUseConnections.

Nytt beteende

Det gamla sättet att konfigurera routning har föråldrats och ersatts med slutpunktsroutning.

Orsak till ändringen

Mellanprogram flyttas till det nya slutpunktsdirigeringssystemet. Det gamla sättet att lägga till mellanprogram är föråldrat.

Ersätt UseSignalR med UseEndpoints:

Gammal kod:

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

Ny kod:

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

Kategori

ASP.NET Core

Berörda API:er

SPA: SpaServices och NodeServices har markerats som föråldrade

Innehållet i följande NuGet-paket har varit onödigt sedan ASP.NET Core 2.1. Därför markeras följande paket som föråldrade:

Av samma anledning markeras följande npm-moduler som inaktuella:

De föregående paketen och npm-modulerna tas senare bort i .NET 5.

Version introducerad

3,0

Gammalt beteende

De inaktuella paketen och npm-modulerna var avsedda att integrera ASP.NET Core med olika spa-ramverk (Single Page App). Sådana ramverk omfattar Angular, React och React med Redux.

Nytt beteende

Det finns en ny integrationsmekanism i NuGet-paketet Microsoft.AspNetCore.SpaServices.Extensions . Paketet är fortfarande grunden för Angular- och React-projektmallarna sedan ASP.NET Core 2.1.

Orsak till ändringen

ASP.NET Core stöder integrering med olika spa-ramverk (Single Page App), inklusive Angular, React och React med Redux. Till en början genomfördes integrering med dessa ramverk med ASP.NET Core-specifika komponenter som hanterade scenarier som förrendering på serversidan och integrering med Webpack. Med tiden förändrades branschstandarderna. Var och en av SPA-ramverken släppte sina egna standardkommandoradsgränssnitt. Till exempel Angular CLI och create-react-app.

När ASP.NET Core 2.1 släpptes i maj 2018 svarade teamet på ändringen av standarder. Ett nyare och enklare sätt att integrera med SPA-ramverkens egna verktygskedjor tillhandahölls. Den nya integreringsmekanismen finns i paketet Microsoft.AspNetCore.SpaServices.Extensions och ligger fortfarande till grund för Angular- och React-projektmallarna sedan ASP.NET Core 2.1.

För att klargöra att de äldre ASP.NET Core-specifika komponenterna är irrelevanta och inte rekommenderas:

  • Integreringsmekanismen före 2.1 är markerad som föråldrad.
  • De stödda npm-paketen markeras som inaktuella.

Om du använder de här paketen uppdaterar du dina appar så att de använder funktionerna:

  • I paketet Microsoft.AspNetCore.SpaServices.Extensions .
  • Tillhandahålls av SPA-ramverken som du använder

Information om hur du aktiverar funktioner som prerendering på serversidan och frekvent modulinläsning finns i dokumentationen för motsvarande SPA-ramverk. Funktionerna i Microsoft.AspNetCore.SpaServices.Extensions är inte föråldrade och kommer att fortsätta att stödjas.

Kategori

ASP.NET Core

Berörda API:er

SPA: SpaServices och NodeServices återgår inte längre till konsolloggaren

Microsoft.AspNetCore.SpaServices och Microsoft.AspNetCore.NodeServices visar inte konsolloggar om inte loggningen har konfigurerats.

Version introducerad

3,0

Gammalt beteende

Microsoft.AspNetCore.SpaServices och Microsoft.AspNetCore.NodeServices används för att automatiskt skapa en konsolloggare när loggningen inte har konfigurerats.

Nytt beteende

Microsoft.AspNetCore.SpaServices och Microsoft.AspNetCore.NodeServices visar inte konsolloggar om inte loggningen har konfigurerats.

Orsak till ändringen

Det finns ett behov av att anpassa sig till hur andra ASP.NET Core-paket implementerar loggning.

Om det gamla beteendet krävs lägger du till services.AddLogging(builder => builder.AddConsole()) i din Setup.ConfigureServices metod för att konfigurera konsolloggning.

Kategori

ASP.NET Core

Berörda API:er

Ingen

Målramverk: .NET Framework-stöd har tagits bort

Från och med ASP.NET Core 3.0 är .NET Framework ett målramverk som inte stöds.

Ändra beskrivning

.NET Framework 4.8 är den sista huvudversionen av .NET Framework. Nya ASP.NET Core-appar bör byggas på .NET Core. Från och med .NET Core 3.0-versionen kan du se ASP.NET Core 3.0 som en del av .NET Core.

Kunder som använder ASP.NET Core med .NET Framework kan fortsätta på ett sätt som stöds fullt ut med hjälp av 2.1 LTS-versionen. Support och service för 2.1 fortsätter till åtminstone den 21 augusti 2021. Det här datumet är tre år efter deklarationen av LTS-versionen enligt .NET-supportpolicyn. Stödet för ASP.NET Core 2.1-paket på .NET Framework utökas på obestämd tid, ungefär som serviceprincipen för andra paketbaserade ASP.NET ramverk.

Mer information om portning från .NET Framework till .NET Core finns i Portning till .NET Core.

Microsoft.Extensions paket (till exempel loggning, beroendeinmatning och konfiguration) och Entity Framework Core påverkas inte. De fortsätter att stödja .NET Standard.

Mer information om motivationen för den här ändringen finns i det ursprungliga blogginlägget.

Version introducerad

3,0

Gammalt beteende

ASP.NET Core-appar kan köras på .NET Core eller .NET Framework.

Nytt beteende

ASP.NET Core-appar kan bara köras på .NET Core.

Välj en av följande åtgärder:

  • Håll appen på ASP.NET Core 2.1.
  • Migrera din app och dina beroenden till .NET Core.

Kategori

ASP.NET Core

Berörda API:er

Ingen

Core .NET-bibliotek

API:er som rapportversionen nu rapporterar produkt och inte filversion

Många av de API:er som returnerar versioner i .NET Core returnerar nu produktversionen i stället för filversionen.

Ändra beskrivning

I .NET Core 2.2 och tidigare versioner återspeglar metoder som Environment.Version, RuntimeInformation.FrameworkDescriptionoch dialogrutan filegenskaper för .NET Core-sammansättningar filversionen. Från och med .NET Core 3.0 återspeglar de produktversionen.

Följande bild illustrerar skillnaden i versionsinformation för System.Runtime.dll sammansättning för .NET Core 2.2 (till vänster) och .NET Core 3.0 (till höger) som visas i dialogrutan Filegenskaper för Utforskaren i Windows.

Difference in product version information

Version introducerad

3,0

Inga. Den här ändringen bör göra versionsidentifiering intuitiv i stället för obtuse.

Kategori

Core .NET-bibliotek

Berörda API:er

Anpassade EncoderFallbackBuffer-instanser kan inte rekursivt falla tillbaka

Anpassade EncoderFallbackBuffer instanser kan inte falla tillbaka rekursivt. Implementeringen av EncoderFallbackBuffer.GetNextChar() måste resultera i en teckensekvens som kan konverteras till målkodningen. Annars inträffar ett undantag.

Ändra beskrivning

Under en transkodningsåtgärd mellan tecken och byte identifierar körningen felaktiga eller icke-konvertible UTF-16-sekvenser och tillhandahåller dessa tecken till EncoderFallbackBuffer.Fallback metoden. Metoden Fallback avgör vilka tecken som ska ersättas med de ursprungliga icke-konvertible data och dessa tecken töms genom att anropa EncoderFallbackBuffer.GetNextChar i en loop.

Körningen försöker sedan omkoda dessa ersättningstecken till målkodningen. Om den här åtgärden lyckas fortsätter körningen att omkodas från den plats där den slutade i den ursprungliga indatasträngen.

Tidigare kan anpassade implementeringar av EncoderFallbackBuffer.GetNextChar() returnera teckensekvenser som inte kan konverteras till målkodningen. Om de ersatta tecknen inte kan omkodas till målkodningen anropar körningen EncoderFallbackBuffer.Fallback metoden igen med ersättningstecken och förväntar sig EncoderFallbackBuffer.GetNextChar() att metoden returnerar en ny ersättningssekvens. Den här processen fortsätter tills körningen slutligen ser en välformulerad, konvertibel ersättning eller tills ett maximalt antal rekursioner har uppnåtts.

Från och med .NET Core 3.0 måste anpassade implementeringar av EncoderFallbackBuffer.GetNextChar() returnera teckensekvenser som kan konverteras till målkodningen. Om de ersatta tecknen inte kan omkodas till målkodningen genereras en ArgumentException . Körningen gör inte längre rekursiva anrop till instansen EncoderFallbackBuffer .

Det här beteendet gäller endast när alla tre av följande villkor uppfylls:

  • Körningen identifierar en felaktig UTF-16-sekvens eller en UTF-16-sekvens som inte kan konverteras till målkodningen.
  • En anpassad EncoderFallback har angetts.
  • De anpassade EncoderFallback försöken att ersätta en ny felaktig eller icke-konverterbar UTF-16-sekvens.

Version introducerad

3,0

De flesta utvecklare behöver inte vidta några åtgärder.

Om ett program använder en anpassad EncoderFallback och EncoderFallbackBuffer klass kontrollerar du att implementeringen av EncoderFallbackBuffer.Fallback fyller reservbufferten med välformulerade UTF-16-data som är direkt konvertibla till målkodningen när Fallback metoden först anropas av körningen.

Kategori

Core .NET-bibliotek

Berörda API:er

Flyttalsformatering och parsningsbeteende har ändrats

Flyttalsparsning och formateringsbeteende (efter typer) DoubleSingle är nu IEEE-kompatibla. Detta säkerställer att beteendet för flyttalstyper i .NET matchar andra IEEE-kompatibla språk. Ska till exempel double.Parse("SomeLiteral") alltid matcha vad C# producerar för double x = SomeLiteral.

Ändra beskrivning

I .NET Core 2.2 och tidigare versioner formaterar du med Double.ToString och Single.ToString, och parsar med Double.Parse, Double.TryParse, Single.Parseoch Single.TryParse är inte IEEE-kompatibla. Därför är det omöjligt att garantera att ett värde tur och retur med någon standard- eller anpassad formatsträng som stöds. För vissa indata kan försöket att parsa ett formaterat värde misslyckas, och för andra är det parsade värdet inte lika med det ursprungliga värdet.

Från och med .NET Core 3.0 är flyttalsparsning och formateringsåtgärder IEEE 754-kompatibla.

I följande tabell visas två kodfragment och hur utdata ändras mellan .NET Core 2.2 och .NET Core 3.1.

Kodstycke Utdata på .NET Core 2.2 Utdata på .NET Core 3.1
Console.WriteLine((-0.0).ToString()); 0 0–
var value = -3.123456789123456789;
Console.WriteLine(value == double.Parse(value.ToString()));		 False True

Mer information finns i förbättringarna av flyttalsparsning och formatering i blogginlägget .NET Core 3.0 .

Version introducerad

3,0

Avsnittet Potentiell påverkan på befintlig kod i förbättringarna av flyttalsparsning och formatering i blogginlägget .NET Core 3.0 föreslår vissa ändringar som du kan göra i koden om du vill behålla det tidigare beteendet.

  • För vissa skillnader i formatering kan du få ett beteende som motsvarar det tidigare beteendet genom att ange en annan formatsträng.
  • För skillnader i parsning finns det ingen mekanism för att återgå till det tidigare beteendet.

Kategori

Core .NET-bibliotek

Berörda API:er

Flyttalsparsningsåtgärder misslyckas inte längre eller utlöser en OverflowException

De flyttalsparsningsmetoderna genererar inte längre en OverflowException eller returnerar false när de parsar en sträng vars numeriska värde ligger utanför intervallet Single för eller Double flyttalstypen.

Ändra beskrivning

I .NET Core 2.2 och tidigare versioner Double.Parse genererar metoderna och Single.Parse en OverflowException för värden som ligger utanför intervallet för respektive typ. Metoderna Double.TryParse och Single.TryParse returnerar false för strängrepresentationer av numeriska värden som inte ligger inom intervallet.

Från och med .NET Core 3.0 Double.Parsemisslyckas inte längre metoderna , Double.TryParse, Single.Parseoch Single.TryParse när du parsar numeriska strängar som inte är inom intervallet. Double I stället returnerar Double.PositiveInfinity parsningsmetoderna för värden som överskrider Double.MaxValue, och de returnerar Double.NegativeInfinity för värden som är mindre än Double.MinValue. På samma sätt returnerar parsningsmetoderna Single för värden som överskrider Single.MaxValue, och de returnerar Single.NegativeInfinity för värden som är mindre än Single.MinValue.Single.PositiveInfinity

Den här ändringen gjordes för förbättrad IEEE 754:2008-efterlevnad.

Version introducerad

3,0

Den här ändringen kan påverka koden på något av två sätt:

  • Din kod är beroende av hanteraren för OverflowException att köra när ett spill uppstår. I det här fallet bör du ta bort -instruktionen catch och placera nödvändig kod i en If -instruktion som testar om Double.IsInfinity eller Single.IsInfinity är true.

  • Koden förutsätter att flyttalsvärdena inte Infinityär . I det här fallet bör du lägga till nödvändig kod för att söka efter flyttalsvärden PositiveInfinity för och NegativeInfinity.

Kategori

Core .NET-bibliotek

Berörda API:er

InvalidAsynchronousStateException har flyttats till en annan sammansättning

Klassen InvalidAsynchronousStateException har flyttats.

Ändra beskrivning

I .NET Core 2.2 och tidigare versioner InvalidAsynchronousStateException finns klassen i sammansättningen System.ComponentModel.TypeConverter .

Från och med .NET Core 3.0 finns den i sammansättningen System.ComponentModel.Primitives .

Version introducerad

3,0

Den här ändringen påverkar endast program som använder reflektion för att läsa in InvalidAsynchronousStateException genom att anropa en metod, till exempel Assembly.GetType eller en överlagring av Activator.CreateInstance som förutsätter att typen finns i en viss sammansättning. I så fall uppdaterar du sammansättningen som refereras i metodanropet så att den återspeglar typens nya sammansättningsplats.

Kategori

Core .NET-bibliotek

Berörda API:er

Inga.

Ersätta illa utformade UTF-8 byte-sekvenser följer Unicode-riktlinjerna

UTF8Encoding När klassen stöter på en illa utformad UTF-8 byte-sekvens under en byte-till-tecken-transkodningsåtgärd ersätter den sekvensen med tecknet U+FFFD REPLACEMENT CHARACTER i utdatasträngen. .NET Core 3.0 skiljer sig från tidigare versioner av .NET Core och .NET Framework genom att följa unicode-metoden för att utföra den här ersättningen under omkodningsåtgärden.

Detta är en del av ett större arbete för att förbättra UTF-8-hanteringen i hela .NET, inklusive av de nya System.Text.Unicode.Utf8 och System.Text.Rune typerna. Typen UTF8Encoding fick förbättrad felhanteringsmekanik så att den ger utdata som överensstämmer med de nyligen introducerade typerna.

Ändra beskrivning

Från och med .NET Core 3.0, när byte överkodas till tecken, UTF8Encoding utför klassen teckenersättning baserat på Metodtips för Unicode. Ersättningsmekanismen som används beskrivs av Unicode Standard, version 12.0, s. 3.9 (PDF) i rubriken U+FFFD Substitution of Maximal Subparts.

Det här beteendet gäller endast när indatabytesekvensen innehåller oformaterad UTF-8-data. Om instansen UTF8Encoding har konstruerats med throwOnInvalidBytes: truefortsätter instansen UTF8Encoding dessutom att generera ogiltiga indata i stället för att utföra U+FFFD-ersättning. Mer information om konstruktorn finns i UTF8EncodingUTF8Encoding(Boolean, Boolean).

I följande tabell visas effekten av den här ändringen med ogiltiga indata på 3 byte:

Felaktig 3-bytesinmatning Utdata före .NET Core 3.0 Utdata som börjar med .NET Core 3.0
[ ED A0 90 ] [ FFFD FFFD ] (utdata med 2 tecken) [ FFFD FFFD FFFD ] (utdata med 3 tecken)

3-teckensutdata är de önskade utdata, enligt tabell 3-9 i den tidigare länkade Unicode Standard PDF.

Version introducerad

3,0

Ingen åtgärd krävs från utvecklarens sida.

Kategori

Core .NET-bibliotek

Berörda API:er

TypeDescriptionProviderAttribute har flyttats till en annan sammansättning

Klassen TypeDescriptionProviderAttribute har flyttats.

Ändra beskrivning

I .NET Core 2.2 och tidigare versioner TypeDescriptionProviderAttribute finns klassen i sammansättningen System.ComponentModel.TypeConverter .

Från och med .NET Core 3.0 finns den i sammansättningen System.ObjectModel .

Version introducerad

3,0

Den här ändringen påverkar endast program som använder reflektion för att läsa in TypeDescriptionProviderAttribute typen genom att anropa en metod, till exempel Assembly.GetType eller en överlagring av Activator.CreateInstance som förutsätter att typen finns i en viss sammansättning. I så fall bör sammansättningen som refereras i metodanropet uppdateras för att återspegla typens nya sammansättningsplats.

Kategori

Windows Forms

Berörda API:er

Inga.

ZipArchiveEntry hanterar inte längre arkiv med inkonsekventa inmatningsstorlekar

Zip-arkiv visar både komprimerad storlek och okomprimerad storlek i den centrala katalogen och det lokala huvudet. Själva inmatningsdata anger också dess storlek. I .NET Core 2.2 och tidigare versioner kontrollerades aldrig dessa värden för konsekvens. Från och med .NET Core 3.0 är de nu det.

Ändra beskrivning

I .NET Core 2.2 och tidigare versioner ZipArchiveEntry.Open() lyckas även om det lokala huvudet inte håller med det centrala huvudet i zip-filen. Data dekomprimeras tills slutet av den komprimerade dataströmmen har nåtts, även om dess längd överskrider den okomprimerade filstorleken som anges i den centrala katalogen/det lokala huvudet.

Från och med .NET Core 3.0 ZipArchiveEntry.Open() kontrollerar metoden att det lokala huvudet och det centrala huvudet är överens om komprimerade och okomprimerade storlekar på en post. Om de inte gör det genererar metoden en InvalidDataException om-arkivets lokala huvud- och/eller databeskrivningsliststorlekar som inte överensstämmer med zip-filens centrala katalog. När du läser en post trunkeras dekomprimerade data till den okomprimerade filstorlek som anges i rubriken.

Den här ändringen gjordes för att säkerställa att en ZipArchiveEntry korrekt representerar storleken på dess data och att endast den mängden data läss.

Version introducerad

3,0

Packa om alla zip-arkiv som uppvisar dessa problem.

Kategori

Core .NET-bibliotek

Berörda API:er

FieldInfo.SetValue genererar undantag för statiska fält med endast init

Från och med .NET Core 3.0 utlöses ett undantag när du försöker ange ett värde för ett statiskt InitOnly fält genom att anropa System.Reflection.FieldInfo.SetValue.

Ändra beskrivning

I .NET Framework och versioner av .NET Core före 3.0 kan du ange värdet för ett statiskt fält som är konstant när det har initierats (skrivskyddat i C#) genom att anropa System.Reflection.FieldInfo.SetValue. Att ange ett sådant fält på det här sättet resulterade dock i oförutsägbart beteende baserat på målramverket och optimeringsinställningarna.

När du anropar SetValue ett statiskt InitOnly fält i .NET Core 3.0 och senare versioner genereras ett System.FieldAccessException undantag.

Dricks

Ett InitOnly fält är ett fält som bara kan anges när det deklareras eller i konstruktorn för den innehållande klassen. Med andra ord är den konstant när den har initierats.

Version introducerad

3,0

Initiera statiska InitOnly fält i en statisk konstruktor. Detta gäller både dynamiska och icke-dynamiska typer.

Du kan också ta bort FieldAttributes.InitOnly attributet från fältet och sedan anropa FieldInfo.SetValue.

Kategori

Core .NET-bibliotek

Berörda API:er

Att skicka GroupCollection till tilläggsmetoder som tar IEnumerable<T> kräver tvetydighet

När du anropar en tilläggsmetod som använder IEnumerable<T> en GroupCollectionmåste du skilja typen från med hjälp av en gjuten fil.

Ändra beskrivning

Från och med .NET Core 3.0 System.Text.RegularExpressions.GroupCollection implementeras IEnumerable<KeyValuePair<String,Group>> utöver de andra typerna som implementeras, inklusive IEnumerable<Group>. Detta resulterar i tvetydighet när du anropar en tilläggsmetod som tar en IEnumerable<T>. Om du till exempel Enumerable.Countanropar en sådan tilläggsmetod på en GroupCollection instans visas följande kompilatorfel:

CS1061: "GroupCollection" innehåller inte någon definition för "Count" och ingen tillgänglig tilläggsmetod "Count" som accepterar ett första argument av typen "GroupCollection" kunde hittas (saknar du ett användningsdirektiv eller en sammansättningsreferens?)

I tidigare versioner av .NET fanns det ingen tvetydighet och inget kompilatorfel.

Version introducerad

3,0

Orsak till ändringen

Detta var en oavsiktlig icke-bakåtkompatibel förändring. Eftersom det har varit så här under en tid planerar vi inte att återställa det. Dessutom skulle en sådan förändring i sig vara banbrytande.

Till GroupCollection exempel, tvetydiga anrop till tilläggsmetoder som accepterar en IEnumerable<T> med en cast.

// Without a cast - causes CS1061.
match.Groups.Count(_ => true)

// With a disambiguating cast.
((IEnumerable<Group>)m.Groups).Count(_ => true);

Kategori

Core .NET-bibliotek

Berörda API:er

Alla tilläggsmetoder som accepterar en IEnumerable<T> påverkas. Till exempel:

Kryptografi

Syntaxen "BEGIN TRUSTED CERTIFICATE" stöds inte längre för rotcertifikat i Linux

Rotcertifikat i Linux och andra Unix-liknande system (men inte macOS) kan visas i två former: PEM-standardrubriken BEGIN CERTIFICATE och den OpenSSL-specifika BEGIN TRUSTED CERTIFICATE PEM-rubriken. Den senare syntaxen möjliggör ytterligare konfiguration som har orsakat kompatibilitetsproblem med .NET Core-klassen System.Security.Cryptography.X509Certificates.X509Chain . BEGIN TRUSTED CERTIFICATE rotcertifikatinnehåll läses inte längre in av kedjemotorn som startar i .NET Core 3.0.

Ändra beskrivning

Tidigare användes både syntaxerna BEGIN CERTIFICATE och BEGIN TRUSTED CERTIFICATE för att fylla i rotförtroendelistan. Om syntaxen BEGIN TRUSTED CERTIFICATE användes och ytterligare alternativ angavs i filen X509Chain kan ha rapporterat att kedjeförtroendet uttryckligen inte tilläts (X509ChainStatusFlags.ExplicitDistrust). Men om certifikatet också angavs med syntaxen BEGIN CERTIFICATE i en tidigare inläst fil tilläts kedjeförtroendet.

Från och med .NET Core 3.0 BEGIN TRUSTED CERTIFICATE läss inte längre innehållet. Om certifikatet inte också anges via en standardsyntax BEGIN CERTIFICATE rapporterar de X509Chain att roten inte är betrodd (X509ChainStatusFlags.UntrustedRoot).

Version introducerad

3,0

De flesta program påverkas inte av den här ändringen, men program som inte kan se båda rotcertifikatkällorna på grund av behörighetsproblem kan uppleva oväntade UntrustedRoot fel efter uppgraderingen.

Många Linux-distributioner (eller distributioner) skriver rotcertifikat till två platser: en katalog med ett certifikat per fil och en sammanlänkning med en fil. I vissa distributioner använder BEGIN TRUSTED CERTIFICATE katalogen one-certificate-per-file syntaxen medan filsammanfogningen använder standardsyntaxen BEGIN CERTIFICATE . Se till att alla anpassade rotcertifikat läggs till som BEGIN CERTIFICATE på minst en av dessa platser och att båda platserna kan läsas av ditt program.

Den typiska katalogen är /etc/ssl/certs/ och den typiska sammanfogade filen är /etc/ssl/cert.pem. Använd kommandot openssl version -d för att fastställa den plattformsspecifika roten, som kan skilja sig från /etc/ssl/. På Ubuntu 18.04 är katalogen till exempel /usr/lib/ssl/certs/ och filen är /usr/lib/ssl/cert.pem. Men /usr/lib/ssl/certs/ är en symlink till /etc/ssl/certs/ och /usr/lib/ssl/cert.pem finns inte.

$ openssl version -d
OPENSSLDIR: "/usr/lib/ssl"
$ ls -al /usr/lib/ssl
total 12
drwxr-xr-x  3 root root 4096 Dec 12 17:10 .
drwxr-xr-x 73 root root 4096 Feb 20 15:18 ..
lrwxrwxrwx  1 root root   14 Mar 27  2018 certs -> /etc/ssl/certs
drwxr-xr-x  2 root root 4096 Dec 12 17:10 misc
lrwxrwxrwx  1 root root   20 Nov 12 16:58 openssl.cnf -> /etc/ssl/openssl.cnf
lrwxrwxrwx  1 root root   16 Mar 27  2018 private -> /etc/ssl/private

Kategori

Kryptografi

Berörda API:er

EnvelopedCms är standard för AES-256-kryptering

Standardalgoritmen för symmetrisk kryptering som används av EnvelopedCms har ändrats från TripleDES till AES-256.

Ändra beskrivning

I tidigare versioner, när EnvelopedCms används för att kryptera data utan att ange en symmetrisk krypteringsalgoritm via en konstruktoröverlagring, krypteras data med TripleDES/3DES/3DEA/DES3-EDE-algoritmen.

Från och med .NET Core 3.0 (via version 4.6.0 av NuGet-paketet System.Security.Cryptography.Pkcs ) har standardalgoritmen ändrats till AES-256 för algoritmmodernisering och för att förbättra säkerheten för standardalternativ. Om ett meddelandemottagarecertifikat har en (icke-EC) Diffie-Hellman offentlig nyckel kan krypteringsåtgärden misslyckas med en CryptographicException på grund av begränsningar i den underliggande plattformen.

I följande exempelkod krypteras data med TripleDES om de körs på .NET Core 2.2 eller tidigare. Om den körs på .NET Core 3.0 eller senare krypteras den med AES-256.

EnvelopedCms cms = new EnvelopedCms(content);
cms.Encrypt(recipient);
return cms.Encode();

Version introducerad

3,0

Om du påverkas negativt av ändringen kan du återställa TripleDES-kryptering genom att uttryckligen ange krypteringsalgoritmidentifieraren i en EnvelopedCms konstruktor som innehåller en parameter av typen AlgorithmIdentifier, till exempel:

Oid tripleDesOid = new Oid("1.2.840.113549.3.7", null);
AlgorithmIdentifier tripleDesIdentifier = new AlgorithmIdentifier(tripleDesOid);
EnvelopedCms cms = new EnvelopedCms(content, tripleDesIdentifier);

cms.Encrypt(recipient);
return cms.Encode();

Kategori

Kryptografi

Berörda API:er

Minsta storlek för RSAOpenSsl-nyckelgenerering har ökat

Den minsta storleken för att generera nya RSA-nycklar i Linux har ökat från 384-bitars till 512-bitars.

Ändra beskrivning

Från och med .NET Core 3.0 har den minsta juridiska nyckelstorleken LegalKeySizes som rapporterats av egenskapen på RSA-instanser från RSA.Create, RSAOpenSsloch RSACryptoServiceProvider i Linux ökat från 384 till 512.

I .NET Core 2.2 och tidigare versioner lyckas därför ett metodanrop, till exempel RSA.Create(384) . I .NET Core 3.0 och senare versioner genererar metodanropet RSA.Create(384) ett undantag som anger att storleken är för liten.

Den här ändringen gjordes eftersom OpenSSL, som utför kryptografiska åtgärder i Linux, höjde sitt minimum mellan versionerna 1.0.2 och 1.1.0. .NET Core 3.0 föredrar OpenSSL 1.1.x till 1.0.x, och den minsta rapporterade versionen höjdes för att återspegla den nya högre beroendebegränsningen.

Version introducerad

3,0

Om du anropar någon av de berörda API:erna kontrollerar du att storleken på alla genererade nycklar inte är mindre än providerns minimum.

Kommentar

384-bitars RSA anses redan vara osäkert (liksom 512-bitars RSA). Moderna rekommendationer, till exempel NIST Special Publication 800-57 Del 1 Revision 4, föreslår 2048-bitars som minsta storlek för nyligen genererade nycklar.

Kategori

Kryptografi

Berörda API:er

.NET Core 3.0 föredrar OpenSSL 1.1.x till OpenSSL 1.0.x

.NET Core för Linux, som fungerar i flera Linux-distributioner, kan stödja både OpenSSL 1.0.x och OpenSSL 1.1.x. .NET Core 2.1 och .NET Core 2.2 letar efter 1.0.x först och faller sedan tillbaka till 1.1.x; .NET Core 3.0 letar efter 1.1.x först. Den här ändringen gjordes för att lägga till stöd för nya kryptografiska standarder.

Den här ändringen kan påverka bibliotek eller program som utför plattformsinterop med OpenSSL-specifika interop-typer i .NET Core.

Ändra beskrivning

I .NET Core 2.2 och tidigare versioner föredrar körningen att läsa in OpenSSL 1.0.x över 1.1.x. Det innebär att typerna IntPtr och SafeHandle för interop med OpenSSL används med libcrypto.so.1.0.0 /libcrypto.so.1.0 /libcrypto.so.10 efter önskemål.

Från och med .NET Core 3.0, runtime föredrar att läsa in OpenSSL 1.1.x över OpenSSL 1.0.x, så IntPtr de och SafeHandle typerna för interop med OpenSSL används med libcrypto.so.1.1 / libcrypto.so.11 / libcrypto.so.1.1.0 / libcrypto.so.1.1.1 efter önskemål. Därför kan bibliotek och program som samverkar direkt med OpenSSL ha inkompatibla pekare med .NET Core-exponerade värden vid uppgradering från .NET Core 2.1 eller .NET Core 2.2.

Version introducerad

3,0

Bibliotek och program som utför direkta åtgärder med OpenSSL måste vara noga med att se till att de använder samma version av OpenSSL som .NET Core-körningen.

Alla bibliotek eller program som använder IntPtr eller SafeHandle värden från .NET Core kryptografiska typer direkt med OpenSSL bör jämföra versionen av biblioteket som de använder med den nya SafeEvpPKeyHandle.OpenSslVersion egenskapen för att säkerställa att pekarna är kompatibla.

Kategori

Kryptografi

Berörda API:er

CryptoStream.Dispose omvandlar endast det sista blocket när du skriver

Metoden CryptoStream.Dispose , som används för att slutföra CryptoStream åtgärder, försöker inte längre transformera det sista blocket vid läsning.

Ändra beskrivning

Om en användare i tidigare .NET-versioner utförde en ofullständig läsning när han Dispose eller hon använde CryptoStream i Read läget kan metoden utlösa ett undantag (till exempel när du använder AES med utfyllnad). Undantaget utlöstes eftersom det sista blocket försökte omvandlas men data var ofullständiga.

I .NET Core 3.0 och senare versioner Dispose försöker inte längre transformera det sista blocket vid läsning, vilket möjliggör ofullständiga läsningar.

Orsak till ändringen

Den här ändringen möjliggör ofullständiga läsningar från kryptoströmmen när en nätverksåtgärd avbryts, utan att du behöver fånga upp ett undantag.

Version introducerad

3,0

De flesta appar bör inte påverkas av den här ändringen.

Om ditt program tidigare upptäckte ett undantag i händelse av en ofullständig läsning kan du ta bort det catch blocket. Om din app använde transformering av det sista blocket i hash-scenarier kan du behöva se till att hela dataströmmen läse innan den tas bort.

Kategori

Kryptografi

Berörda API:er

Entity Framework Core

Icke-bakåtkompatibla ändringar i Entity Framework Core

Globalisering

"C" nationella inställningar mappar till det invarianta språket

.NET Core 2.2 och tidigare versioner beror på standardbeteendet för ICU, som mappar språkvarianten "C" till en_US_POSIX nationella inställningar. Det en_US_POSIX nationella språket har ett oönskat sorteringsbeteende eftersom det inte stöder skiftlägesokänsliga strängjämförelser. Eftersom vissa Linux-distributioner anger "C"-språk som standardspråk hade användarna oväntat beteende.

Ändra beskrivning

Från och med .NET Core 3.0 har "C"-språkmappningen ändrats för att använda invariantspråket i stället för en_US_POSIX. "C"-språkvarianten för Invariant-mappning tillämpas också på Windows för konsekvens.

Mappning av "C" till en_US_POSIX kultur orsakade kundförvirring, eftersom en_US_POSIX inte stöder skiftlägesokänsliga sorterings-/söksträngsåtgärder. Eftersom "C"-språkvarianten används som standardspråk i vissa Linux-distributioner upplevde kunderna detta oönskade beteende på dessa operativsystem.

Version introducerad

3,0

Inget specifikt mer än medvetenheten om denna förändring. Den här ändringen påverkar endast program som använder "C"-språkmappningen.

Kategori

Globalisering

Berörda API:er

Alla sorterings- och kultur-API:er påverkas av den här ändringen.

MSBuild

Namnändring för resursmanifestfil

Från och med .NET Core 3.0 genererar MSBuild i standardfallet ett annat manifestfilnamn för resursfiler.

Version introducerad

3,0

Ändra beskrivning

Innan .NET Core 3.0, om inga , eller metadata angavs för ett EmbeddedResource objekt i projektfilen, genererade MSBuild ett manifestfilnamn i mönstret <RootNamespace>.<ResourceFilePathFromProjectRoot>.resources.DependentUponManifestResourceNameLogicalName Om RootNamespace inte har definierats i projektfilen är det som standard namnet på projektet. Till exempel var det genererade manifestnamnet för en resursfil med namnet Form1.resx i rotprojektkatalogen MyProject.Form1.resources.

Från och med .NET Core 3.0, om en resursfil samplaceras med en källfil med samma namn (till exempel Form1.resx och Form1.cs), använder MSBuild typinformation från källfilen för att generera manifestfilens namn i mönstret <Namespace>.<ClassName>.resources. Namnområdet och klassnamnet extraheras från den första typen i den samlokaliserade källfilen. Det genererade manifestnamnet för en resursfil med namnet Form1.resx som samlokaliserats med en källfil med namnet Form1.cs är MyNamespace.Form1.resources. Det viktigaste att notera är att den första delen av filnamnet skiljer sig från tidigare versioner av .NET Core (MyNamespace i stället för MyProject).

Kommentar

Om du har LogicalNameangett , ManifestResourceNameeller DependentUpon metadata för ett EmbeddedResource objekt i projektfilen påverkar inte den här ändringen resursfilen.

Den här icke-bakåtkompatibla ändringen introducerades med tillägget av EmbeddedResourceUseDependentUponConvention egenskapen till .NET Core-projekt. Som standard visas inte resursfiler uttryckligen i en .NET Core-projektfil, så de har inga DependentUpon metadata för att ange hur den genererade .resources-filen ska namnges. När EmbeddedResourceUseDependentUponConvention är inställt på true, vilket är standardinställningen, letar MSBuild efter en samlokaliserad källfil och extraherar ett namnområde och klassnamn från filen. Om du anger EmbeddedResourceUseDependentUponConvention till falsegenererar MSBuild manifestnamnet enligt det tidigare beteendet, som kombinerar RootNamespace och den relativa filsökvägen.

I de flesta fall krävs ingen åtgärd från utvecklarens sida, och din app bör fortsätta att fungera. Men om den här ändringen bryter din app kan du antingen:

  • Ändra koden så att den förväntar sig det nya manifestnamnet.

  • Avregistrera dig från den nya namngivningskonventionen genom att ange EmbeddedResourceUseDependentUponConvention i false projektfilen.

    <PropertyGroup>
  <EmbeddedResourceUseDependentUponConvention>false</EmbeddedResourceUseDependentUponConvention>
</PropertyGroup>

Kategori

MSBuild

Berörda API:er

Ej tillämpligt

Nätverk

Standardvärdet för HttpRequestMessage.Version har ändrats till 1.1

Standardvärdet för System.Net.Http.HttpRequestMessage.Version egenskapen har ändrats från 2.0 till 1.1.

Version introducerad

3,0

Ändra beskrivning

I .NET Core 1.0 till 2.0 är standardvärdet för System.Net.Http.HttpRequestMessage.Version egenskapen 1.1. Från och med .NET Core 2.1 ändrades den till 2.1.

Från och med .NET Core 3.0 är standardversionsnumret som returneras av System.Net.Http.HttpRequestMessage.Version egenskapen återigen 1.1.

Uppdatera koden om den är beroende av att System.Net.Http.HttpRequestMessage.Version egenskapen returnerar standardvärdet 2.0.

Kategori

Nätverk

Berörda API:er

Se även