Dela via

Brytande ändringar i .NET Core 3.0

Om du migrerar till version 3.0 av .NET Core, ASP.NET Core eller EF Core kan ändringar med kompatibilitetsproblem som anges i den här artikeln påverka din app.

ASP.NET Kärna

API:er för föråldrade åtgärder 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 införd

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 Kärna

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 kunde brytas i mindre uppdateringar 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 införd

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 underkastade .NET-policyer för att förhindra icke-bakåtkompatibla ändringar.

Att hålla kvar API:erna public (även i *.Internal namnrum) 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 API:n 'now' internal.

HttpContext.Request.EnableBuffering();

Kategori

ASP.NET Kärna

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örjade stänga 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 införd

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 i Google+ avstängningens påverkan. Appar bör slutföra testningen med åtgärden för att kontrollera ä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

Minskningen 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 livslängdens slut.

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 lösning som föreslås 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 Kärna

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 införd

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 Kärna

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 införd

3,0

För härledda OAuth-implementeringar är den vanligaste ändringen att ersätta JObject.Parse med JsonDocument.Parse i åsidosättningen CreateTicketAsync som visas i dotnet/aspnetcore#7105. JsonDocument implementerar IDisposable.

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

Kategori

ASP.NET Kärna

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 införd

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-störande sätt. Du behöver inte skapa nya ExchangeCodeAsync överladdningar.

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 OAuthHandler.ExchangeCodeAsync i stället för flera argument.

Kategori

ASP.NET Kärna

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 införd

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 Kärna

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 och stödsatt sätt för att uppnå starktypad, attributbaserad auktorisering när både konfiguration och beroendeinjektion krävs.

Version införd

3,0

Gammalt beteende

IAllowAnonymous dök upp 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 Kärna

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 reservprincipen används av auktoriseringsmellanprogrammet när ingen princip har angetts.

Mer information finns i dotnet/aspnetcore#9759.

Version införd

3,0

Gammalt beteende

Implementeringar av IAuthorizationPolicyProvider krävde inte någon GetFallbackPolicyAsync 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 GetFallbackPolicyAsync-metoden i dina implementeringar av IAuthorizationPolicyProvider.

Kategori

ASP.NET Kärna

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/Caching#221. Mer information finns i dotnet/extensions#1062.

Version införd

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 Kärna

Berörda API:er

MemoryCacheOptions.CompactOnMemoryPressure

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

Paketet Microsoft.Extensions.Caching.SqlServer kommer att använda det nya Microsoft.Data.SqlClient paketet i stället för System.Data.SqlClient 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 införd

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 arbete med nya funktioner kommer att utföras från och med nu.

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

Kategori

ASP.NET Kärna

Berörda API:er

Ingen

Cachelagring: ResponseCaching"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 störande förändringar i dessa projekt och begränsar möjligheten att underhålla ramverket.

Version införd

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 Kärna

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 använder Azure.Extensions.AspNetCore.DataProtection.Blobs 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 införd

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 Kärna

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 införd

3,0

Gammalt beteende

ANCM V1 ingår i Windows-värdtjänstpaketet.

Nytt beteende

ANCM V1 ingår inte i Windows Hosting-paketet.

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:

  • Har 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 Kärna

Berörda API:er

Ingen

Värd: Generisk värd begränsar injektion i startkonstruktorn

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ärdplattformen och en för appen. Därför stöder Startup-konstruktorn inte längre anpassad tjänstinjektion. 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 införd

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 Kärna

Berörda API:er

Ingen

Värdtjänst: HTTPS-omdirigering aktiverad för IIS-appar som körs utanför processen

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 införd

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 hoppar över som standardinställning.

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 att även aktivera UseHttpsRedirection-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 UseHttpsRedirection fortsätter att 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 Kärna

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 införd

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 . Varje användning av dessa dubbletttyper orsakar ett kompilatorfel för tvetydig referens när båda namnrymderna refereras till.

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

Föråldrade typer (varning):

Nya typer:

De nya tilläggsmetoderna IHostEnvironmentIsDevelopment och IsProduction finns i Microsoft.Extensions.Hosting namnområdet. Namnrymden kan behöva läggas till i ditt projekt.

Kategori

ASP.NET Kärna

Berörda API:er

Värdtjänst: ObjectPoolProvider har tagits bort från beroenden för WebHostBuilder

Som en del av att göra ASP.NET Core mer användningsbaserat, togs ObjectPoolProvider bort från huvudgruppen 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 införd

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 din komponent kräver ObjectPoolProvider, behöver den läggas till i dina beroenden via IServiceCollection.

Kategori

ASP.NET Kärna

Berörda API:er

Ingen

HTTP: Utökningsbarheten defaultHttpContext har tagits bort

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

Om dina enhetstester använder Mock<DefaultHttpContext>, använd i stället Mock<HttpContext> eller new DefaultHttpContext().

Mer information finns i dotnet/aspnetcore#6534.

Version införd

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 Kärna

Berörda API:er

Microsoft.AspNetCore.Http.DefaultHttpContext

HTTP: HeaderNames-konstanter har ändrats till statisk readonly

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 införd

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 som använder dessa fält på följande sätt kan inte längre göra det.

  • Som ett attributargument
  • Som en case i ett switch uttryck
  • 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 Kärna

Berörda API:er

Microsoft.Net.Http.Headers.HeaderNames

HTTP: Infrastrukturändringar för svarskropp

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 införd

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.Body, ersätter den hela IHttpResponseBodyFeature med en omslutning runt din angivna ström, med hjälp av StreamResponseBodyFeature 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 Kärna

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 införd

3,0

Gammalt beteende

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

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 emitterar cookies måste avgöra om SameSite ä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 Kärna

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ält och programhaverier. Från och med ASP.NET Core 3.0 Preview 3 inaktiveras dessa synkrona åtgärder som standard.

Berörda servrar:

  • Tornfalk
  • 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 Dispose, ska du i stället anropa det nya DisposeAsync API:et.

Mer information finns i dotnet/aspnetcore#7644.

Version införd

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ält och applikationshängningar. 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 Kärna

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 införd

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 överlagrade funktionen 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 Kärna

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 införd

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 Kärna

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 införd

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 principaler som standard avvisades av [Authorize] / RequireAuthenticatedUser().

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

Kategori

ASP.NET Kärna

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 införd

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 SignInManager manuellt, ange en implementering av IUserConfirmation eller hämta en från beroendeinjektionen för att tillhandahålla.

Kategori

ASP.NET Kärna

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 Identity UI antagit funktionen för statiska webbtillgångar:

  • Ramverk väljs genom att använda IdentityUIFrameworkVersion-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 införd

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 Kärna

Berörda API:er

IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder, UIFramework)

Kestrel: Anslutningskort 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. Anslutningskort ersätts med mellanprogram för anslutning (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 införd

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 visas i dotnet/aspnetcore#11412.

Kategori

ASP.NET Kärna

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 införd

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 Kärna

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-förfrågningstrailers 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 införd

3,0

Gammalt beteende

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

Nytt beteende

Begärandehuvuden inte i samlingen. Använd följande tilläggsmetoder på HttpRequest för 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 förfrågan stöder mottagning av trailer-rubriker.
  • CheckTrailersAvailable() – Avgör om begäran stöder trailerfält 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 Kärna

Berörda API:er

HttpRequest.Headers

Kestrel: Transportabstraktioner har tagits bort och offentliggjorts

Som en del av att avveckla "pubternal" API:er exponeras transportskiktets API:er i Kestrel som ett offentligt gränssnitt i Microsoft.AspNetCore.Connections.Abstractions-biblioteket.

Version införd

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 övergett "pubternal" API:er.

Kategori

ASP.NET Kärna

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 när det körs. För att eliminera förvirringskällan har API:erna markerats som föråldrade i ASP.NET Core 3.0. API:erna tas bort i en framtida version.

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

Version införd

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 Kärna

Berörda API:er

  • Microsoft.Extensions.Localization.ResourceManagerWithCultureStringLocalizer
  • Microsoft.Extensions.Localization.ResourceManagerStringLocalizer.WithCulture

Loggning: DebugLogger-klassen har gjorts till en intern klass

Innan ASP.NET Core 3.0, DebugLogger var det public åtkomstmodifieraren. I ASP.NET Core 3.0 ändrades åtkomstmodifieraren till internal.

Version införd

3,0

Orsak till ändringen

Ändringen görs för att:

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

AddDebug ILoggingBuilder 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 Kärna

Berörda API:er

Microsoft.Extensions.Logging.Debug.DebugLogger

MVC: Async-suffix trimmat från kontrollerens aktionsnamn

Som en del av att adressera 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 införd

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 ställa in MvcOptions.SuppressAsyncSuffixInActionNames till false i Startup.ConfigureServices.

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

Orsak till ändringen

Enligt konvention suffikseras asynkrona .NET-metoder 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 suffixet i namnet Async, välj 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 till false i Startup.ConfigureServices.
services.AddMvc(options =>
{
   options.SuppressAsyncSuffixInActionNames = false;
});

Kategori

ASP.NET Kärna

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 införd

3.0 Förhandsversion 6

Gammalt beteende

En app som använder ett bibliotek baserat på 2.2 byggs framgångsrikt.

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. Om du påverkas, kontakta biblioteksförfattaren. Begär omkompilering av biblioteket för att rikta in sig på ASP.NET Core 3.0.

Kategori

ASP.NET Kärna

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 av Razor-filer vid bygg- och publiceringstillfället. 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, från ASP.NET Core 1.1-eran, bort. Tidigare paketversioner fortsätter att ta emot viktiga bugg- och säkerhetskorrigeringar i korrigeringsversionen.

Version införd

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 Kärna

Berörda API:er

Ingen

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

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 public, har de ingen stödriktlinje och är föremål för förändringar som kan bryta kompatibilitet. Tyvärr har oavsiktlig användning av dessa typer varit vanligt, vilket resulterar i störande förändringar i dessa projekt och begränsar möjligheten att underhålla ramverket.

Version införd

3,0

Gammalt beteende

Vissa typer i MVC var public men i ett .Internal namnområde. Dessa typer hade ingen supportpolicy och var föremål för brytande förändringar.

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 oförenliga ändringar i dessa projekt och begränsat möjligheten att underhålla ramverket.

Om du använder typer som har blivit verkligt public och har flyttats till en ny, stödd namnrymd, uppdatera 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 Kärna

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 införd

3,0

Orsak till ändringen

Webb-API-kompatibilitetsskikt 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 Kärna

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.

För diskussion, se GitHub-ärende dotnet/aspnetcore#25215.

Version införd

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 man försökte konfigurera en Razor-parsnings- och 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 Kärna

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 införd

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 i Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions för att möjliggöra 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 Kärna

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 införd

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 Kärna

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 störande ändringar i Microsoft.AspNetCore.App.

Version införd

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:erna som paketen tillhandahåller är fortfarande tillgängliga för appar genom att använda en <FrameworkReference> till 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 skapas av ASP.NET Core-teamet som inte ingår i Microsoft.AspNetCore.App. 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 Kärna

Berörda API:er

Delat ramverk: Microsoft.AspNetCore.All har tagits bort

Från och med ASP.NET Core 3.0 skapas metapaketet Microsoft.AspNetCore.All och det matchande delade ramverket Microsoft.AspNetCore.All inte längre. 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 införd

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 Kärna

Berörda API:er

Ingen

SignalR: HandshakeProtocol.SuccessHandshakeData har ersatts

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

Version införd

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 Kärna

Berörda API:er

HandshakeProtocol.SuccessHandshakeData

SignalR: Metoderna HubConnection 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 införd

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 Kärna

Berörda API:er

SignalR: HubConnectionContext-konstruktorer har ändrats

SignalR:s konstruktorer har ändrats för att acceptera en optionstyp istället för flera parametrar, för att framtidssäkra möjligheten att lägga till alternativ. Den här ändringen ersätter två konstruktorer med en enda konstruktor som accepterar en alternativtyp.

Version införd

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 Kärna

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 införd

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 Kärna

Berörda API:er

Ingen

SignalR: UseSignalR- och UseConnections-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 införd

3,0

Gammalt beteende

SignalR Hub-routning har konfigurerats med UseSignalR eller UseConnections.

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 Kärna

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 införd

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 Kärna

Berörda API:er

SPAs: SpaServices och NodeServices återgår inte längre till att använda konsolloggern

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

Version införd

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 Kärna

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 införd

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 Kärna

Berörda API:er

Ingen

.NET Core-bibliotek

API som nu rapporterar produktversion 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 assembly för .NET Core 2.2 (till vänster) och .NET Core 3.0 (till höger) som visas i Utforskarens filegenskaper i Windows dialogruta.

Skillnad i produktversionsinformation

Version införd

3,0

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

Kategori

.NET Core-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örtiden försöker sedan transkodar dessa ersättningstecken till den önskade kodningen. Om den här åtgärden lyckas fortsätter processen att transkoda från den punkt där det slutade i den ursprungliga indata-strä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 programmet slutligen ser en korrekt formulerad och omvandlingsbar ersättning eller tills ett maximalt rekursionstal 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örtiden 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örningsmiljön identifierar en felkonstruerad UTF-16-sekvens eller en UTF-16-sekvens som inte kan konverteras till målkodningen.
  • En anpassad EncoderFallback har angetts.
  • Det anpassade EncoderFallback försöket att ersätta en ny felformad eller icke-konverterbar UTF-16-sekvens.

Version införd

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

.NET Core-bibliotek

Berörda API:er

Flyttalsformatering och parseringsbeteende har ändrats

Flyttalsparsning och formateringsbeteende (av typerna Double och Single) ä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 kan återställas till sitt ursprungliga tillstånd med någon av de standard- eller anpassade formatsträngar 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

För mer information, se blogginlägget Förbättringar av flyttalsparsning och formatering i .NET Core 3.0.

Version införd

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

.NET Core-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 för Single eller Double flyttalstypen.

Ändra beskrivning

I .NET Core 2.2 och tidigare versioner kastar metoderna Double.Parse 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. Parsningsmetoderna returnerar i stället Double för värden som överskrider Double.PositiveInfinity, och de returnerar Double.MaxValue för värden som är mindre än Double.NegativeInfinity. På samma sätt returnerar parsningsmetoderna Single för värden som överskrider Single.PositiveInfinity, och de returnerar Single.MaxValue för värden som är mindre än Single.NegativeInfinity.Single.MinValue

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

Version införd

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 för att utföras när ett överflöd 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 är Infinity. I det här fallet bör du lägga till nödvändig kod för att söka efter flyttalsvärden för PositiveInfinity och NegativeInfinity.

Kategori

.NET Core-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 finns klassen InvalidAsynchronousStateException i assemblyn System.ComponentModel.TypeConverter.

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

Version införd

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

.NET Core-bibliotek

Berörda API:er

Inga.

Ersättande av 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 kodas om till tecken, utför klassen UTF8Encoding teckenersättning baserat på Unicodes bästa praxis. 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-teckens utdata är det önskade utdata, enligt tabell 3-9 i den tidigare länkade Unicode Standard-PDF.

Version införd

3,0

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

Kategori

.NET Core-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 finns klassen TypeDescriptionProviderAttribute i sammansättningen System.ComponentModel.TypeConverter.

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

Version införd

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-formulär

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 fortsätter ZipArchiveEntry.Open() även om det lokala huvudet inte överensstämmer 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 kontrollerar Metoden ZipArchiveEntry.Open() att det lokala huvudet och det centrala huvudet är överens om komprimerade och okomprimerade storlekar på en post. Om de inte gör det, kastar metoden ett InvalidDataException om storlekarna för arkivets lokala huvud och/eller databeskrivningslistan inte överensstämmer med zip-filens centrala katalog. När du läser en post begränsas de dekomprimerade data till den okomprimerade filstorlek som anges i titeln.

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 införd

3,0

Packa om alla zip-arkiv som uppvisar dessa problem.

Kategori

.NET Core-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 kunde du sätta värdet på ett statiskt fält som är konstant efter att ha blivit initierat (readonly-attributet i C#) genom att anropa . 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 på ett statiskt InitOnly-fält i .NET Core 3.0 och senare versioner kastas ett System.FieldAccessException-undantag.

Tips

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 införd

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

.NET Core-bibliotek

Berörda API:er

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

När du anropar en tilläggsmetod som tar en IEnumerable<T> på en GroupCollection, måste du tydliggöra typen med en typomvandling.

Ändra beskrivning

Från och med .NET Core 3.0 implementerar System.Text.RegularExpressions.GroupCollectionIEnumerable<KeyValuePair<String,Group>> utöver de andra typerna den implementerar, inklusive IEnumerable<Group>. Detta resulterar i tvetydighet när du anropar en tilläggsmetod som tar en IEnumerable<T>. Om du till exempel GroupCollectionanropar en sådan tilläggsmetod på en Enumerable.Count 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 införd

3,0

Orsak till ändringen

Detta var en oavsiktlig brytä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

.NET Core-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 innehållet i rotcertifikatet laddas inte längre av kedjemotorn från och med .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, läses inte längre innehållet i BEGIN TRUSTED CERTIFICATE. Om certifikatet inte också anges via en standard BEGIN CERTIFICATE syntax, rapporterar X509Chain att roten inte är betrodd (X509ChainStatusFlags.UntrustedRoot).

Version införd

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 sammanfogning till en enda fil. i vissa distributioner använder katalogen för ett-certifikat-per-fil syntaxen BEGIN TRUSTED CERTIFICATE, medan filsammanfogning 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 använder som standard 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 införd

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 som rapporterats av egenskapen LegalKeySizes på RSA-instanser från RSA.Create, RSAOpenSsl och RSACryptoServiceProvider på 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 införd

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.

Anteckning

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 föredrar runtime att ladda OpenSSL 1.1.x över OpenSSL 1.0.x, så IntPtr 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 i första hand. 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 införd

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

I tidigare .NET-versioner, om en användare utförde en ofullständig läsning när CryptoStream användes i Read-läge, kunde metoden Dispose utlösa ett undantag (till exempel vid användning av 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 införd

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äses innan den stängs.

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. en_US_POSIX-lokalen har ett oönskat sorteringsbeteende eftersom den inte stöder skiftlägesinsensitiva strängjämförelser. Eftersom vissa Linux-distributioner anger "C"-locale som standard-locale upplevde 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 införd

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 införd

3,0

Ändra beskrivning

Innan .NET Core 3.0, om inga LogicalName, ManifestResourceName eller DependentUpon metadata angavs för ett EmbeddedResource-objekt i projektfilen, genererade MSBuild ett manifestfilnamn i mönstret <RootNamespace>.<ResourceFilePathFromProjectRoot>.resources. 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 samma källfil. 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).

Anteckning

Om du har LogicalName, ManifestResourceName eller DependentUpon-metadata specificerat på ett EmbeddedResource-objekt i projektfilen så påverkar den här ändringen inte den resursfilen.

Den här icke-bakåtkompatibla ändringen introducerades med tillägget av EmbeddedResourceUseDependentUponConvention-egenskapen till .NET Core-projekten. 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.

  • Avstå från den nya namngivningskonventionen genom att ställa in EmbeddedResourceUseDependentUponConvention till false i 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 införd

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

Windows-formulär

Standardkontrollteckensnittet har ändrats till Segoe UI 9 pt

Ändra beskrivning

I .NET Framework har egenskapen Control.DefaultFont angetts till Microsoft Sans Serif 8.25 pt. Följande bild visar ett fönster som använder standardteckensnittet.

Standardkontrollteckensnitt i .NET Framework

Från och med .NET Core 3.0 är standardteckensnittet inställt på Segoe UI 9 pt (samma teckensnitt som SystemFonts.MessageBoxFont). Som ett resultat av den här ändringen är formulär och kontroller ungefär 27% större för att ta hänsyn till den större storleken på det nya standardteckensnittet. Till exempel:

Standardkontrollteckensnitt i .NET Core

Den här ändringen gjordes i enlighet med riktlinjer för Windows-användarupplevelse (UX).

Version införd

3,0

På grund av ändringen i storleken på formulär och kontroller kontrollerar du att programmet renderas korrekt.

Om du vill behålla det ursprungliga teckensnittet för ett enskilt formulär anger du standardteckensnittet till Microsoft Sans Serif 8.25 pt. Till exempel:

public MyForm()
{
    InitializeComponent();
    Font = new Font(new FontFamily("Microsoft Sans Serif"), 8.25f);
}

Du kan också ändra standardteckensnittet för ett helt program på något av följande sätt:

  • Genom att ange egenskapen ApplicationDefaultFont MSBuild till "Microsoft Sans Serif, 8.25pt". Det här är den bästa tekniken eftersom det gör att Visual Studio kan använda de nya inställningarna i designern.

    <PropertyGroup>
  <ApplicationDefaultFont>Microsoft Sans Serif, 8.25pt</ApplicationDefaultFont>
</PropertyGroup>

  • Genom att anropa Application.SetDefaultFont(Font).

    class Program
{
    [STAThread]
    static void Main()
    {
        Application.EnableVisualStyles();
        Application.SetCompatibleTextRenderingDefault(false);
        Application.SetHighDpiMode(HighDpiMode.SystemAware);
        Application.SetDefaultFont(new Font(new FontFamily("Microsoft Sans Serif"), 8.25f));
        Application.Run(new Form1());
    }
}

Kategori

  • Windows-formulär

Berörda API:er

Inga.

Modernisering av FolderBrowserDialog

Kontrollen FolderBrowserDialog har ändrats i Windows Forms-program för .NET Core.

Ändra beskrivning

I .NET Framework använder Windows-formulär följande dialogruta för FolderBrowserDialog-kontrollen:

FolderBrowserDialogControl i .NET Frameworket

I .NET Core 3.0 använder Windows Forms en nyare COM-baserad kontroll som introducerades i Windows Vista:

FolderBrowserDialogControl i .NET Core

Version införd

3,0

Dialogrutan uppgraderas automatiskt.

Om du vill behålla den ursprungliga dialogrutan anger du egenskapen FolderBrowserDialog.AutoUpgradeEnabled till false innan du visar dialogrutan, vilket illustreras av följande kodfragment:

var dialog = new FolderBrowserDialog();
dialog.AutoUpgradeEnabled = false;
dialog.ShowDialog();

Kategori

Windows-formulär

Berörda API:er

SerializableAttribute har tagits bort från vissa Typer av Windows-formulär

SerializableAttribute har tagits bort från vissa Windows Forms-klasser som inte har några kända scenarier med binär serialisering.

Ändra beskrivning

Följande typer är dekorerade med SerializableAttribute i .NET Framework, men attributet har tagits bort i .NET Core:

Tidigare har den här serialiseringsmekanismen haft allvarliga underhålls- och säkerhetsproblem. Att underhålla SerializableAttribute på typer innebär att dessa typer måste testas för serialiseringsändringar från version till version och potentiellt serialiseringsändringar från ramverk till ramverk. Detta gör det svårare att utveckla dessa typer och kan vara kostsamt att underhålla. Dessa typer har inga kända scenarier för binär serialisering, vilket minimerar effekten av att ta bort attributet.

För mer information, se binär serialisering.

Version införd

3,0

Uppdatera all kod som kan vara beroende av att dessa typer markeras som serialiserbara.

Kategori

Windows-formulär

Berörda API:er

  • Ingen

AllowUpdateChildControlIndexForTabControls-kompatibilitetsväxeln stöds inte

Kompatibilitetsväxeln Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls stöds i Windows Forms i .NET Framework 4.6 och senare versioner, men stöds inte på .NET Core eller .NET 5.0 och senare.

Ändra beskrivning

Om du väljer en flik i .NET Framework 4.6 och senare versioner, ordnas dess kontrollsamling om. Med Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls kompatibilitetsväxel kan ett program hoppa över den här omordningen när det här beteendet är oönskat.

I .NET Core och .NET 5.0 och senare stöds inte växeln Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls.

Version införd

3,0

Ta bort växeln. Växeln stöds inte och inga alternativa funktioner är tillgängliga.

Kategori

Windows-formulär

Berörda API:er

  • Ingen

DomainUpDown.UseLegacyScrolling-kompatibilitetsväxeln stöds inte

Den Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling kompatibilitetsväxeln, som introducerades i .NET Framework 4.7.1, stöds inte i Windows Forms på .NET Core eller .NET 5.0 och senare.

Ändra beskrivning

Från och med .NET Framework 4.7.1 gjorde Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling-kompatibilitetsswitchen det möjligt för utvecklare att välja bort oberoende DomainUpDown.DownButton()- och DomainUpDown.UpButton()-funktioner. Växeln återställde det äldre beteendet, där DomainUpDown.UpButton() ignoreras om kontexttext finns, och utvecklaren måste använda DomainUpDown.DownButton() åtgärd på kontrollen innan åtgärden DomainUpDown.UpButton(). Mer information finns i <AppContextSwitchOverrides> element.

I .NET Core och .NET 5.0 och senare stöds inte växeln Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling.

Version införd

3,0

Ta bort växeln. Växeln stöds inte och inga alternativa funktioner är tillgängliga.

Kategori

Windows-formulär

Berörda API:er

DoNotLoadLatestRichEditControl-kompatibilitetsväxeln stöds inte

Den Switch.System.Windows.Forms.UseLegacyImages kompatibilitetsväxeln, som introducerades i .NET Framework 4.7.1, stöds inte i Windows Forms på .NET Core eller .NET 5.0 och senare.

Ändra beskrivning

I .NET Framework 4.6.2 och tidigare versioner instansierar RichTextBox kontrollen Win32 RichEdit-kontrollen v3.0 och för program som riktar in sig på .NET Framework 4.7.1 instansierar RichTextBox kontrollen RichEdit v4.1 (i msftedit.dll). Den Switch.System.Windows.Forms.DoNotLoadLatestRichEditControl kompatibilitetsväxeln introducerades för att tillåta program som riktar sig mot .NET Framework 4.7.1 och senare versioner att välja bort den nya RichEdit v4.1-kontrollen och använda den gamla RichEdit v3-kontrollen i stället.

I .NET Core- och .NET 5.0- och senare versioner stöds inte växeln Switch.System.Windows.Forms.DoNotLoadLatestRichEditControl. Endast nya versioner av RichTextBox-kontrollen stöds.

Version införd

3,0

Ta bort växeln. Växeln stöds inte och inga alternativa funktioner är tillgängliga.

Kategori

Windows-formulär

Berörda API:er

DoNotSupportSelectAllShortcutInMultilineTextBox-kompatibilitetsväxeln stöds inte

Den Switch.System.Windows.Forms.DoNotSupportSelectAllShortcutInMultilineTextBox kompatibilitetsväxeln, som introducerades i .NET Framework 4.6.1, stöds inte i Windows Forms på .NET Core och .NET 5.0 och senare.

Ändra beskrivning

Från och med .NET Framework 4.6.1 väljer du Ctrl + En genvägsnyckel i en TextBox kontroll markerade all text. I .NET Framework 4.6 och tidigare versioner kunde du inte välja Ctrl + En genvägsnyckel kunde inte markera all text om Textbox.ShortcutsEnabled och TextBox.Multiline egenskaper båda var inställda på true. Kompatibilitetsväxeln Switch.System.Windows.Forms.DoNotSupportSelectAllShortcutInMultilineTextBox introducerades i .NET Framework 4.6.1 för att behålla det ursprungliga beteendet. Mer information finns i TextBox.ProcessCmdKey.

I .NET Core- och .NET 5.0- och senare versioner stöds inte växeln Switch.System.Windows.Forms.DoNotSupportSelectAllShortcutInMultilineTextBox.

Version införd

3,0

Ta bort växeln. Växeln stöds inte och inga alternativa funktioner är tillgängliga.

Kategori

Windows-formulär

Berörda API:er

  • Ingen

DontSupportReentrantFilterMessage-kompatibilitetsväxeln stöds inte

Den Switch.System.Windows.Forms.DontSupportReentrantFilterMessage kompatibilitetsväxeln, som introducerades i .NET Framework 4.6.1, stöds inte i Windows Forms på .NET Core och .NET 5.0 och senare.

Ändra beskrivning

Från och med .NET Framework 4.6.1 löser Switch.System.Windows.Forms.DontSupportReentrantFilterMessage kompatibilitetsväxling möjliga IndexOutOfRangeException undantag när Application.FilterMessage-meddelandet anropas med en anpassad IMessageFilter.PreFilterMessage implementering. Mer information finns i Mitigation: Custom IMessageFilter.PreFilterMessage Implementations.

I .NET Core och .NET 5.0 och senare stöds inte växeln Switch.System.Windows.Forms.DontSupportReentrantFilterMessage.

Version införd

3,0

Ta bort växeln. Växeln stöds inte och inga alternativa funktioner är tillgängliga.

Kategori

Windows-formulär

Berörda API:er

EnableVisualStyleValidation-kompatibilitetsväxeln stöds inte

Kompatibilitetsväxeln Switch.System.Windows.Forms.EnableVisualStyleValidation stöds inte i Windows Forms på .NET Core eller .NET 5.0 och senare.

Ändra beskrivning

I .NET Framework tillät Switch.System.Windows.Forms.EnableVisualStyleValidation-kompatibilitetsväxeln en applikation att inte delta i valideringen av visuella format som tillhandahålls i numerisk form.

I .NET Core och .NET 5.0 och senare stöds inte växeln Switch.System.Windows.Forms.EnableVisualStyleValidation.

Version införd

3,0

Ta bort växeln. Växeln stöds inte och inga alternativa funktioner är tillgängliga.

Kategori

Windows-formulär

Berörda API:er

  • Ingen

Kompatibilitetsväxeln UseLegacyContextMenuStripSourceControlValue stöds inte

Den Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue kompatibilitetsväxeln, som introducerades i .NET Framework 4.7.2, stöds inte i Windows Forms på .NET Core eller .NET 5.0 och senare.

Ändra beskrivning

Från och med .NET Framework 4.7.2 gör Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue kompatibilitetsväxeln att utvecklaren kan välja bort det nya beteendet för egenskapen ContextMenuStrip.SourceControl, som nu returnerar en referens till källkontrollen. Det tidigare beteendet för egenskapen var att returnera null. Mer information finns i <AppContextSwitchOverrides> element.

I .NET Core och .NET 5.0 och senare stöds inte växeln Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue.

Version införd

3,0

Ta bort växeln. Växeln stöds inte och inga alternativa funktioner är tillgängliga.

Kategori

Windows-formulär

Berörda API:er

UseLegacyImages kompatibilitetsväxel stöds inte

Kompatibilitetsväxeln Switch.System.Windows.Forms.UseLegacyImages, som introducerades i .NET Framework 4.8, stöds inte i Windows Forms på .NET Core eller .NET 5.0 och senare.

Ändra beskrivning

Från och med .NET Framework 4.8 åtgärdade Switch.System.Windows.Forms.UseLegacyImages kompatibilitetsväxeln möjliga problem med bildskalning i ClickOnce-scenarier i miljöer med hög DPI. När den är inställd på truetillåter växeln att användaren återställer äldre bildskalning på höga DPI-skärmar vars skala är inställd på större än 100%. Mer information finns i .NET Framework 4.8 Versionsinformation på GitHub.

I .NET Core och .NET 5.0 och senare stöds inte växeln Switch.System.Windows.Forms.UseLegacyImages.

Version införd

3,0

Ta bort växeln. Växeln stöds inte och inga alternativa funktioner är tillgängliga.

Kategori

Windows-formulär

Berörda API:er

  • Ingen

Om-sidan och SplashScreen-sidan har slutat fungera

De About.vb- och SplashScreen.vb filer som genereras av Visual Studio innehåller referenser till typer i My namnrymd som inte är tillgängliga .NET Core 3.0 och 3.1.

Version införd

3,0

Ändra beskrivning

.NET Core 3.0 och 3.1 innehåller inte fullständigt stöd för Visual Basic My. Referensegenskaperna för Om och SplashScreen formulärmallar i Visual Studio för Visual Basic Windows Forms-appar refererar till egenskaper i My.Application.Info-typen som inte är tillgängliga.

Stödet för Visual Basic My har förbättrats i .NET 5. Uppgradera ditt projekt till .NET 5 eller senare.

-eller-

Åtgärda kompilatorfelen i About och SplashScreen-typerna i din app. Använd klassen System.Reflection.Assembly för att hämta den information som tillhandahålls av My.Application.Info typ. En rak port för båda formulären finns här.

Tips

Det här är exempelkod och ej optimerad. Listan över attribut ska cachelagras för att minska tiden för formulärinläsning.

Om

Imports System.Reflection

Public NotInheritable Class About

    Private Sub about_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        ' Set the title of the form.
        Dim applicationTitle As String = Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyTitleAttribute)()?.Title

        If String.IsNullOrEmpty(applicationTitle) Then
            applicationTitle = System.IO.Path.GetFileNameWithoutExtension(Assembly.GetExecutingAssembly().GetName().Name)
        End If

        Me.Text = String.Format("About {0}", applicationTitle)
        ' Initialize all of the text displayed on the About Box.
        ' TODO: Customize the application's assembly information in the "Application" pane of the project
        '    properties dialog (under the "Project" menu).
        Me.LabelProductName.Text = If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyProductAttribute)()?.Product, "")
        Me.LabelVersion.Text = String.Format("Version {0}", Assembly.GetExecutingAssembly().GetName().Version)
        Me.LabelCopyright.Text = If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyCopyrightAttribute)()?.Copyright, "")
        Me.LabelCompanyName.Text = If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyCompanyAttribute)()?.Company, "")
        Me.TextBoxDescription.Text = If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyDescriptionAttribute)()?.Description, "")
    End Sub

    Private Sub OKButton_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles OKButton.Click
        Me.Close()
    End Sub

End Class

SplashScreen

Imports System.Reflection

Public NotInheritable Class SplashScreen

    Private Sub SplashScreen1_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
        'Set up the dialog text at runtime according to the application's assembly information.  

        'TODO: Customize the application's assembly information in the "Application" pane of the project
        '  properties dialog (under the "Project" menu).

        'Application title
        Dim appTitle As String = Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyTitleAttribute)()?.Title

        If String.IsNullOrEmpty(appTitle) Then
            appTitle = System.IO.Path.GetFileNameWithoutExtension(Assembly.GetExecutingAssembly().GetName().Name)
        End If

        ApplicationTitle.Text = appTitle

        Dim versionValue = Assembly.GetExecutingAssembly().GetName().Version

        'Format the version information using the text set into the Version control at design time as the
        '  formatting string.  This allows for effective localization if desired.
        '  Build and revision information could be included by using the following code and changing the
        '  Version control's designtime text to "Version {0}.{1:00}.{2}.{3}" or something similar.  See
        '  String.Format() in Help for more information.
        '
        '    Version.Text = System.String.Format(Version.Text, versionValue.Major, versionValue.Minor, versionValue.Build, versionValue.Revision)

        Version.Text = System.String.Format(Version.Text, versionValue.Major, versionValue.Minor)

        'Copyright info
        Copyright.Text = If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyCopyrightAttribute)()?.Copyright, "")
    End Sub

End Class

Kategori

Visual Basic Windows Forms

Berörda API:er

Ingen

WPF (Windows Presentation Foundation)

Ändrat drag-och-släpp-beteende i textredigerare

.NET Core 3.0 introducerade en ändring i hur textredigerarens kontroller skapar en System.Windows.DataObject när text dras till en annan kontroll. Ändringen inaktiverade autokonverteringen, vilket gör att åtgärden behåller data som DataFormats.Text eller DataFormats.UnicodeText i stället för att konvertera dem till DataFormats.StringFormat.

Version införd

.NET Core 3.0

Kategori

Windows Presentation Foundation

Tidigare beteende

Datatypen på System.Windows.DataObject när man drar text från en textredigerarkontroll var DataFormats.StringFormat.

Nytt beteende

Datatypen på System.Windows.DataObject när du drar text från en textredigerare är DataFormats.Text eller DataFormats.UnicodeText.

Typ av brytande ändring

Den här ändringen är en beteendeförändring.

Orsak till ändringen

Ändringen var oavsiktlig.

Den här ändringen återställdes i .NET 7. Uppgradera till .NET 7 eller senare.

Berörda API:er

Se även