Zmiany powodujące niezgodność w programie .NET Core 3.0

  • Artykuł

Jeśli przeprowadzasz migrację do wersji 3.0 platformy .NET Core, ASP.NET Core lub EF Core, zmiany powodujące niezgodność wymienione w tym artykule mogą mieć wpływ na twoją aplikację.

ASP.NET Core

Usunięte przestarzałe interfejsy API antiforgery, CORS, Diagnostics, MVC i Routing

Przestarzałe elementy członkowskie i przełączniki zgodności w systemie ASP.NET Core 2.2 zostały usunięte.

Wprowadzona wersja

3.0

Przyczyna wprowadzenia zmiany

Poprawa powierzchni interfejsu API w czasie.

W przypadku platformy .NET Core 2.2 postępuj zgodnie ze wskazówkami w przestarzałych komunikatach kompilacji, aby zamiast tego wdrażać nowe interfejsy API.

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Następujące typy i elementy członkowskie zostały oznaczone jako przestarzałe dla ASP.NET Core 2.1 i 2.2:

Typy

  • 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

Konstruktory

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

Właściwości

  • 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

Metody

Usunięte interfejsy API "Pubternal"

Aby lepiej utrzymać publiczną powierzchnię interfejsu API ASP.NET Core, większość typów przestrzeni *.Internal nazw (nazywanych "pubternal" interfejsami API) stała się naprawdę wewnętrzna. Członkowie tych przestrzeni nazw nigdy nie mieli być obsługiwani jako publiczne interfejsy API. Interfejsy API mogą przerywać wersje pomocnicze i często działały. Kod zależny od tych interfejsów API przerywa aktualizację do ASP.NET Core 3.0.

Aby uzyskać więcej informacji, zobacz dotnet/aspnetcore#4932 i dotnet/aspnetcore#11312.

Wprowadzona wersja

3.0

Stare zachowanie

Objęte interfejsy API są oznaczone modyfikatorem public dostępu i istnieją w *.Internal przestrzeniach nazw.

Nowe zachowanie

Objęte interfejsy API są oznaczone modyfikatorem dostępu wewnętrznego i nie mogą być już używane przez kod poza tym zestawem.

Przyczyna wprowadzenia zmiany

Wskazówki dotyczące tych "pubternal" interfejsów API były następujące:

  • Można zmienić bez powiadomienia.
  • Nie podlegały zasadom platformy .NET, aby zapobiec zmianom powodujących niezgodność.

Pozostawienie interfejsów public API (nawet w *.Internal przestrzeniach nazw) było mylące dla klientów.

Przestań używać tych "pubternal" interfejsów API. Jeśli masz pytania dotyczące alternatywnych interfejsów API, otwórz problem w repozytorium dotnet/aspnetcore .

Rozważmy na przykład następujący kod buforowania żądania HTTP w projekcie ASP.NET Core 2.2. Metoda EnableRewind rozszerzenia istnieje w Microsoft.AspNetCore.Http.Internal przestrzeni nazw.

HttpContext.Request.EnableRewind();

W projekcie ASP.NET Core 3.0 zastąp EnableRewind wywołanie wywołaniem EnableBuffering metody rozszerzenia. Funkcja buforowania żądania działa tak jak w przeszłości. EnableBuffering wywołuje teraz internal interfejs API.

HttpContext.Request.EnableBuffering();

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Wszystkie interfejsy API w Microsoft.AspNetCore.* przestrzeniach nazw i Microsoft.Extensions.* , które mają Internal segment w nazwie przestrzeni nazw. Na przykład:

  • 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

Uwierzytelnianie: przestarzałe i zastąpione przez firmę Google+

Firma Google zaczyna zamykać logowanie Google+ dla aplikacji już 28 stycznia 2019 r.

Opis zmiany

ASP.NET 4.x i ASP.NET Core używają interfejsów API logowania Google+ do uwierzytelniania użytkowników kont Google w aplikacjach internetowych. Pakiety NuGet, których dotyczy problem, to Microsoft.AspNetCore.Authentication.Google dla platformy ASP.NET Core i Microsoft.Owin.Security.Google dla Microsoft.Owin programu ASP.NET Web Forms i MVC.

Interfejsy API zastępcze firmy Google używają innego źródła danych i formatu. Środki zaradcze i rozwiązania przedstawione poniżej uwzględniają zmiany strukturalne. Aplikacje powinny sprawdzić, czy same dane nadal spełniają swoje wymagania. Na przykład nazwy, adresy e-mail, linki do profilów i zdjęcia profilowe mogą zawierać subtelnie inne wartości niż wcześniej.

Wprowadzona wersja

Wszystkie wersje. Ta zmiana jest zewnętrzna dla ASP.NET Core.

Owin z ASP.NET Web Forms i MVC

W przypadku Microsoft.Owin wersji 3.1.0 lub nowszej przedstawiono tymczasowe środki zaradcze. Aplikacje powinny zakończyć testowanie za pomocą środków zaradczych, aby sprawdzić zmiany w formacie danych. Istnieją plany wydania Microsoft.Owin wersji 4.0.1 z poprawką. Aplikacje korzystające z poprzedniej wersji powinny zostać zaktualizowane do wersji 4.0.1.

ASP.NET Core 1.x

Środki zaradcze w usłudze Owin za pomocą ASP.NET Web Forms i MVC można dostosować do ASP.NET Core 1.x. Poprawki pakietów NuGet nie są planowane, ponieważ wersja 1.x osiągnęła stan zakończenia życia .

ASP.NET Core 2.x

W przypadku Microsoft.AspNetCore.Authentication.Google wersji 2.x zastąp istniejące wywołanie metody AddGoogle w pliku Startup.ConfigureServices następującym kodem:

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

Poprawki z lutego 2.1 i 2.2 zawierały poprzednią ponowną konfigurację jako nową domyślną. Żadna poprawka nie jest planowana na ASP.NET Core 2.0, ponieważ osiągnęła koniec życia.

ASP.NET Core 3.0

Środki zaradcze podane dla ASP.NET Core 2.x można również użyć do ASP.NET Core 3.0. W przyszłych wersji zapoznawczych Microsoft.AspNetCore.Authentication.Google 3.0 pakiet może zostać usunięty. Użytkownicy będą zamiast tego kierowani do Microsoft.AspNetCore.Authentication.OpenIdConnect . Poniższy kod pokazuje, jak zastąpić AddGoogle ciąg ciągiem AddOpenIdConnect w pliku Startup.ConfigureServices. Tego zastąpienia można używać z ASP.NET Core 2.0 lub nowszym i można go dostosować do ASP.NET Core 1.x zgodnie z potrzebami.

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

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Microsoft.AspNetCore.Authentication.Google

Uwierzytelnianie: usunięto właściwość HttpContext.Authentication

Właściwość przestarzała AuthenticationHttpContext została usunięta.

Opis zmiany

W ramach polecenia dotnet/aspnetcore#6504 właściwość HttpContext przestarzała Authentication została usunięta. Właściwość Authentication jest przestarzała od wersji 2.0. Przewodnik migracji został opublikowany w celu przeprowadzenia migracji kodu przy użyciu tej przestarzałej właściwości do nowych zastępczych interfejsów API. Pozostałe nieużywane klasy/interfejsy API związane ze starym stosem uwierzytelniania ASP.NET Core 1.x zostały usunięte w zatwierdzaniu dotnet/aspnetcore@d7a7c65.

Aby zapoznać się z dyskusją, zobacz dotnet/aspnetcore#6533.

Wprowadzona wersja

3.0

Przyczyna wprowadzenia zmiany

interfejsy API platformy ASP.NET Core 1.0 zostały zastąpione metodami rozszerzeń w programie Microsoft.AspNetCore.Authentication.AuthenticationHttpContextExtensions.

Zobacz przewodnik migracji.

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Uwierzytelnianie: zastąpiono typy Newtonsoft.Json

W ASP.NET Core 3.0 Newtonsoft.Json typy używane w interfejsach API uwierzytelniania zostały zastąpione typami System.Text.Json . Z wyjątkiem następujących przypadków podstawowe użycie pakietów uwierzytelniania pozostaje niezmienione:

  • Klasy pochodzące od dostawców OAuth, takich jak te z aspnet-contrib.
  • Zaawansowane implementacje manipulowania oświadczeniami.

Aby uzyskać więcej informacji, zobacz dotnet/aspnetcore#7105. Aby zapoznać się z dyskusją, zobacz dotnet/aspnetcore#7289.

Wprowadzona wersja

3.0

W przypadku pochodnych implementacji protokołu OAuth najczęstszą zmianą jest zastąpienie JObject.Parse wartością JsonDocument.Parse w CreateTicketAsync zastąpieniu, jak pokazano tutaj. JsonDocument implementuje IDisposable.

Na poniższej liście przedstawiono znane zmiany:

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Uwierzytelnianie: zmieniono podpis OAuthHandler ExchangeCodeAsync

W ASP.NET Core 3.0 podpis OAuthHandler.ExchangeCodeAsync został zmieniony z:

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

Do:

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

Wprowadzona wersja

3.0

Stare zachowanie

Ciągi code i redirectUri zostały przekazane jako oddzielne argumenty.

Nowe zachowanie

Code i RedirectUri są właściwościami OAuthCodeExchangeContext , które można ustawić za pomocą konstruktora OAuthCodeExchangeContext . Nowy OAuthCodeExchangeContext typ jest jedynym argumentem przekazanym do OAuthHandler.ExchangeCodeAsyncelementu .

Przyczyna wprowadzenia zmiany

Ta zmiana umożliwia wprowadzenie dodatkowych parametrów w sposób niełamiący. Nie ma potrzeby tworzenia nowych ExchangeCodeAsync przeciążeń.

Skonstruuj element OAuthCodeExchangeContext z odpowiednimi code wartościami i redirectUri . Należy AuthenticationProperties podać wystąpienie. To pojedyncze OAuthCodeExchangeContext wystąpienie można przekazać OAuthHandler.ExchangeCodeAsync zamiast wielu argumentów.

Kategoria

ASP.NET Core

Dotyczy interfejsów API

OAuthHandler<TOptions>.ExchangeCodeAsync(String, String)

Autoryzacja: przeciążenie addAuthorization przeniesione do innego zestawu

Nazwy podstawowych AddAuthorization metod używanych do pobytu w obiekcie Microsoft.AspNetCore.Authorization zostały zmienione na AddAuthorizationCore. Stare AddAuthorization metody nadal istnieją, ale zamiast tego Microsoft.AspNetCore.Authorization.Policy znajdują się w zestawie. Aplikacje korzystające z obu metod nie powinny mieć wpływu. Należy pamiętać, że Microsoft.AspNetCore.Authorization.Policy teraz są dostarczane w strukturze udostępnionej zamiast autonomicznego pakietu zgodnie z opisem w temacie Shared Framework: Assemblies removed from Microsoft.AspNetCore.App (Zestawy usunięte z Microsoft.AspNetCore.App).

Wprowadzona wersja

3.0

Stare zachowanie

AddAuthorization metody istniały w systemie Microsoft.AspNetCore.Authorization.

Nowe zachowanie

AddAuthorization metody istnieją w systemie Microsoft.AspNetCore.Authorization.Policy. AddAuthorizationCore to nowa nazwa starych metod.

Przyczyna wprowadzenia zmiany

AddAuthorization to lepsza nazwa metody dodawania wszystkich typowych usług potrzebnych do autoryzacji.

Dodaj odwołanie do Microsoft.AspNetCore.Authorization.Policy lub użyj zamiast tego AddAuthorizationCore .

Kategoria

ASP.NET Core

Dotyczy interfejsów API

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

Autoryzacja: IAllowAnonymous usunięte z authorizationFilterContext.Filters

Od ASP.NET Core 3.0 mvC nie dodaje atrybutów AllowAnonymousFilters dla atrybutów [AllowAnonymous], które zostały odnalezione na kontrolerach i metodach akcji. Ta zmiana jest usuwana lokalnie dla pochodnych elementu AuthorizeAttribute, ale jest to zmiana powodująca niezgodność dla IAsyncAuthorizationFilter implementacji i IAuthorizationFilter . Takie implementacje opakowane w atrybut [TypeFilter] są popularnym i obsługiwanym sposobem osiągnięcia silnie typizowanej autoryzacji opartej na atrybutach, gdy wymagana jest zarówno konfiguracja, jak i wstrzykiwanie zależności.

Wprowadzona wersja

3.0

Stare zachowanie

IAllowAnonymous pojawi się w kolekcji AuthorizationFilterContext.Filters . Testowanie obecności interfejsu było prawidłowym podejściem do zastąpienia lub wyłączenia filtru dla poszczególnych metod kontrolera.

Nowe zachowanie

IAllowAnonymous w kolekcji nie jest już wyświetlana AuthorizationFilterContext.Filters . IAsyncAuthorizationFilter implementacje zależne od starego zachowania zwykle powodują sporadyczne odpowiedzi HTTP 401 Brak autoryzacji lub HTTP 403 Zabronione odpowiedzi.

Przyczyna wprowadzenia zmiany

Wprowadzono nową strategię routingu punktów końcowych w ASP.NET Core 3.0.

Przeszukaj metadane punktu końcowego pod kątem IAllowAnonymous. Na przykład:

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

Przykład tej techniki jest widoczny w tej metodzie HasAllowAnonymous.

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Brak

Autoryzacja: implementacje IAuthorizationPolicyProvider wymagają nowej metody

W ASP.NET Core 3.0 dodano nową GetFallbackPolicyAsync metodę do IAuthorizationPolicyProvidermetody . Te zasady rezerwowe są używane przez oprogramowanie pośredniczące autoryzacji, gdy nie określono żadnych zasad.

Aby uzyskać więcej informacji, zobacz dotnet/aspnetcore#9759.

Wprowadzona wersja

3.0

Stare zachowanie

Implementacje metody nie wymagały IAuthorizationPolicyProviderGetFallbackPolicyAsync metody.

Nowe zachowanie

Implementacje IAuthorizationPolicyProvider metody wymagają GetFallbackPolicyAsync metody.

Przyczyna wprowadzenia zmiany

Do użycia AuthorizationMiddleware nowej metody potrzebna była nowa metoda, gdy nie określono żadnych zasad.

Dodaj metodę GetFallbackPolicyAsync do implementacji elementu IAuthorizationPolicyProvider.

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Microsoft.AspNetCore.Authorization.IAuthorizationPolicyProvider

Buforowanie: właściwość CompactOnMemoryPressure została usunięta

Wersja ASP.NET Core 3.0 usunęła przestarzałe interfejsy API MemoryCacheOptions.

Opis zmiany

Ta zmiana jest kontynuacją pliku aspnet/Buforowanie#221. Aby zapoznać się z dyskusją, zobacz dotnet/extensions#1062.

Wprowadzona wersja

3.0

Stare zachowanie

MemoryCacheOptions.CompactOnMemoryPressure właściwość była dostępna.

Nowe zachowanie

Właściwość została usunięta MemoryCacheOptions.CompactOnMemoryPressure .

Przyczyna wprowadzenia zmiany

Automatyczne kompaktowanie pamięci podręcznej spowodowało problemy. Aby uniknąć nieoczekiwanego zachowania, pamięć podręczna powinna być kompaktowana tylko w razie potrzeby.

Aby skompaktować pamięć podręczną, zmieść pamięć podręczną i wywołać MemoryCache je Compact w razie potrzeby.

Kategoria

ASP.NET Core

Dotyczy interfejsów API

MemoryCacheOptions.CompactOnMemoryPressure

Buforowanie: Microsoft.Extensions. Buforowanie. SqlServer używa nowego pakietu SqlClient

Pakiet Microsoft.Extensions.Caching.SqlServer będzie używać nowego Microsoft.Data.SqlClient pakietu zamiast System.Data.SqlClient pakietu. Ta zmiana może spowodować niewielkie zmiany powodujące niezgodność behawioralną. Aby uzyskać więcej informacji, zobacz Wprowadzenie do nowego obiektu Microsoft.Data.SqlClient.

Wprowadzona wersja

3.0

Stare zachowanie

Pakiet Microsoft.Extensions.Caching.SqlServer użył System.Data.SqlClient pakietu.

Nowe zachowanie

Microsoft.Extensions.Caching.SqlServer program korzysta teraz z Microsoft.Data.SqlClient pakietu.

Przyczyna wprowadzenia zmiany

Microsoft.Data.SqlClient to nowy pakiet, który został skompilowany z klasy System.Data.SqlClient. W tym miejscu wszystkie nowe funkcje będą wykonywane od teraz.

Klienci nie powinni martwić się o tę zmianę powodującą Microsoft.Extensions.Caching.SqlServer niezgodność, chyba że używają typów zwracanych przez pakiet i rzutowania ich do System.Data.SqlClient typów. Jeśli na przykład ktoś rzutował element DbConnection na stary typ sql Połączenie ion, musiałby zmienić rzutowanie na nowy Microsoft.Data.SqlClient.SqlConnectiontyp.

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Brak

Buforowanie: Typy odpowiedzi Buforowanie "pubternal" zmieniły się na wewnętrzne

W systemie ASP.NET Core 3.0 typy "pubternal" zostały ResponseCaching zmienione na internal.

Ponadto domyślne implementacje IResponseCachingPolicyProvider i IResponseCachingKeyProvider nie są już dodawane do usług w ramach AddResponseCaching metody .

Opis zmiany

W ASP.NET Core typy "pubternal" są deklarowane jako public , ale znajdują się w sufiksie przestrzeni nazw z .Internal. Chociaż te typy są publiczne, nie mają żadnych zasad pomocy technicznej i podlegają zmianom powodujących niezgodność. Niestety przypadkowe użycie tych typów było powszechne, co spowodowało niezgodność zmian w tych projektach i ograniczenie możliwości utrzymania struktury.

Wprowadzona wersja

3.0

Stare zachowanie

Te typy były widoczne publicznie, ale nieobsługiwane.

Nowe zachowanie

Te typy są teraz internal.

Przyczyna wprowadzenia zmiany

Zakres internal lepiej odzwierciedla nieobsługiwane zasady.

Kopiowanie typów używanych przez aplikację lub bibliotekę.

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Ochrona danych: Usługa DataProtection.Blobs używa nowych interfejsów API usługi Azure Storage

Azure.Extensions.AspNetCore.DataProtection.Blobs zależy od bibliotek usługi Azure Storage. Te biblioteki zmieniły nazwy zestawów, pakietów i przestrzeni nazw. Począwszy od ASP.NET Core 3.0, Azure.Extensions.AspNetCore.DataProtection.Blobs używa nowych Azure.Storage.-prefiksowanych interfejsów API i pakietów.

W przypadku pytań dotyczących interfejsów API usługi Azure Storage użyj polecenia https://github.com/Azure/azure-storage-net. Aby omówić ten problem, zobacz dotnet/aspnetcore#19570.

Wprowadzona wersja

3.0

Stare zachowanie

Pakiet odwołuje się do WindowsAzure.Storage pakietu NuGet. Pakiet odwołuje się do Microsoft.Azure.Storage.Blob pakietu NuGet.

Nowe zachowanie

Pakiet odwołuje się do Azure.Storage.Blob pakietu NuGet.

Przyczyna wprowadzenia zmiany

Ta zmiana umożliwia Azure.Extensions.AspNetCore.DataProtection.Blobs migrację do zalecanych pakietów usługi Azure Storage.

Jeśli nadal musisz używać starszych interfejsów API usługi Azure Storage z programem ASP.NET Core 3.0, dodaj bezpośrednią zależność do pakietu WindowsAzure.Storage lub Microsoft.Azure.Storage. Ten pakiet można zainstalować wraz z nowymi Azure.Storage interfejsami API.

W wielu przypadkach uaktualnienie obejmuje tylko zmianę using instrukcji tak, aby korzystały z nowych przestrzeni nazw:

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

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Brak

Hosting: AspNetCoreModule V1 usunięto z pakietu hostingu systemu Windows

Począwszy od wersji ASP.NET Core 3.0, pakiet hostingu systemu Windows nie będzie zawierać modułu AspNetCoreModule (ANCM) w wersji 1.

PROGRAM ANCM V2 jest do tyłu zgodny z anCM OutOfProcess i jest zalecany do użycia z aplikacjami ASP.NET Core 3.0.

Aby zapoznać się z dyskusją, zobacz dotnet/aspnetcore#7095.

Wprowadzona wersja

3.0

Stare zachowanie

Program ANCM V1 jest dołączony do pakietu hostingu systemu Windows.

Nowe zachowanie

Program ANCM V1 nie jest uwzględniony w pakiecie hostingu systemu Windows.

Przyczyna wprowadzenia zmiany

PROGRAM ANCM V2 jest do tyłu zgodny z anCM OutOfProcess i jest zalecany do użycia z aplikacjami ASP.NET Core 3.0.

Użyj narzędzia ANCM V2 z aplikacjami ASP.NET Core 3.0.

Jeśli program ANCM V1 jest wymagany, można go zainstalować przy użyciu pakietu hostingu systemu Windows ASP.NET Core 2.1 lub 2.2.

Ta zmiana spowoduje przerwanie ASP.NET aplikacji Core 3.0, które:

  • Jawnie zrezygnowano z używania programu ANCM V1 z <AspNetCoreModuleName>AspNetCoreModule</AspNetCoreModuleName>programem .
  • Mieć niestandardowy plik web.config z .<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Brak

Hosting: host ogólny ogranicza wstrzykiwanie konstruktora startowego

Jedynymi typami host ogólny obsługuje Startup iniekcję konstruktora klasy to IHostEnvironment, IWebHostEnvironmenti IConfiguration. Nie ma to wpływu na aplikacje korzystające z usługi WebHost .

Opis zmiany

Przed ASP.NET Core 3.0 można użyć iniekcji konstruktora do dowolnych typów w Startup konstruktorze klasy. W ASP.NET Core 3.0 stos internetowy został ponownie splatformowany z ogólną biblioteką hostów. Możesz zobaczyć zmianę w pliku Program.cs szablonów:

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 używa jednego kontenera wstrzykiwania zależności (DI) do skompilowania aplikacji. WebHost używa dwóch kontenerów: jeden dla hosta i jeden dla aplikacji. W rezultacie Startup konstruktor nie obsługuje już iniekcji usługi niestandardowej. Tylko IHostEnvironment, IWebHostEnvironmenti IConfiguration można wstrzykiwać. Ta zmiana uniemożliwia problemy z di, takie jak zduplikowane tworzenie pojedynczej usługi.

Wprowadzona wersja

3.0

Przyczyna wprowadzenia zmiany

Ta zmiana jest konsekwencją ponownego odtworzenia stosu internetowego w ogólnej bibliotece hostów.

Wstrzykiwanie usług do Startup.Configure podpisu metody. Na przykład:

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

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Brak

Hosting: przekierowanie HTTPS włączone dla aplikacji pozaprocesowych usług IIS

Wersja 13.0.19218.0 modułu ASP.NET Core Module (ANCM) do hostowania za pośrednictwem usług IIS poza procesem umożliwia korzystanie z istniejącej funkcji przekierowywania HTTPS dla aplikacji ASP.NET Core 3.0 i 2.2.

Aby zapoznać się z dyskusją, zobacz dotnet/AspNetCore#15243.

Wprowadzona wersja

3.0

Stare zachowanie

Szablon projektu ASP.NET Core 2.1 po raz pierwszy wprowadził obsługę metod oprogramowania pośredniczącego HTTPS, takich jak UseHttpsRedirection i UseHsts. Włączenie przekierowania HTTPS wymaga dodania konfiguracji, ponieważ aplikacje w programowania nie używają domyślnego portu 443. Protokół HTTP Strict Transport Security (HSTS) jest aktywny tylko wtedy, gdy żądanie korzysta już z protokołu HTTPS. Host lokalny jest domyślnie pomijany.

Nowe zachowanie

W ASP.NET Core 3.0 ulepszono scenariusz PROTOKOŁU HTTPS usług IIS. Dzięki ulepszeniu aplikacja może odnaleźć porty HTTPS serwera i domyślnie UseHttpsRedirection pracować. Składnik przetwarzania wykonał odnajdywanie portów za IServerAddresses pomocą funkcji, która ma wpływ tylko na aplikacje ASP.NET Core 3.0, ponieważ biblioteka procesów jest wersjonowana z platformą. Składnik poza procesem został zmieniony, aby automatycznie dodać zmienną ASPNETCORE_HTTPS_PORT środowiskową. Ta zmiana dotyczy zarówno aplikacji ASP.NET Core 2.2, jak i 3.0, ponieważ składnik poza procesem jest współużytkowany globalnie. ASP.NET aplikacje core 2.1 nie mają wpływu, ponieważ domyślnie używają wcześniejszej wersji programu ANCM.

Poprzednie zachowanie zostało zmodyfikowane w programie ASP.NET Core 3.0.1 i 3.1.0 (wersja zapoznawcza 3), aby odwrócić zmiany zachowania w programie ASP.NET Core 2.x. Te zmiany mają wpływ tylko na aplikacje pozaprocesowe usług IIS.

Jak opisano powyżej, instalowanie ASP.NET Core 3.0.0 miało również efekt uboczny aktywowania oprogramowania pośredniczącego UseHttpsRedirection w aplikacjach ASP.NET Core 2.x. Wprowadzono zmianę w usłudze ANCM w ASP.NET Core 3.0.1 i 3.1.0 (wersja zapoznawcza 3), tak aby instalowanie ich nie miało już wpływu na aplikacje ASP.NET Core 2.x. Zmienna ASPNETCORE_HTTPS_PORT środowiskowa wypełniona w programie ASP.NET Core 3.0.0 została zmieniona na ASPNETCORE_ANCM_HTTPS_PORT w ASP.NET Core 3.0.1 i 3.1.0 (wersja zapoznawcza 3). UseHttpsRedirection aktualizacja została również zaktualizowana w tych wersjach, aby zrozumieć zarówno nowe, jak i stare zmienne. ASP.NET Core 2.x nie zostanie zaktualizowany. W związku z tym przywraca ono poprzednie zachowanie, które jest domyślnie wyłączone.

Przyczyna wprowadzenia zmiany

Ulepszona funkcja ASP.NET Core 3.0.

Nie jest wymagana żadna akcja, jeśli chcesz, aby wszyscy klienci używali protokołu HTTPS. Aby zezwolić niektórym klientom na korzystanie z protokołu HTTP, wykonaj jedną z następujących czynności:

  • Usuń wywołania metody UseHttpsRedirection i UseHsts z metody projektu Startup.Configure i ponownie wdróż aplikację.

  • W pliku web.config ustaw ASPNETCORE_HTTPS_PORT zmienną środowiskową na pusty ciąg. Ta zmiana może wystąpić bezpośrednio na serwerze bez ponownego wdrażania aplikacji. Na przykład:

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

UseHttpsRedirection nadal może być:

  • Aktywowane ręcznie w ASP.NET Core 2.x przez ustawienie ASPNETCORE_HTTPS_PORT zmiennej środowiskowej na odpowiedni numer portu (443 w większości scenariuszy produkcyjnych).
  • Dezaktywowany w ASP.NET Core 3.x przez zdefiniowanie ASPNETCORE_ANCM_HTTPS_PORT z pustą wartością ciągu. Ta wartość jest ustawiana w taki sam sposób, jak w poprzednim przykładzie ASPNETCORE_HTTPS_PORT .

Maszyny z aplikacjami ASP.NET Core 3.0.0 powinny zainstalować środowisko uruchomieniowe ASP.NET Core 3.0.1 przed zainstalowaniem ASP.NET Core 3.1.0 Preview 3 ANCM. Zapewnia to, że UseHttpsRedirection nadal działa zgodnie z oczekiwaniami dla aplikacji platformy ASP.NET Core 3.0.

W usłudze aplikacja systemu Azure usługa ANCM jest wdrażana zgodnie z oddzielnym harmonogramem od środowiska uruchomieniowego ze względu na jej globalny charakter. Narzędzie ANCM zostało wdrożone na platformie Azure przy użyciu tych zmian po wdrożeniu ASP.NET Core 3.0.1 i 3.1.0.

Kategoria

ASP.NET Core

Dotyczy interfejsów API

HttpsPolicyBuilderExtensions.UseHttpsRedirection(IApplicationBuilder)

Hosting: typy IHostingEnvironment i IApplicationLifetime oznaczone jako przestarzałe i zastąpione

Wprowadzono nowe typy, aby zastąpić istniejące IHostingEnvironment i IApplicationLifetime typy.

Wprowadzona wersja

3.0

Stare zachowanie

Istnieją dwa różne IHostingEnvironment typy i IApplicationLifetime od Microsoft.Extensions.Hosting i Microsoft.AspNetCore.Hosting.

Nowe zachowanie

Stare typy zostały oznaczone jako przestarzałe i zastąpione nowymi typami.

Przyczyna wprowadzenia zmiany

Kiedy Microsoft.Extensions.Hosting wprowadzono w ASP.NET Core 2.1, niektóre typy, takie jak IHostingEnvironment i IApplicationLifetime zostały skopiowane z Microsoft.AspNetCore.Hostingprogramu . Niektóre zmiany ASP.NET Core 3.0 powodują, że aplikacje będą zawierać zarówno przestrzenie nazw, jak Microsoft.Extensions.Hosting i Microsoft.AspNetCore.Hosting . Każde użycie tych zduplikowanych typów powoduje błąd kompilatora "niejednoznaczne", gdy odwołują się do obu przestrzeni nazw.

Zastąpiono wszystkie użycia starych typów nowo wprowadzonymi typami, jak pokazano poniżej:

Przestarzałe typy (ostrzeżenie):

Nowe typy:

Nowe IHostEnvironmentIsDevelopment metody i IsProduction rozszerzenia znajdują się w Microsoft.Extensions.Hosting przestrzeni nazw. Może być konieczne dodanie tej przestrzeni nazw do projektu.

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Hosting: Obiekt ObjectPoolProvider został usunięty z zależności WebHostBuilder

W ramach dokonywania ASP.NET Core większej opłaty za grę, ObjectPoolProvider został usunięty z głównego zestawu zależności. Określone składniki, na ObjectPoolProvider których polegają teraz, dodają je samodzielnie.

Aby zapoznać się z dyskusją, zobacz dotnet/aspnetcore#5944.

Wprowadzona wersja

3.0

Stare zachowanie

WebHostBuilder domyślnie w ObjectPoolProvider kontenerze DI.

Nowe zachowanie

WebHostBuilder Kontener DI nie jest już domyślnie dostępny ObjectPoolProvider .

Przyczyna wprowadzenia zmiany

Ta zmiana została wprowadzona, aby ASP.NET Core płacić za grę.

Jeśli składnik wymaga ObjectPoolProviderpolecenia , należy go dodać do zależności za pośrednictwem elementu IServiceCollection.

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Brak

HTTP: Usunięto rozszerzalność DefaultHttpContext

W ramach ulepszeń wydajności ASP.NET Core 3.0 rozszerzalność została usunięta DefaultHttpContext . Klasa to teraz sealed. Aby uzyskać więcej informacji, zobacz dotnet/aspnetcore#6504.

Jeśli testy jednostkowe używają polecenia Mock<DefaultHttpContext>, użyj polecenia Mock<HttpContext> lub new DefaultHttpContext() zamiast tego.

Aby zapoznać się z dyskusją, zobacz dotnet/aspnetcore#6534.

Wprowadzona wersja

3.0

Stare zachowanie

Klasy mogą pochodzić z klasy DefaultHttpContext.

Nowe zachowanie

Klasy nie mogą pochodzić z klasy DefaultHttpContext.

Przyczyna wprowadzenia zmiany

Rozszerzalność została udostępniona początkowo w celu umożliwienia HttpContexttworzenia puli elementów , ale wprowadziła niepotrzebną złożoność i utrudniała inne optymalizacje.

Jeśli używasz Mock<DefaultHttpContext> w testach jednostkowych, zacznij używać zamiast tego Mock<HttpContext> .

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Microsoft.AspNetCore.Http.DefaultHttpContext

HTTP: stałe HeaderNames zmieniły się na statyczne tylko do odczytu

Począwszy od ASP.NET Core 3.0 (wersja zapoznawcza 5), pola w Microsoft.Net.Http.Headers.HeaderNames systemie zmieniły się z const na static readonly.

Aby zapoznać się z dyskusją, zobacz dotnet/aspnetcore#9514.

Wprowadzona wersja

3.0

Stare zachowanie

Te pola były używane jako const.

Nowe zachowanie

Te pola są teraz static readonly.

Przyczyna wprowadzenia zmiany

Zmiana:

  • Zapobiega osadzaniu wartości w granicach zestawów, co pozwala na korektę wartości zgodnie z potrzebami.
  • Umożliwia szybsze sprawdzanie równości odwołań.

Przekompiluj ponownie w stosunku do wersji 3.0. Kod źródłowy korzystający z tych pól w następujący sposób nie może już tego zrobić:

  • Jako argument atrybutu
  • case Jako instrukcja w instrukcji switch
  • Podczas definiowania innego const

Aby obejść zmianę powodującą niezgodność, przejdź do używania stałych nazwy nagłówka zdefiniowanego samodzielnie lub literałów ciągu.

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Microsoft.Net.Http.Headers.HeaderNames

HTTP: Zmiany infrastruktury treści odpowiedzi

Infrastruktury obsługującej treść odpowiedzi HTTP uległa zmianie. Jeśli używasz HttpResponse bezpośrednio, nie musisz wprowadzać żadnych zmian w kodzie. Przeczytaj dalej, jeśli opakowujesz lub zamieniasz HttpResponse.Body lub uzyskujesz dostęp do HttpContext.Featureselementu .

Wprowadzona wersja

3.0

Stare zachowanie

Wystąpiły trzy interfejsy API skojarzone z treścią odpowiedzi HTTP:

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

Nowe zachowanie

Jeśli zastąpisz HttpResponse.Bodyelement , zastąpi cały IHttpResponseBodyFeature element otoką wokół danego strumienia przy użyciu polecenia StreamResponseBodyFeature , aby zapewnić domyślne implementacje dla wszystkich oczekiwanych interfejsów API. Przywrócenie oryginalnego strumienia spowoduje przywrócenie tej zmiany.

Przyczyna wprowadzenia zmiany

Motywacją jest połączenie interfejsów API treści odpowiedzi w jeden nowy interfejs funkcji.

Użyj IHttpResponseBodyFeature miejsca, w którym wcześniej używano elementu IHttpResponseFeature.Body, IHttpSendFileFeaturelub IHttpBufferingFeature.

Kategoria

ASP.NET Core

Dotyczy interfejsów API

SameSite jest opcją plików cookie, które mogą pomóc w ograniczeniu niektórych ataków fałszerzujących żądania między witrynami (CSRF). Kiedy ta opcja została początkowo wprowadzona, niespójne wartości domyślne były używane w różnych interfejsach API platformy ASP.NET Core. Niespójność doprowadziła do mylących wyników. Od wersji ASP.NET Core 3.0 te wartości domyślne są lepiej dopasowane. Musisz wyrazić zgodę na tę funkcję dla poszczególnych składników.

Wprowadzona wersja

3.0

Stare zachowanie

Podobne ASP.NET Podstawowe interfejsy API używały różnych wartości domyślnych SameSiteMode . Przykład niespójności jest widoczny w HttpResponse.Cookies.Append(String, String) elementy i HttpResponse.Cookies.Append(String, String, CookieOptions), które są domyślnie ustawione na SameSiteMode.None i SameSiteMode.Lax, odpowiednio.

Nowe zachowanie

Wszystkie interfejsy API, których dotyczy problem, domyślnie mają wartość SameSiteMode.None.

Przyczyna wprowadzenia zmiany

Wartość domyślna została zmieniona, aby włączyć SameSite funkcję zgody.

Każdy składnik emitujący pliki cookie musi zdecydować, czy SameSite jest odpowiedni dla jego scenariuszy. Przejrzyj użycie interfejsów API, których dotyczy problem, i skonfiguruj je SameSite ponownie w razie potrzeby.

Kategoria

ASP.NET Core

Dotyczy interfejsów API

HTTP: Synchroniczne operacje we/wy wyłączone na wszystkich serwerach

Począwszy od ASP.NET Core 3.0, operacje synchroniczne serwera są domyślnie wyłączone.

Opis zmiany

AllowSynchronousIO to opcja na każdym serwerze, która włącza lub wyłącza synchroniczne interfejsy API we/wy, takie jak HttpRequest.Body.Read, HttpResponse.Body.Writei Stream.Flush. Te interfejsy API od dawna są źródłem głodu wątku i zawiesza się aplikacja. Począwszy od wersji ASP.NET Core 3.0 (wersja zapoznawcza 3), te operacje synchroniczne są domyślnie wyłączone.

Serwery, których dotyczy problem:

  • Kestrel
  • HttpSys
  • Usługi IIS w procesie
  • Testserver

Oczekiwano błędów podobnych do:

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

Każdy serwer ma AllowSynchronousIO opcję, która kontroluje to zachowanie, a ustawienie domyślne dla wszystkich z nich to teraz false.

Zachowanie można również zastąpić na podstawie poszczególnych żądań jako tymczasowe ograniczenie ryzyka. Na przykład:

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

Jeśli masz problemy z wywołaniem TextWriter synchronicznego interfejsu API lub innego strumienia w Disposeprogramie , wywołaj nowy DisposeAsync interfejs API.

Aby zapoznać się z dyskusją, zobacz dotnet/aspnetcore#7644.

Wprowadzona wersja

3.0

Stare zachowanie

HttpRequest.Body.Read, HttpResponse.Body.Writei Stream.Flush były domyślnie dozwolone.

Nowe zachowanie

Te synchroniczne interfejsy API są domyślnie niedozwolone:

Oczekiwano błędów podobnych do:

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

Przyczyna wprowadzenia zmiany

Te synchroniczne interfejsy API od dawna są źródłem głodu wątku i zawiesza się aplikacja. Począwszy od wersji ASP.NET Core 3.0 (wersja zapoznawcza 3), operacje synchroniczne są domyślnie wyłączone.

Użyj asynchronicznych wersji metod. Zachowanie można również zastąpić na podstawie poszczególnych żądań jako tymczasowe ograniczenie ryzyka.

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

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Tożsamość: usunięto przeciążenie metody AddDefaultUI

Począwszy od ASP.NET Core 3.0, przeciążenie metody IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework) już nie istnieje.

Wprowadzona wersja

3.0

Przyczyna wprowadzenia zmiany

Ta zmiana była wynikiem wdrożenia funkcji statycznych zasobów internetowych.

Wywołanie IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder) zamiast przeciążenia, które przyjmuje dwa argumenty. Jeśli używasz programu Bootstrap 3, dodaj również następujący wiersz do <PropertyGroup> elementu w pliku projektu:

<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>

Kategoria

ASP.NET Core

Dotyczy interfejsów API

IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework)

Tożsamość: zmieniono domyślną wersję interfejsu użytkownika bootstrap

Począwszy od ASP.NET Core 3.0, interfejs użytkownika tożsamości domyślnie używa wersji 4 bootstrap.

Wprowadzona wersja

3.0

Stare zachowanie

Wywołanie services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(); metody było takie samo jak services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap3);

Nowe zachowanie

Wywołanie services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(); metody jest takie samo jak services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap4);

Przyczyna wprowadzenia zmiany

Bootstrap 4 został wydany w czasie ASP.NET Core 3.0.

Wpływ na tę zmianę ma zastosowanie w przypadku używania domyślnego interfejsu użytkownika tożsamości i dodania go w Startup.ConfigureServices sposób pokazany w poniższym przykładzie:

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

Przeprowadź jedną z następujących czynności:

  • Przeprowadź migrację aplikacji, aby użyć narzędzia Bootstrap 4, korzystając z przewodnika po migracji.

  • Aktualizacja Startup.ConfigureServices w celu wymuszenia użycia bootstrap 3. Na przykład:

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

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Brak

Tożsamość: narzędzie SignInAsync zgłasza wyjątek dla nieuwierzytelnionej tożsamości

Domyślnie SignInAsync zgłasza wyjątek dla podmiotów zabezpieczeń/tożsamości, w których IsAuthenticated jest .false

Wprowadzona wersja

3.0

Stare zachowanie

SignInAsyncakceptuje wszystkie podmioty zabezpieczeń/tożsamości, w tym tożsamości, w których IsAuthenticated jest .false

Nowe zachowanie

Domyślnie SignInAsync zgłasza wyjątek dla podmiotów zabezpieczeń/tożsamości, w których IsAuthenticated jest .false Istnieje nowa flaga, która pozwala pominąć to zachowanie, ale zachowanie domyślne uległo zmianie.

Przyczyna wprowadzenia zmiany

Stare zachowanie było problematyczne, ponieważ domyślnie te podmioty zabezpieczeń zostały odrzucone przez [Authorize] / RequireAuthenticatedUser().

W programie ASP.NET Core 3.0 (wersja zapoznawcza 6) jest domyślnie flaga RequireAuthenticatedSignInAuthenticationOptionstrue . Ustaw tę flagę, aby false przywrócić stare zachowanie.

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Brak

Tożsamość: Konstruktor SignInManager akceptuje nowy parametr

Począwszy od ASP.NET Core 3.0, do konstruktora SignInManager został dodany nowy IUserConfirmation<TUser> parametr. Aby uzyskać więcej informacji, zobacz dotnet/aspnetcore#8356.

Wprowadzona wersja

3.0

Przyczyna wprowadzenia zmiany

Motywacją zmiany było dodanie obsługi nowych przepływów wiadomości e-mail /potwierdzenia w tożsamości.

Jeśli ręcznie skonstruuje element , podaj implementację SignInManagerIUserConfirmation lub pobierz jedną z iniekcji zależności, aby zapewnić.

Kategoria

ASP.NET Core

Dotyczy interfejsów API

SignInManager<TUser>

Tożsamość: interfejs użytkownika używa funkcji statycznych zasobów internetowych

ASP.NET Core 3.0 wprowadziła funkcję statycznych zasobów internetowych, a interfejs użytkownika tożsamości go przyjął.

Opis zmiany

W wyniku interfejsu użytkownika tożsamości przyjmującej funkcję statycznych zasobów internetowych:

  • Wybór struktury odbywa się przy użyciu IdentityUIFrameworkVersion właściwości w pliku projektu.
  • Bootstrap 4 to domyślna struktura interfejsu użytkownika dla interfejsu użytkownika tożsamości. Bootstrap 3 osiągnął koniec życia i należy rozważyć migrację do obsługiwanej wersji.

Wprowadzona wersja

3.0

Stare zachowanie

Domyślna struktura interfejsu użytkownika dla interfejsu użytkownika tożsamości to Bootstrap 3. Strukturę interfejsu użytkownika można skonfigurować przy użyciu parametru AddDefaultUI do wywołania metody w pliku Startup.ConfigureServices.

Nowe zachowanie

Domyślna struktura interfejsu użytkownika dla interfejsu użytkownika tożsamości to Bootstrap 4. Struktura interfejsu użytkownika musi być skonfigurowana w pliku projektu, a nie w wywołaniu AddDefaultUI metody.

Przyczyna wprowadzenia zmiany

Wdrożenie funkcji statycznych zasobów internetowych wymaga, aby konfiguracja platformy interfejsu użytkownika została przeniesiona do programu MSBuild. Decyzja o tym, która struktura do osadzenia jest decyzją w czasie kompilacji, a nie decyzją środowiska uruchomieniowego.

Przejrzyj interfejs użytkownika witryny, aby upewnić się, że nowe składniki bootstrap 4 są zgodne. W razie potrzeby użyj IdentityUIFrameworkVersion właściwości MSBuild, aby przywrócić element Bootstrap 3. Dodaj właściwość do <PropertyGroup> elementu w pliku projektu:

<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>

Kategoria

ASP.NET Core

Dotyczy interfejsów API

IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder, UIFramework)

Kestrel: usunięte karty Połączenie ion

W ramach przejścia do przenoszenia interfejsów API "pubternal" do public, koncepcja elementu IConnectionAdapter została usunięta z usługi Kestrel. Karty Połączenie ion są zastępowane oprogramowaniem pośredniczącym połączeń (podobnie jak oprogramowanie pośredniczące HTTP w potoku ASP.NET Core, ale w przypadku połączeń niższego poziomu). Rejestrowanie https i połączeń zostało przeniesione z kart połączenia do oprogramowania pośredniczącego połączeń. Te metody rozszerzenia powinny nadal działać bezproblemowo, ale szczegóły implementacji uległy zmianie.

Aby uzyskać więcej informacji, zobacz dotnet/aspnetcore#11412. Aby zapoznać się z dyskusją, zobacz dotnet/aspnetcore#11475.

Wprowadzona wersja

3.0

Stare zachowanie

Składniki rozszerzalności Kestrel zostały utworzone przy użyciu polecenia IConnectionAdapter.

Nowe zachowanie

Składniki rozszerzalności Kestrel są tworzone jako oprogramowanie pośredniczące.

Przyczyna wprowadzenia zmiany

Ta zmiana ma na celu zapewnienie bardziej elastycznej architektury rozszerzalności.

Przekonwertuj wszystkie implementacje programu IConnectionAdapter , aby użyć nowego wzorca oprogramowania pośredniczącego, jak pokazano tutaj.

Kategoria

ASP.NET Core

Dotyczy interfejsów API

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

Kestrel: usunięty pusty zestaw HTTPS

Zestaw Microsoft.AspNetCore.Server.Kestrel.Https został usunięty.

Wprowadzona wersja

3.0

Przyczyna wprowadzenia zmiany

W ASP.NET Core 2.1 zawartość elementu została przeniesiona Microsoft.AspNetCore.Server.Kestrel.Https do Microsoft.AspNetCore.Server.Kestrel.Core. Ta zmiana została wykonana w sposób niełamiący się przy użyciu [TypeForwardedTo] atrybutów.

  • Biblioteki odwołujące Microsoft.AspNetCore.Server.Kestrel.Https się do wersji 2.0 powinny zaktualizować wszystkie zależności ASP.NET Core do wersji 2.1 lub nowszej. W przeciwnym razie mogą one zostać przerwane podczas ładowania do aplikacji ASP.NET Core 3.0.
  • Aplikacje i biblioteki przeznaczone dla platformy ASP.NET Core 2.1 i nowszych powinny usuwać wszelkie bezpośrednie odwołania do Microsoft.AspNetCore.Server.Kestrel.Https pakietu NuGet.

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Brak

Kestrel: Żądanie nagłówków zwiastunów przeniesionych do nowej kolekcji

W poprzednich wersjach firma Kestrel dodała fragmenty nagłówków przyczepy HTTP/1.1 do kolekcji nagłówków żądań, gdy treść żądania została odczytowana na końcu. To zachowanie spowodowało obawy dotyczące niejednoznaczności między nagłówkami a przyczepami. Podjęto decyzję o przeniesieniu przyczep do nowej kolekcji.

Zwiastuny żądań HTTP/2 były niedostępne w ASP.NET Core 2.2, ale są teraz również dostępne w tej nowej kolekcji w ASP.NET Core 3.0.

Dodano nowe metody rozszerzenia żądania w celu uzyskania dostępu do tych przyczep.

Przyczepy HTTP/1.1 są dostępne po odczytaniu całej treści żądania.

Przyczepy HTTP/2 są dostępne po ich odebraniu od klienta. Klient nie będzie wysyłać przyczep, dopóki cała treść żądania nie zostanie co najmniej buforowana przez serwer. Może być konieczne odczytanie treści żądania, aby zwolnić miejsce buforu. Przyczepy są zawsze dostępne, jeśli przeczytasz treść żądania na końcu. Przyczepy oznaczają koniec ciała.

Wprowadzona wersja

3.0

Stare zachowanie

Do kolekcji zostaną dodane nagłówki zwiastuna HttpRequest.Headers żądania.

Nowe zachowanie

Nagłówki zwiastuna żądania nie są obecne w kolekcji HttpRequest.Headers . Aby uzyskać do nich dostęp, użyj następujących metod HttpRequest rozszerzenia:

  • GetDeclaredTrailers() - Pobiera nagłówek żądania "Trailer", który zawiera listę zwiastunów, których oczekuje się po treści.
  • SupportsTrailers() - Wskazuje, czy żądanie obsługuje odbieranie nagłówków przyczepy.
  • CheckTrailersAvailable() - Określa, czy żądanie obsługuje przyczepy i czy są dostępne do czytania.
  • GetTrailer(string trailerName) — Pobiera żądany nagłówek końcowy z odpowiedzi.

Przyczyna wprowadzenia zmiany

Przyczepy są kluczową funkcją w scenariuszach, takich jak gRPC. Scalanie przyczep w nagłówkach żądań było mylące dla użytkowników.

Użyj metod rozszerzenia związanych z przyczepą, HttpRequest aby uzyskać dostęp do przyczep.

Kategoria

ASP.NET Core

Dotyczy interfejsów API

HttpRequest.Headers

Kestrel: Abstrakcje transportu usunięte i upublicznione

W ramach odejścia od interfejsów API "pubternal" interfejsy API warstwy transportu Kestrel są udostępniane jako interfejs publiczny w Microsoft.AspNetCore.Connections.Abstractions bibliotece.

Wprowadzona wersja

3.0

Stare zachowanie

  • Abstrakcje związane z transportem były dostępne w bibliotece Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions .
  • Właściwość ListenOptions.NoDelay była dostępna.

Nowe zachowanie

  • Interfejs IConnectionListener został wprowadzony w Microsoft.AspNetCore.Connections.Abstractions bibliotece, aby uwidocznić najczęściej używane funkcje z ...Transport.Abstractions biblioteki.
  • Element NoDelay jest teraz dostępny w opcjach transportu (LibuvTransportOptions i SocketTransportOptions).
  • SchedulingMode program nie jest już dostępny.

Przyczyna wprowadzenia zmiany

ASP.NET Core 3.0 odeszła od interfejsów API "pubternal".

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Brak

Lokalizacja: ResourceManagerWithCultureStringLocalizer i WithCulture oznaczone jako przestarzałe

Klasa ResourceManagerWithCultureStringLocalizer i element członkowski interfejsu WithCulture są często źródłami nieporozumień dla użytkowników lokalizacji, zwłaszcza podczas tworzenia własnej IStringLocalizer implementacji. Te elementy dają użytkownikowi wrażenie, że IStringLocalizer wystąpienie to "na język, za zasób". W rzeczywistości wystąpienia powinny być tylko "na zasób". Wyszukiwany język jest określany przez CultureInfo.CurrentUICulture czas wykonywania. Aby wyeliminować źródło nieporozumień, interfejsy API zostały oznaczone jako przestarzałe w programie ASP.NET Core 3.0 (wersja zapoznawcza 3). Interfejsy API zostaną usunięte w przyszłej wersji.

Aby zapoznać się z kontekstem, zobacz dotnet/aspnetcore#3324. Aby zapoznać się z dyskusją, zobacz dotnet/aspnetcore#7756.

Wprowadzona wersja

3.0

Stare zachowanie

Metody nie zostały oznaczone jako Obsolete.

Nowe zachowanie

Metody są oznaczone jako Obsolete.

Przyczyna wprowadzenia zmiany

Interfejsy API reprezentowały przypadek użycia, który nie jest zalecany. Było zamieszanie dotyczące projektowania lokalizacji.

Zaleceniem jest użycie ResourceManagerStringLocalizer zamiast tego. Niech kultura zostanie ustawiona CurrentCultureprzez element . Jeśli nie jest to opcja, utwórz i użyj kopii elementu ResourceManagerWithCultureStringLocalizer.

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Rejestrowanie: klasa DebugLogger wykonana wewnętrznych

Przed ASP.NET Core 3.0 DebugLoggermodyfikator dostępu to public. W ASP.NET Core 3.0 modyfikator dostępu zmienił się na internal.

Wprowadzona wersja

3.0

Przyczyna wprowadzenia zmiany

Zmiana jest wprowadzana w następujących zmianami:

  • Wymuszaj spójność z innymi implementacjami rejestratora, takimi jak ConsoleLogger.
  • Zmniejsz powierzchnię interfejsu API.

AddDebugILoggingBuilder Użyj metody rozszerzenia, aby włączyć rejestrowanie debugowania. DebugLoggerProvider jest również nadal public w przypadku, gdy usługa musi zostać zarejestrowana ręcznie.

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Microsoft.Extensions.Logging.Debug.DebugLogger

MVC: sufiks asynchroniczny przycięty z nazw akcji kontrolera

W ramach adresowania dotnet/aspnetcore#4849 ASP.NET Core MVC domyślnie przycina sufiks Async z nazw akcji. Począwszy od ASP.NET Core 3.0, ta zmiana wpływa zarówno na routing, jak i generowanie linków.

Wprowadzona wersja

3.0

Stare zachowanie

Rozważ następujące ASP.NET podstawowego kontrolera MVC:

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

Akcja jest routingowa za pośrednictwem .Product/ListAsync Generowanie linków wymaga określenia sufiksu Async . Na przykład:

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

Nowe zachowanie

W ASP.NET Core 3.0 akcja jest routingowa za pośrednictwem .Product/List Kod generowania linku Async powinien pominąć sufiks. Na przykład:

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

Ta zmiana nie ma wpływu na nazwy określone przy użyciu atrybutu [ActionName] . Nowe zachowanie można wyłączyć, ustawiając wartość na w Startup.ConfigureServicespliku MvcOptions.SuppressAsyncSuffixInActionNamesfalse :

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

Przyczyna wprowadzenia zmiany

Zgodnie z konwencją Asyncmetody asynchroniczne platformy .NET mają sufiks . Jednak gdy metoda definiuje akcję MVC, nie jest pożądane użycie sufiksu Async .

Jeśli aplikacja zależy od akcji MVC zachowujących sufiks Async nazwy, wybierz jeden z następujących środków zaradczych:

  • Użyj atrybutu , [ActionName] aby zachować oryginalną nazwę.
  • Wyłącz zmianę nazwy całkowicie, ustawiając wartość na w pliku MvcOptions.SuppressAsyncSuffixInActionNamesfalse :Startup.ConfigureServices
services.AddMvc(options =>
{
   options.SuppressAsyncSuffixInActionNames = false;
});

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Brak

MVC: plik JsonResult został przeniesiony do pliku Microsoft.AspNetCore.Mvc.Core

JsonResult został przeniesiony Microsoft.AspNetCore.Mvc.Core do zestawu. Ten typ używany do definiowania w pliku Microsoft.AspNetCore.Mvc.Formatters.Json. Dodano atrybut na poziomie zestawu [TypeForwardedTo], aby rozwiązać Microsoft.AspNetCore.Mvc.Formatters.Json ten problem dla większości użytkowników. Aplikacje korzystające z bibliotek innych firm mogą napotkać problemy.

Wprowadzona wersja

3.0 (wersja zapoznawcza 6)

Stare zachowanie

Aplikacja korzystająca z biblioteki opartej na wersji 2.2 została pomyślnie skompilowanych.

Nowe zachowanie

Kompilacja aplikacji korzystającej z biblioteki opartej na wersji 2.2 kończy się niepowodzeniem. Podano błąd zawierający odmianę następującego tekstu:

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'

Aby zapoznać się z przykładem takiego problemu, zobacz dotnet/aspnetcore#7220.

Przyczyna wprowadzenia zmiany

Zmiany na poziomie platformy w kompozycji ASP.NET Core zgodnie z opisem na stronie aspnet/Announcements#325.

Biblioteki skompilowane w wersji 2.2 programu mogą wymagać ponownego Microsoft.AspNetCore.Mvc.Formatters.Json skompilowania, aby rozwiązać problem dla wszystkich użytkowników. W razie problemu skontaktuj się z autorem biblioteki. Zażądaj ponownej kompilacji biblioteki, aby docelowa ASP.NET Core 3.0.

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Microsoft.AspNetCore.Mvc.JsonResult

MVC: Przestarzałe narzędzie do kompilowania

W ASP.NET Core 1.1 Microsoft.AspNetCore.Mvc.Razor.ViewCompilation wprowadzono pakiet (narzędzie prekompilacji MVC), aby dodać obsługę kompilacji plików Razor w czasie publikowania (pliki cshtml ). W ASP.NET Core 2.1 zestaw SDK Razor został wprowadzony w celu rozszerzenia funkcji narzędzia prekompilacji. Zestaw SDK Razor dodał obsługę kompilacji plików Razor i kompilacji w czasie publikowania. Zestaw SDK sprawdza poprawność plików cshtml w czasie kompilacji, poprawiając czas uruchamiania aplikacji. Zestaw SDK Razor jest domyślnie włączony i nie trzeba używać żadnego gestu.

W ASP.NET Core 3.0 narzędzie prekompilacji MVC ASP.NET Core 1.1-era zostało usunięte. Wcześniejsze wersje pakietów będą nadal otrzymywać ważne poprawki błędów i zabezpieczeń w wydaniu poprawki.

Wprowadzona wersja

3.0

Stare zachowanie

Pakiet Microsoft.AspNetCore.Mvc.Razor.ViewCompilation został użyty do wstępnie skompilowania widoków MVC Razor.

Nowe zachowanie

Zestaw SDK Razor natywnie obsługuje tę funkcję. Pakiet Microsoft.AspNetCore.Mvc.Razor.ViewCompilation nie jest już aktualizowany.

Przyczyna wprowadzenia zmiany

Zestaw SDK Razor zapewnia większą funkcjonalność i weryfikuje poprawność plików cshtml w czasie kompilacji. Zestaw SDK poprawia również czas uruchamiania aplikacji.

W przypadku użytkowników programu ASP.NET Core 2.1 lub nowszego zaktualizuj ją, aby używać natywnej obsługi prekompilacji w zestawie SDK Razor. Jeśli usterki lub brakujące funkcje uniemożliwiają migrację do zestawu SDK Razor, otwórz problem w witrynie dotnet/aspnetcore.

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Brak

MVC: typy "Pubternal" zmieniły się na wewnętrzne

W ASP.NET Core 3.0 wszystkie typy "pubternal" w MVC zostały zaktualizowane tak, aby znajdowały się public w obsługiwanej przestrzeni nazw lub internal odpowiednio.

Opis zmiany

W ASP.NET Core typy "pubternal" są deklarowane jako public , ale znajdują się w .Internal-sufiksowanej przestrzeni nazw. Chociaż te typy to public, nie mają żadnych zasad pomocy technicznej i podlegają zmianom powodujących niezgodność. Niestety przypadkowe użycie tych typów było powszechne, co spowodowało niezgodność zmian w tych projektach i ograniczenie możliwości utrzymania struktury.

Wprowadzona wersja

3.0

Stare zachowanie

Niektóre typy w mvc były public , ale w .Internal przestrzeni nazw. Te typy nie miały żadnych zasad pomocy technicznej i podlegają zmianom powodujących niezgodność.

Nowe zachowanie

Wszystkie takie typy są aktualizowane tak, aby były public w obsługiwanej przestrzeni nazw lub oznaczone jako internal.

Przyczyna wprowadzenia zmiany

Przypadkowe użycie typów "pubternal" jest powszechne, co powoduje niezgodność zmian w tych projektach i ograniczenie możliwości utrzymania struktury.

Jeśli używasz typów, które stały się naprawdę public i zostały przeniesione do nowej, obsługiwanej przestrzeni nazw, zaktualizuj odwołania, aby były zgodne z nowymi przestrzeniami nazw.

Jeśli używasz typów, które zostały oznaczone jako internal, musisz znaleźć alternatywę. Wcześniej "pubternal" typy nigdy nie były obsługiwane do użytku publicznego. Jeśli istnieją określone typy w tych przestrzeniach nazw, które mają kluczowe znaczenie dla aplikacji, zgłoś problem w witrynie dotnet/aspnetcore. Podczas wprowadzania żądanych typów publicmożna wziąć pod uwagę następujące kwestie: .

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Ta zmiana obejmuje typy w następujących przestrzeniach nazw:

  • 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: usunięto podkładkę zgodności interfejsu API sieci Web

Począwszy od ASP.NET Core 3.0, Microsoft.AspNetCore.Mvc.WebApiCompatShim pakiet nie jest już dostępny.

Opis zmiany

Microsoft.AspNetCore.Mvc.WebApiCompatShim Pakiet (WebApiCompatShim) zapewnia częściową zgodność w ASP.NET Core z interfejsem API sieci Web ASP.NET 4.x 2, aby uprościć migrację istniejących implementacji internetowego interfejsu API do ASP.NET Core. Jednak aplikacje korzystające z interfejsu WebApiCompatShim nie korzystają z funkcji związanych z interfejsem API w ostatnich wersjach platformy ASP.NET Core. Takie funkcje obejmują ulepszone generowanie specyfikacji interfejsu OPEN API, ustandaryzowaną obsługę błędów i generowanie kodu klienta. Aby lepiej skoncentrować wysiłki interfejsu API w wersji 3.0, usunięto element WebApiCompatShim. Istniejące aplikacje korzystające z interfejsu WebApiCompatShim powinny zostać zmigrowane do nowszego [ApiController] modelu.

Wprowadzona wersja

3.0

Przyczyna wprowadzenia zmiany

Podkładka zgodności interfejsu API sieci Web była narzędziem do migracji. Ogranicza dostęp użytkowników do nowych funkcji dodanych w ASP.NET Core.

Usuń użycie tej podkładki i przeprowadź migrację bezpośrednio do podobnych funkcji w ASP.NET Core.

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Microsoft.AspNetCore.Mvc.WebApiCompatShim

Razor: usunięto interfejs API RazorTemplateEngine

Interfejs RazorTemplateEngine API został usunięty i zastąpiony elementem Microsoft.AspNetCore.Razor.Language.RazorProjectEngine.

Aby zapoznać się z dyskusją, zobacz problem z usługą GitHub dotnet/aspnetcore#25215.

Wprowadzona wersja

3.0

Stare zachowanie

Aparat szablonu można utworzyć i użyć do analizowania i generowania kodu dla plików Razor.

Nowe zachowanie

RazorProjectEngine Można utworzyć i podać ten sam typ informacji co RazorTemplateEngine do analizowania i generowania kodu dla plików Razor. RazorProjectEngine Zapewnia również dodatkowe poziomy konfiguracji.

Przyczyna wprowadzenia zmiany

RazorTemplateEngine była zbyt mocno połączona z istniejącymi implementacjami. To ścisłe sprzężenie doprowadziło do większej liczby pytań podczas próby prawidłowego skonfigurowania potoku analizy/generowania Razor.

Użyj RazorProjectEngine zamiast RazorTemplateEngine. Rozważmy następujące przykłady.

Tworzenie i konfigurowanie biblioteki 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
        });
Generowanie kodu dla pliku Razor
RazorProjectItem item = projectEngine.FileSystem.GetItem(
    @"C:\source\repos\ConsoleApp4\ConsoleApp4\Example.cshtml",
    FileKinds.Legacy);
RazorCodeDocument output = projectEngine.Process(item);

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

Kategoria

ASP.NET Core

Dotyczy interfejsów API

  • RazorTemplateEngine
  • RazorTemplateEngineOptions

Razor: kompilacja środowiska uruchomieniowego przeniesiona do pakietu

Obsługa kompilacji w czasie wykonywania widoków Razor i stron Razor została przeniesiona do oddzielnego pakietu.

Wprowadzona wersja

3.0

Stare zachowanie

Kompilacja środowiska uruchomieniowego jest dostępna bez konieczności używania dodatkowych pakietów.

Nowe zachowanie

Funkcjonalność została przeniesiona do pakietu Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation .

Następujące interfejsy API były wcześniej dostępne w Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions programie do obsługi kompilacji środowiska uruchomieniowego. Interfejsy API są teraz dostępne za pośrednictwem polecenia Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation.MvcRazorRuntimeCompilationOptions.

  • RazorViewEngineOptions.FileProviders jest teraz MvcRazorRuntimeCompilationOptions.FileProviders
  • RazorViewEngineOptions.AdditionalCompilationReferences jest teraz MvcRazorRuntimeCompilationOptions.AdditionalReferencePaths

Ponadto Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions.AllowRecompilingViewsOnFileChange usunięto element . Ponowne skompilowanie zmian plików jest domyślnie włączone przez odwoływanie Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation się do pakietu.

Przyczyna wprowadzenia zmiany

Ta zmiana była konieczna do usunięcia współużytkowanej zależności platformy ASP.NET Core z platformą Roslyn.

Aplikacje, które wymagają kompilacji środowiska uruchomieniowego lub ponownej kompilacji plików Razor, powinny wykonać następujące czynności:

  1. Dodaj odwołanie do Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation pakietu.

  2. Zaktualizuj metodę projektu Startup.ConfigureServices , aby uwzględnić wywołanie metody AddRazorRuntimeCompilation. Na przykład:

    services.AddMvc()
    .AddRazorRuntimeCompilation();

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions

Stan sesji: usunięte przestarzałe interfejsy API

Usunięto przestarzałe interfejsy API do konfigurowania plików cookie sesji. Aby uzyskać więcej informacji, zobacz aspnet/Announcements#257.

Wprowadzona wersja

3.0

Przyczyna wprowadzenia zmiany

Ta zmiana wymusza spójność między interfejsami API w celu konfigurowania funkcji korzystających z plików cookie.

Migrowanie użycia usuniętych interfejsów API do nowszych zamian. Rozważmy następujący przykład w pliku 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;
    });
}

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Struktura udostępniona: zestawy usunięte z Microsoft.AspNetCore.App

Począwszy od ASP.NET Core 3.0, platforma udostępniona ASP.NET Core (Microsoft.AspNetCore.App) zawiera tylko zestawy pierwszej firmy, które są w pełni opracowane, obsługiwane i obsługiwane przez firmę Microsoft.

Opis zmiany

Pomyśl o zmianie jako ponownej definicji granic dla ASP.NET Core "platformy". Platforma udostępniona będzie możliwa do tworzenia źródła przez każdego użytkownika za pośrednictwem usługi GitHub i będzie nadal oferować istniejące korzyści związane z platformami udostępnionymi platformy .NET Core dla Twoich aplikacji. Niektóre korzyści obejmują mniejszy rozmiar wdrożenia, scentralizowane stosowanie poprawek i krótszy czas uruchamiania.

W ramach zmiany niektóre istotne zmiany powodujące niezgodność są wprowadzane w programie Microsoft.AspNetCore.App.

Wprowadzona wersja

3.0

Stare zachowanie

Projekty, do których odwołuje się Microsoft.AspNetCore.App<PackageReference> element w pliku projektu.

Microsoft.AspNetCore.App Ponadto zawarte są następujące podskładniki:

  • Json.NET (Newtonsoft.Json)
  • Entity Framework Core (zestawy poprzedzone prefiksem Microsoft.EntityFrameworkCore.)
  • Roslyn (Microsoft.CodeAnalysis)

Nowe zachowanie

Odwołanie do Microsoft.AspNetCore.App elementu nie wymaga <PackageReference> już elementu w pliku projektu. Zestaw .NET Core SDK obsługuje nowy element o nazwie <FrameworkReference>, który zastępuje użycie elementu <PackageReference>.

Aby uzyskać więcej informacji, zobacz dotnet/aspnetcore#3612.

Program Entity Framework Core jest dostarczany jako pakiety NuGet. Ta zmiana jest zgodna z modelem wysyłki ze wszystkimi innymi bibliotekami dostępu do danych na platformie .NET. Zapewnia ona najprostszą ścieżkę do dalszego wprowadzania innowacji w programie Entity Framework Core, jednocześnie obsługując różne platformy .NET. Przeniesienie platformy Entity Framework Core z platformy udostępnionej nie ma wpływu na jej stan jako bibliotekę opracowaną przez firmę Microsoft, obsługiwaną i obsługiwaną. Zasady obsługi platformy .NET Core nadal go obejmują.

Json.NET i Entity Framework Core nadal współpracują z platformą ASP.NET Core. Nie zostaną one jednak uwzględnione w strukturze udostępnionej.

Aby uzyskać więcej informacji, zobacz Przyszłość kodu JSON na platformie .NET Core 3.0. Zobacz również pełną listę plików binarnych usuniętych ze struktury udostępnionej.

Przyczyna wprowadzenia zmiany

Ta zmiana upraszcza zużycie Microsoft.AspNetCore.App i zmniejsza duplikację pakietów NuGet i struktur udostępnionych.

Aby uzyskać więcej informacji na temat motywacji do tej zmiany, zobacz ten wpis w blogu.

Począwszy od ASP.NET Core 3.0, nie jest już konieczne używanie zestawów w projektach jako Microsoft.AspNetCore.App pakietów NuGet. Aby uprościć określanie celu i użycie platformy udostępnionej ASP.NET Core, wiele pakietów NuGet wysłanych od czasu, gdy ASP.NET Core 1.0 nie są już produkowane. Interfejsy API udostępniane przez te pakiety są nadal dostępne dla aplikacji przy użyciu elementu do <FrameworkReference>Microsoft.AspNetCore.App. Typowe przykłady interfejsów API to Kestrel, MVC i Razor.

Ta zmiana nie ma zastosowania do wszystkich plików binarnych, do których odwołuje się Microsoft.AspNetCore.App ASP.NET Core 2.x. Istotne wyjątki obejmują:

  • Microsoft.Extensions biblioteki, które nadal są przeznaczone dla platformy .NET Standard, są dostępne jako pakiety NuGet (zobacz https://github.com/dotnet/extensions).
  • Interfejsy API utworzone przez zespół platformy ASP.NET Core, które nie są częścią programu Microsoft.AspNetCore.App. Na przykład następujące składniki są dostępne jako pakiety NuGet:
  • Rozszerzenia mvC, które obsługują obsługę Json.NET. Interfejs API jest dostarczany jako pakiet NuGet do obsługi przy użyciu Json.NET i MVC. Aby uzyskać więcej informacji, zobacz przewodnik migracji ASP.NET Core.
  • Klient platformy .NET usługi SignalR nadal obsługuje platformę .NET Standard i jest dostarczany jako pakiet NuGet. Jest ona przeznaczona do użycia w wielu środowiskach uruchomieniowych platformy .NET, takich jak Xamarin i UWP.

Aby uzyskać więcej informacji, zobacz Zatrzymywanie tworzenia pakietów dla zestawów platform udostępnionych w wersji 3.0. Aby zapoznać się z dyskusją, zobacz dotnet/aspnetcore#3757.

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Struktura udostępniona: Usunięto microsoft.AspNetCore.All

Począwszy od ASP.NET Core 3.0, Microsoft.AspNetCore.All metapakiet i pasująca Microsoft.AspNetCore.All platforma udostępniona nie są już produkowane. Ten pakiet jest dostępny w wersji ASP.NET Core 2.2 i będzie nadal otrzymywać aktualizacje obsługi w programie ASP.NET Core 2.1.

Wprowadzona wersja

3.0

Stare zachowanie

Aplikacje mogą używać Microsoft.AspNetCore.All metapakiet do określania docelowej platformy udostępnionej Microsoft.AspNetCore.All na platformie .NET Core.

Nowe zachowanie

Platforma .NET Core 3.0 nie zawiera struktury udostępnionej Microsoft.AspNetCore.All .

Przyczyna wprowadzenia zmiany

Metapakiet Microsoft.AspNetCore.All zawierał dużą liczbę zależności zewnętrznych.

Migrowanie projektu w celu korzystania z platformy Microsoft.AspNetCore.App . Składniki, które były wcześniej dostępne w programie Microsoft.AspNetCore.All , są nadal dostępne w narzędziu NuGet. Te składniki są teraz wdrażane przy użyciu aplikacji zamiast dołączania ich do struktury udostępnionej.

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Brak

SignalR: HandshakeProtocol.SuccessHandshakeData zastąpiono

Pole HandshakeProtocol.SuccessHandshakeData zostało usunięte i zastąpione metodą pomocnika, która generuje pomyślną odpowiedź uzgadniania na podstawie określonego IHubProtocolelementu .

Wprowadzona wersja

3.0

Stare zachowanie

HandshakeProtocol.SuccessHandshakeData był polem public static ReadOnlyMemory<byte> .

Nowe zachowanie

HandshakeProtocol.SuccessHandshakeData został zastąpiony przez metodę staticGetSuccessfulHandshake(IHubProtocol protocol) , która zwraca ReadOnlyMemory<byte> element na podstawie określonego protokołu.

Przyczyna wprowadzenia zmiany

Dodano dodatkowe pola do odpowiedzi uzgadniania, które nie są stałe i zmieniają się w zależności od wybranego protokołu.

Brak. Ten typ nie jest przeznaczony do użycia z kodu użytkownika. publicJest to element , dzięki czemu może być współużytkowany między serwerem SignalR i klientem. Może być również używany przez klientów signalr klienta napisanych na platformie .NET. Ta zmiana nie powinna mieć wpływu na użytkowników usługi SignalR.

Kategoria

ASP.NET Core

Dotyczy interfejsów API

HandshakeProtocol.SuccessHandshakeData

SignalR: usunięto metody Hub Połączenie ion ResetSendPing i ResetTimeout

Metody ResetSendPing i ResetTimeout zostały usunięte z interfejsu API usługi SignalR HubConnection . Metody te były pierwotnie przeznaczone tylko do użytku wewnętrznego, ale zostały upublicznione w ASP.NET Core 2.2. Te metody nie będą dostępne, począwszy od wersji ASP.NET Core 3.0 (wersja zapoznawcza 4). Aby zapoznać się z dyskusją, zobacz dotnet/aspnetcore#8543.

Wprowadzona wersja

3.0

Stare zachowanie

Dostępne były interfejsy API.

Nowe zachowanie

Interfejsy API są usuwane.

Przyczyna wprowadzenia zmiany

Metody te były pierwotnie przeznaczone tylko do użytku wewnętrznego, ale zostały upublicznione w ASP.NET Core 2.2.

Nie używaj tych metod.

Kategoria

ASP.NET Core

Dotyczy interfejsów API

SignalR: Konstruktory Hub Połączenie ionContext uległy zmianie

Konstruktory usługi SignalR HubConnectionContext zmieniły się tak, aby akceptowały typ opcji, a nie wiele parametrów, do opcji dodawania w przyszłości. Ta zmiana zastępuje dwa konstruktory jednym konstruktorem, który akceptuje typ opcji.

Wprowadzona wersja

3.0

Stare zachowanie

HubConnectionContext ma dwa konstruktory:

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

Nowe zachowanie

Dwa konstruktory zostały usunięte i zastąpione jednym konstruktorem:

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

Przyczyna wprowadzenia zmiany

Nowy konstruktor używa nowego obiektu opcji. W związku z HubConnectionContext tym funkcje programu można rozszerzyć w przyszłości bez wprowadzania większej liczby konstruktorów i zmian powodujących niezgodność.

Zamiast używać następującego konstruktora:

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

Użyj następującego konstruktora:

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

Kategoria

ASP.NET Core

Dotyczy interfejsów API

SignalR: zmieniono nazwę pakietu klienta JavaScript

W programie ASP.NET Core 3.0 (wersja zapoznawcza 7) nazwa pakietu klienta SignalR JavaScript została zmieniona z @aspnet/signalr na @microsoft/signalr. Zmiana nazwy odzwierciedla fakt, że usługa SignalR jest przydatna w aplikacjach innych niż tylko ASP.NET Core dzięki usłudze Azure SignalR Service.

Aby zareagować na tę zmianę, zmień odwołania do plików, instrukcji i require instrukcji ECMAScript import w plikach package.json. Żaden interfejs API nie zmieni się w ramach tej zmiany nazwy.

Aby zapoznać się z dyskusją, zobacz dotnet/aspnetcore#11637.

Wprowadzona wersja

3.0

Stare zachowanie

Pakiet klienta nosił nazwę @aspnet/signalr.

Nowe zachowanie

Pakiet klienta ma nazwę @microsoft/signalr.

Przyczyna wprowadzenia zmiany

Zmiana nazwy wyjaśnia, że usługa SignalR jest przydatna poza aplikacjami ASP.NET Core dzięki usłudze Azure SignalR Service.

Przejdź do nowego pakietu @microsoft/signalr.

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Brak

SignalR: Metody UseSignalR i Use Połączenie ions oznaczone jako przestarzałe

Metody UseConnections i UseSignalR klasy ConnectionsRouteBuilder i HubRouteBuilder są oznaczone jako przestarzałe w ASP.NET Core 3.0.

Wprowadzona wersja

3.0

Stare zachowanie

Routing koncentratora usługi SignalR został skonfigurowany przy użyciu polecenia UseSignalR lub UseConnections.

Nowe zachowanie

Stary sposób konfigurowania routingu został przestarzały i zastąpiony routingiem punktów końcowych.

Przyczyna wprowadzenia zmiany

Oprogramowanie pośredniczące jest przenoszone do nowego systemu routingu punktów końcowych. Stary sposób dodawania oprogramowania pośredniczącego jest przestarzały.

Zastąp ciąg UseSignalR ciągiem UseEndpoints:

Stary kod:

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

Nowy kod:

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

Kategoria

ASP.NET Core

Dotyczy interfejsów API

SpAs: SpaServices i NodeServices oznaczone jako przestarzałe

Zawartość następujących pakietów NuGet była niepotrzebna od czasu ASP.NET Core 2.1. W związku z tym następujące pakiety są oznaczone jako przestarzałe:

Z tego samego powodu następujące moduły npm są oznaczane jako przestarzałe:

Poprzednie pakiety i moduły npm zostaną później usunięte na platformie .NET 5.

Wprowadzona wersja

3.0

Stare zachowanie

Przestarzałe pakiety i moduły npm miały na celu integrację ASP.NET Core z różnymi strukturami aplikacji jednostronicowej (SPA). Takie struktury obejmują platformy Angular, React i React z redux.

Nowe zachowanie

W pakiecie NuGet Microsoft.AspNetCore.SpaServices.Extensions istnieje nowy mechanizm integracji. Pakiet pozostaje podstawą szablonów projektów Angular i React od czasu ASP.NET Core 2.1.

Przyczyna wprowadzenia zmiany

platforma ASP.NET Core obsługuje integrację z różnymi platformami aplikacji jednostronicowych(SPA), w tym angular, React i React z systemem Redux. Początkowo integracja z tymi strukturami odbywała się z ASP.NET składnikami specyficznymi dla rdzeni, które obsługiwały scenariusze, takie jak wstępne wdrażanie po stronie serwera i integracja z pakietem WebPack. Wraz z upływem czasu standardy branżowe uległy zmianie. Każda ze struktur SPA wydała własne standardowe interfejsy wiersza polecenia. Na przykład interfejs wiersza polecenia platformy Angular i aplikacja create-react-.

Po wydaniu ASP.NET Core 2.1 w maju 2018 r. zespół zareagował na zmianę standardów. Udostępniono nowszy i prostszy sposób integracji z własnymi łańcuchami narzędzi SPA. Nowy mechanizm integracji istnieje w pakiecie Microsoft.AspNetCore.SpaServices.Extensions i pozostaje podstawą szablonów projektów Angular i React od ASP.NET Core 2.1.

Aby wyjaśnić, że starsze składniki specyficzne dla ASP.NET Core są nieistotne i nie są zalecane:

  • Mechanizm integracji sprzed wersji 2.1 jest oznaczony jako przestarzały.
  • Pomocnicze pakiety npm są oznaczone jako przestarzałe.

Jeśli używasz tych pakietów, zaktualizuj aplikacje, aby korzystały z funkcji:

  • W pakiecie Microsoft.AspNetCore.SpaServices.Extensions .
  • Dostarczane przez struktury SPA, z których korzystasz

Aby włączyć funkcje, takie jak wstępne ładowanie po stronie serwera i przeładowywanie modułu na gorąco, zobacz dokumentację odpowiedniej struktury SPA. Funkcja w programie Microsoft.AspNetCore.SpaServices.Extensions nie jest przestarzała i będzie nadal obsługiwana.

Kategoria

ASP.NET Core

Dotyczy interfejsów API

SpAs: SpaServices i NodeServices nie wracają już do rejestratora konsoli

Microsoft.AspNetCore.SpaServices i Microsoft.AspNetCore.NodeServices nie będzie wyświetlać dzienników konsoli, chyba że rejestrowanie jest skonfigurowane.

Wprowadzona wersja

3.0

Stare zachowanie

Microsoft.AspNetCore.SpaServices i Microsoft.AspNetCore.NodeServices służy do automatycznego tworzenia rejestratora konsoli, gdy rejestrowanie nie jest skonfigurowane.

Nowe zachowanie

Microsoft.AspNetCore.SpaServices i Microsoft.AspNetCore.NodeServices nie będzie wyświetlać dzienników konsoli, chyba że rejestrowanie jest skonfigurowane.

Przyczyna wprowadzenia zmiany

Istnieje potrzeba dopasowania do sposobu implementowania rejestrowania innych pakietów ASP.NET Core.

Jeśli stare zachowanie jest wymagane, aby skonfigurować rejestrowanie konsoli, dodaj services.AddLogging(builder => builder.AddConsole()) do Setup.ConfigureServices metody .

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Brak

Struktura docelowa: obsługa platformy .NET Framework została porzucona

Począwszy od platformy ASP.NET Core 3.0, platforma .NET Framework jest nieobsługiwaną platformą docelową.

Opis zmiany

.NET Framework 4.8 to ostatnia wersja główna programu .NET Framework. Nowe aplikacje ASP.NET Core powinny być tworzone na platformie .NET Core. Począwszy od wersji .NET Core 3.0, można traktować ASP.NET Core 3.0 jako część platformy .NET Core.

Klienci korzystający z platformy ASP.NET Core z programem .NET Framework mogą kontynuować w pełni obsługiwany sposób przy użyciu wersji 2.1 LTS. Wsparcie i obsługa dla wersji 2.1 trwa do co najmniej 21 sierpnia 2021 r. Ta data to trzy lata po deklaracji wydania LTS zgodnie z zasadami pomocy technicznej platformy .NET. Obsługa pakietów ASP.NET Core 2.1 w programie .NET Framework będzie rozszerzana na czas nieokreślony, podobnie jak w przypadku innych platform ASP.NET opartych na pakietach.

Aby uzyskać więcej informacji na temat przenoszenia z programu .NET Framework do platformy .NET Core, zobacz Przenoszenie do platformy .NET Core.

Microsoft.Extensions Nie ma to wpływu na pakiety (takie jak rejestrowanie, wstrzykiwanie zależności i konfiguracja) i Entity Framework Core. Będą nadal obsługiwać platformę .NET Standard.

Aby uzyskać więcej informacji na temat motywacji do tej zmiany, zobacz oryginalny wpis w blogu.

Wprowadzona wersja

3.0

Stare zachowanie

aplikacje ASP.NET Core mogą działać na platformie .NET Core lub .NET Framework.

Nowe zachowanie

aplikacje ASP.NET Core można uruchamiać tylko na platformie .NET Core.

Przeprowadź jedną z następujących czynności:

  • Zachowaj aplikację na platformie ASP.NET Core 2.1.
  • Migrowanie aplikacji i zależności do platformy .NET Core.

Kategoria

ASP.NET Core

Dotyczy interfejsów API

Brak

Podstawowe biblioteki platformy .NET

Interfejsy API raportu, które teraz zgłaszają wersję produktu, a nie wersję pliku

Wiele interfejsów API, które zwracają wersje na platformie .NET Core, zwraca teraz wersję produktu, a nie wersję pliku.

Opis zmiany

W programie .NET Core 2.2 i poprzednich wersjach metody, takie jak Environment.Version, RuntimeInformation.FrameworkDescriptioni okno dialogowe właściwości pliku dla zestawów platformy .NET Core odzwierciedla wersję pliku. Począwszy od platformy .NET Core 3.0, odzwierciedlają wersję produktu.

Na poniższej ilustracji przedstawiono różnicę w informacjach o wersji zestawu System.Runtime.dll dla platformy .NET Core 2.2 (po lewej stronie) i programu .NET Core 3.0 (po prawej stronie) wyświetlanego przez okno dialogowe właściwości pliku Eksploratora Windows.

Difference in product version information

Wprowadzona wersja

3.0

Brak. Ta zmiana powinna sprawić, że wykrywanie wersji powinno być intuicyjne, a nie zatusze.

Kategoria

Podstawowe biblioteki platformy .NET

Dotyczy interfejsów API

Wystąpienia custom EncoderFallbackBuffer nie mogą wrócić rekursywnie

Wystąpienia niestandardowe EncoderFallbackBuffer nie mogą powracać rekursywnie. Implementacja EncoderFallbackBuffer.GetNextChar() musi skutkować sekwencją znaków, która jest konwertowana na kodowanie docelowe. W przeciwnym razie wystąpi wyjątek.

Opis zmiany

Podczas operacji transkodowania znaków do bajtów środowisko uruchomieniowe wykrywa źle sformułowane lub niekonwertowalne sekwencje UTF-16 i udostępnia te znaki metodzie EncoderFallbackBuffer.Fallback . Metoda Fallback określa, które znaki powinny zostać zastąpione oryginalnymi danymi niekonwertowalnymi, a te znaki są opróżniane przez wywołanie EncoderFallbackBuffer.GetNextChar w pętli.

Następnie środowisko uruchomieniowe próbuje transkodować te znaki podstawienia do kodowania docelowego. Jeśli ta operacja powiedzie się, środowisko uruchomieniowe kontynuuje transkodowanie, z którego zostało wyłączone w oryginalnym ciągu wejściowym.

Wcześniej niestandardowe implementacje EncoderFallbackBuffer.GetNextChar() programu mogą zwracać sekwencje znaków, które nie są konwertowane na kodowanie docelowe. Jeśli nie można transkodować znaków zastępczych do kodowania docelowego, środowisko uruchomieniowe ponownie wywołuje EncoderFallbackBuffer.Fallback metodę z znakami podstawienia, oczekując EncoderFallbackBuffer.GetNextChar() , że metoda zwróci nową sekwencję podstawienia. Ten proces będzie kontynuowany do momentu, aż środowisko uruchomieniowe w końcu zobaczy prawidłowo sformułowane, zamieniające się podstawianie lub do momentu osiągnięcia maksymalnej liczby rekursji.

Począwszy od platformy .NET Core 3.0, niestandardowe implementacje EncoderFallbackBuffer.GetNextChar() muszą zwracać sekwencje znaków, które są konwertowane na kodowanie docelowe. Jeśli nie można transkodować znaków zastępczych do kodowania docelowego, ArgumentException zostanie zgłoszony element . Środowisko uruchomieniowe nie będzie już wykonywać cyklicznych wywołań do EncoderFallbackBuffer wystąpienia.

To zachowanie ma zastosowanie tylko wtedy, gdy zostaną spełnione wszystkie trzy z następujących warunków:

  • Środowisko uruchomieniowe wykrywa nieprawidłową sekwencję UTF-16 lub sekwencję UTF-16, której nie można przekonwertować na kodowanie docelowe.
  • Określono niestandardowe EncoderFallback .
  • EncoderFallback Niestandardowe próby zastąpienia nowej źle sformułowanej lub niekonwertowalnej sekwencji UTF-16.

Wprowadzona wersja

3.0

Większość deweloperów nie potrzebuje żadnych działań.

Jeśli aplikacja używa niestandardowego EncoderFallback i EncoderFallbackBuffer klasy, upewnij się, że implementacja buforu EncoderFallbackBuffer.Fallback rezerwowego jest wypełniana dobrze sformułowanymi danymi UTF-16, które są bezpośrednio konwertowane na kodowanie docelowe, gdy Fallback metoda jest wywoływana po raz pierwszy przez środowisko uruchomieniowe.

Kategoria

Podstawowe biblioteki platformy .NET

Dotyczy interfejsów API

Zachowanie formatowania zmiennoprzecinkowego i analizowania zostało zmienione

Zachowanie analizowania i formatowania zmiennoprzecinkowego (według Double typów i Single ) jest teraz zgodne ze standardem IEEE. Dzięki temu zachowanie typów zmiennoprzecinkowych na platformie .NET jest zgodne z innymi językami zgodnymi ze standardem IEEE. Na przykład double.Parse("SomeLiteral") należy zawsze odpowiadać wartościom generowanym przez język C# dla elementu double x = SomeLiteral.

Opis zmiany

W programie .NET Core 2.2 i starszych wersjach formatowanie za pomocą Double.ToString poleceń i Single.ToStringoraz analizowanie za pomocą poleceń , Double.TryParse, Single.Parsei Single.TryParse nie jest zgodne ze standardem Double.ParseIEEE. W związku z tym nie można zagwarantować, że wartość zostanie zaokrąglona z dowolnym obsługiwanym ciągiem formatu standardowego lub niestandardowego. W przypadku niektórych danych wejściowych próba przeanalizowania sformatowanej wartości może zakończyć się niepowodzeniem, a dla innych przeanalizowana wartość nie jest równa oryginalnej wartości.

Począwszy od platformy .NET Core 3.0, operacje analizowania i formatowania zmiennoprzecinkowego są zgodne ze standardem IEEE 754.

W poniższej tabeli przedstawiono dwa fragmenty kodu i sposób zmiany danych wyjściowych między platformą .NET Core 2.2 i platformą .NET Core 3.1.

Fragment kodu Dane wyjściowe na platformie .NET Core 2.2 Dane wyjściowe na platformie .NET Core 3.1
Console.WriteLine((-0.0).ToString()); 0 0–
var value = -3.123456789123456789;
Console.WriteLine(value == double.Parse(value.ToString()));		 False True

Aby uzyskać więcej informacji, zobacz ulepszenia analizowania i formatowania zmiennoprzecinkowe w wpisie w blogu platformy .NET Core 3.0 .

Wprowadzona wersja

3.0

Potencjalny wpływ na istniejącą sekcję kodu ulepszenia analizowania i formatowania zmiennoprzecinkowego w wpisie w blogu platformy .NET Core 3.0 sugeruje pewne zmiany, które można wprowadzić w kodzie, jeśli chcesz zachować poprzednie zachowanie.

  • W przypadku niektórych różnic w formatowaniu można uzyskać zachowanie równoważne poprzedniemu zachowaniu, określając inny ciąg formatu.
  • W przypadku różnic w analizowaniu nie ma mechanizmu powrotu do poprzedniego zachowania.

Kategoria

Podstawowe biblioteki platformy .NET

Dotyczy interfejsów API

Operacje analizowania zmiennoprzecinkowego nie kończą się już niepowodzeniem ani nie zgłaszają wyjątku OverflowException

Metody analizowania zmiennoprzecinkowego nie zgłaszają OverflowException już wartości lub zwracają false , gdy analizują ciąg, którego wartość liczbowa znajduje się poza zakresem Single typu zmiennoprzecinkowego lub Double zmiennoprzecinkowego.

Opis zmiany

W przypadku platformy .NET Core 2.2 i starszych wersji Double.Parse metody i Single.Parse zgłaszają OverflowException wartości spoza zakresu odpowiedniego typu. Metody Double.TryParse i Single.TryParse zwracają false reprezentacje ciągów poza zakresem wartości liczbowych.

Począwszy od platformy .NET Core 3.0, Double.Parsemetody , Double.TryParse, Single.Parsei Single.TryParse nie kończą się już niepowodzeniem podczas analizowania ciągów liczbowych poza zakresem. Double Zamiast tego metody analizowania zwracają Double.PositiveInfinity wartości, które przekraczają Double.MaxValuewartość , i zwracają Double.NegativeInfinity wartości, które są mniejsze niż Double.MinValue. Single Podobnie metody analizowania zwracają Single.PositiveInfinity wartości, które przekraczają Single.MaxValuewartość , i zwracają Single.NegativeInfinity wartości, które są mniejsze niż Single.MinValue.

Ta zmiana została wprowadzona w celu poprawy zgodności IEEE 754:2008.

Wprowadzona wersja

3.0

Ta zmiana może mieć wpływ na kod na jeden z dwóch sposobów:

  • Kod zależy od programu obsługi, OverflowException który ma zostać wykonany, gdy wystąpi przepełnienie. W takim przypadku należy usunąć instrukcję catch i umieścić dowolny niezbędny kod w If instrukcji, która sprawdza, czy Single.IsInfinityDouble.IsInfinity element ma truewartość .

  • W kodzie przyjęto założenie, że wartości zmiennoprzecinkowe nie Infinitysą . W takim przypadku należy dodać niezbędny kod, aby sprawdzić wartości PositiveInfinity zmiennoprzecinkowe i NegativeInfinity.

Kategoria

Podstawowe biblioteki platformy .NET

Dotyczy interfejsów API

InvalidAsynchronousStateException przeniesiono do innego zestawu

Klasa została przeniesiona InvalidAsynchronousStateException .

Opis zmiany

W programie .NET Core 2.2 i starszych wersjach InvalidAsynchronousStateException klasa znajduje się w zestawie System.ComponentModel.TypeConverter .

Począwszy od platformy .NET Core 3.0, znajduje się on w zestawie System.ComponentModel.Primitives .

Wprowadzona wersja

3.0

Ta zmiana dotyczy tylko aplikacji, które używają odbicia w celu załadowania InvalidAsynchronousStateException obiektu przez wywołanie metody, takiej jak Assembly.GetType lub przeciążenie Activator.CreateInstance , które zakłada, że typ jest w określonym zestawie. W takim przypadku zaktualizuj zestaw, do którego odwołuje się wywołanie metody, aby odzwierciedlić nową lokalizację zestawu typu.

Kategoria

Podstawowe biblioteki platformy .NET

Dotyczy interfejsów API

Brak.

Zastępowanie źle sformułowanych sekwencji bajtów UTF-8 jest zgodne z wytycznymi Unicode

UTF8Encoding Gdy klasa napotka nieprawidłowo sformułowaną sekwencję bajtów UTF-8 podczas operacji transkodowania bajt-znak, zastępuje tę sekwencję znakiem " (U+FFFD REPLACE CHARACTER) w ciągu wyjściowym. Program .NET Core 3.0 różni się od poprzednich wersji platformy .NET Core i programu .NET Framework, stosując najlepsze rozwiązanie Unicode do wykonania tego zastąpienia podczas operacji transkodowania.

Jest to część większego nakładu pracy, aby ulepszyć obsługę utF-8 na platformie .NET, w tym przez nowe System.Text.Unicode.Utf8 i System.Text.Rune typy. Typ UTF8Encoding otrzymał ulepszoną mechanikę obsługi błędów, dzięki czemu generuje dane wyjściowe zgodne z nowo wprowadzonymi typami.

Opis zmiany

Począwszy od platformy .NET Core 3.0, gdy transkodowanie bajtów do znaków, UTF8Encoding klasa wykonuje podstawianie znaków na podstawie najlepszych rozwiązań Unicode. Używany mechanizm podstawiania jest opisany przez Standard Unicode w wersji 12.0, s. 3.9 (PDF) w nagłówku zatytułowanym Podstawianie U+FFFD maksymalnie części podrzędnych.

To zachowanie ma zastosowanie tylko wtedy, gdy sekwencja bajtów wejściowych zawiera źle sformułowane dane UTF-8. Ponadto jeśli UTF8Encoding wystąpienie zostało skonstruowane za pomocą throwOnInvalidBytes: truepolecenia , UTF8Encoding wystąpienie będzie nadal zgłaszać nieprawidłowe dane wejściowe, a nie wykonać zamiany U+FFFD. Aby uzyskać więcej informacji na temat konstruktora UTF8Encoding , zobacz UTF8Encoding(Boolean, Boolean).

W poniższej tabeli przedstawiono wpływ tej zmiany z nieprawidłowymi danymi wejściowymi 3-bajtowymi:

Źle sformułowane dane wejściowe 3-bajtowe Dane wyjściowe przed platformą .NET Core 3.0 Dane wyjściowe rozpoczynające się od platformy .NET Core 3.0
[ ED A0 90 ] [ FFFD FFFD ] (2-znakowe dane wyjściowe) [ FFFD FFFD FFFD ] (3-znakowe dane wyjściowe)

Dane wyjściowe 3-char są preferowanymi danymi wyjściowymi, zgodnie z tabelą 3-9 wcześniej połączonego standardowego pliku PDF Unicode.

Wprowadzona wersja

3.0

Ze strony dewelopera nie jest wymagana żadna akcja.

Kategoria

Podstawowe biblioteki platformy .NET

Dotyczy interfejsów API

TypeDescriptionProviderAttribute przeniesiono do innego zestawu

Klasa została przeniesiona TypeDescriptionProviderAttribute .

Opis zmiany

W programie .NET Core 2.2 i starszych wersjach TypeDescriptionProviderAttribute klasa znajduje się w zestawie System.ComponentModel.TypeConverter .

Począwszy od platformy .NET Core 3.0, znajduje się on w zestawie System.ObjectModel .

Wprowadzona wersja

3.0

Ta zmiana dotyczy tylko aplikacji, które używają odbicia w celu załadowania TypeDescriptionProviderAttribute typu przez wywołanie metody, takiej jak Assembly.GetType lub przeciążenie Activator.CreateInstance , które zakłada, że typ jest w określonym zestawie. W takim przypadku zestaw, do którego odwołuje się wywołanie metody, powinien zostać zaktualizowany w celu odzwierciedlenia nowej lokalizacji zestawu typu.

Kategoria

Windows Forms

Dotyczy interfejsów API

Brak.

ZipArchiveEntry nie obsługuje już archiwów z niespójnymi rozmiarami pozycji

Archiwa zip wyświetlają zarówno skompresowany rozmiar, jak i nieskompresowany rozmiar w centralnym katalogu i nagłówku lokalnym. Dane wejściowe również wskazują jego rozmiar. W programie .NET Core 2.2 i starszych wersjach te wartości nigdy nie były sprawdzane pod kątem spójności. Począwszy od platformy .NET Core 3.0, są teraz.

Opis zmiany

W programie .NET Core 2.2 i starszych wersjach kończy się powodzeniem, ZipArchiveEntry.Open() nawet jeśli nagłówek lokalny nie zgadza się z centralnym nagłówkiem pliku zip. Dane są dekompresowane do końca skompresowanego strumienia, nawet jeśli jego długość przekracza nieskompresowany rozmiar pliku wymieniony w centralnym katalogu/nagłówku lokalnym.

Począwszy od platformy .NET Core 3.0, metoda sprawdza, ZipArchiveEntry.Open() czy lokalny nagłówek i centralny nagłówek zgadzają się na skompresowane i nieskompresowane rozmiary wpisu. Jeśli tak nie jest, metoda zgłasza InvalidDataException , czy lokalny nagłówek archiwum i/lub rozmiary list deskryptora danych, które nie zgadzają się z centralnym katalogiem pliku zip. Podczas odczytywania wpisu zdekompresowane dane są obcinane do nieskompresowanego rozmiaru pliku wymienionego w nagłówku.

Ta zmiana została wprowadzona w celu zapewnienia, że ZipArchiveEntry prawidłowo reprezentuje rozmiar danych i że tylko ta ilość danych jest odczytywana.

Wprowadzona wersja

3.0

Zapakuj ponownie wszelkie archiwum zip, które wykazuje te problemy.

Kategoria

Podstawowe biblioteki platformy .NET

Dotyczy interfejsów API

FieldInfo.SetValue zgłasza wyjątek dla pól statycznych, tylko do inicjowania

Począwszy od platformy .NET Core 3.0, podczas próby ustawienia wartości w statycznym InitOnly polu jest zgłaszany wyjątek, wywołując metodę System.Reflection.FieldInfo.SetValue.

Opis zmiany

W programie .NET Framework i wersjach platformy .NET Core wcześniejszych niż 3.0 można ustawić wartość pola statycznego, które jest stałe po zainicjowaniu (tylko do odczytu w języku C#), wywołując metodę System.Reflection.FieldInfo.SetValue. Jednak ustawienie takiego pola w ten sposób spowodowało nieprzewidywalne zachowanie w oparciu o platformę docelową i ustawienia optymalizacji.

W programie .NET Core 3.0 lub nowszym podczas wywoływania SetValue statycznego InitOnly pola zgłaszany System.FieldAccessException jest wyjątek.

Napiwek

Pole InitOnly to pole, które można ustawić tylko wtedy, gdy jest zadeklarowane lub w konstruktorze dla zawierającej klasy. Innymi słowy, jest stała po zainicjowaniu.

Wprowadzona wersja

3.0

Inicjowanie statycznych InitOnly pól w konstruktorze statycznym. Dotyczy to zarówno typów dynamicznych, jak i niedynamicznych.

Alternatywnie możesz usunąć FieldAttributes.InitOnly atrybut z pola, a następnie wywołać metodę FieldInfo.SetValue.

Kategoria

Podstawowe biblioteki platformy .NET

Dotyczy interfejsów API

Przekazywanie elementu GroupCollection do metod rozszerzeń przy użyciu metody IEnumerable<T> wymaga uściślania

Podczas wywoływania metody rozszerzenia, która przyjmuje IEnumerable<T> element na GroupCollectionobiekcie , należy uściślić typ przy użyciu rzutowania.

Opis zmiany

Począwszy od platformy .NET Core 3.0, System.Text.RegularExpressions.GroupCollection implementuje oprócz innych typów, które implementuje IEnumerable<KeyValuePair<String,Group>> , w tym IEnumerable<Group>. Powoduje to niejednoznaczność podczas wywoływania metody rozszerzenia, która przyjmuje metodę IEnumerable<T>. Jeśli wywołasz taką metodę rozszerzenia na GroupCollection przykład , Enumerable.Countzobaczysz następujący błąd kompilatora:

CS1061: "GroupCollection" nie zawiera definicji metody "Count" i nie można odnaleźć dostępnej metody rozszerzenia "Count" akceptującej pierwszy argument typu "GroupCollection" (czy brakuje dyrektywy using lub odwołania do zestawu?)

W poprzednich wersjach platformy .NET nie było żadnych niejednoznaczności i nie było błędu kompilatora.

Wprowadzona wersja

3.0

Przyczyna wprowadzenia zmiany

Była to niezamierzona zmiana powodująca niezgodność. Ponieważ to było tak od jakiegoś czasu, nie planujemy go przywrócić. Ponadto taka zmiana sama byłaby łamiąca.

Na GroupCollection przykład uściślanie wywołań metod rozszerzenia, które akceptują metodę IEnumerable<T> rzutowania.

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

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

Kategoria

Podstawowe biblioteki platformy .NET

Dotyczy interfejsów API

Dotyczy to dowolnej metody rozszerzenia, która akceptuje IEnumerable<T> element . Na przykład:

Kryptografia

Składnia "BEGIN TRUSTED CERTIFICATE" nie jest już obsługiwana dla certyfikatów głównych w systemie Linux

Certyfikaty główne w systemach Linux i innych systemach podobnych do unix (ale nie macOS) mogą być prezentowane w dwóch formach: standardowy BEGIN CERTIFICATE nagłówek PEM i nagłówek PEM specyficzny dla BEGIN TRUSTED CERTIFICATE protokołu OpenSSL. Ta ostatnia składnia umożliwia dodatkową konfigurację, która spowodowała problemy ze zgodnością z klasą platformy System.Security.Cryptography.X509Certificates.X509Chain .NET Core. BEGIN TRUSTED CERTIFICATE Zawartość certyfikatu głównego nie jest już ładowana przez aparat łańcucha rozpoczynający się w programie .NET Core 3.0.

Opis zmiany

Wcześniej użyto składni BEGIN CERTIFICATE i BEGIN TRUSTED CERTIFICATE do wypełnienia głównej listy zaufania. BEGIN TRUSTED CERTIFICATE Jeśli użyto składni i określono dodatkowe opcje w pliku, być może zgłoszono, X509Chain że zaufanie łańcucha zostało jawnie niedozwolone (X509ChainStatusFlags.ExplicitDistrust). Jeśli jednak certyfikat został również określony ze BEGIN CERTIFICATE składnią w wcześniej załadowanym pliku, zaufanie łańcucha było dozwolone.

Począwszy od platformy .NET Core 3.0, BEGIN TRUSTED CERTIFICATE zawartość nie jest już odczytywana. Jeśli certyfikat nie jest również określony za pomocą standardowej BEGIN CERTIFICATE składni, raportuje, X509Chain że katalog główny nie jest zaufany (X509ChainStatusFlags.UntrustedRoot).

Wprowadzona wersja

3.0

Większość aplikacji nie ma wpływu na tę zmianę, ale aplikacje, które nie widzą obu źródeł certyfikatów głównych z powodu problemów z uprawnieniami, mogą wystąpić nieoczekiwane UntrustedRoot błędy po uaktualnieniu.

Wiele dystrybucji systemu Linux (lub dystrybucji) zapisuje certyfikaty główne w dwóch lokalizacjach: katalog jeden certyfikat na plik i łączenie jednego pliku. W niektórych dystrybucjach katalog jeden certyfikat na plik używa BEGIN TRUSTED CERTIFICATE składni, podczas gdy łączenie plików używa standardowej BEGIN CERTIFICATE składni. Upewnij się, że wszystkie niestandardowe certyfikaty główne są dodawane tak jak BEGIN CERTIFICATE w co najmniej jednej z tych lokalizacji i że obie lokalizacje mogą być odczytywane przez aplikację.

Typowy katalog to /etc/ssl/certs/ i typowy połączony plik to /etc/ssl/cert.pem. Użyj polecenia openssl version -d , aby określić katalog główny specyficzny dla platformy, który może się różnić od /etc/ssl/. Na przykład w systemie Ubuntu 18.04 katalog to /usr/lib/ssl/certs/ i plik to /usr/lib/ssl/cert.pem. Jednak /usr/lib/ssl/certs/ jest symlinkiem do /etc/ssl/certs/ i /usr/lib/ssl/cert.pem nie istnieje.

$ 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

Kategoria

Kryptografia

Dotyczy interfejsów API

Ustawienie domyślne kopertyCms do szyfrowania AES-256

Domyślny algorytm szyfrowania symetrycznego używany przez EnvelopedCms program został zmieniony z TripleDES na AES-256.

Opis zmiany

W poprzednich wersjach, gdy EnvelopedCms jest używany do szyfrowania danych bez określania algorytmu szyfrowania symetrycznego za pośrednictwem przeciążenia konstruktora, dane są szyfrowane za pomocą algorytmu TripleDES/3DES/3DEA/DES3-EDE.

Począwszy od programu .NET Core 3.0 (w wersji 4.6.0 pakietu NuGet System.Security.Cryptography.Pkcs ), domyślny algorytm został zmieniony na AES-256 na potrzeby modernizacji algorytmu i w celu poprawy bezpieczeństwa opcji domyślnych. Jeśli certyfikat odbiorcy wiadomości ma klucz publiczny Diffie-Hellman (inny niż EC), operacja szyfrowania może zakończyć się niepowodzeniem CryptographicException z powodu ograniczeń w podstawowej platformie.

W poniższym przykładowym kodzie dane są szyfrowane za pomocą funkcji TripleDES, jeśli są uruchomione na platformie .NET Core 2.2 lub starszej wersji. W przypadku korzystania z platformy .NET Core 3.0 lub nowszej jest ona szyfrowana przy użyciu protokołu AES-256.

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

Wprowadzona wersja

3.0

Jeśli zmiana ma negatywny wpływ, możesz przywrócić szyfrowanie TripleDES, jawnie określając identyfikator algorytmu szyfrowania w konstruktorze EnvelopedCms zawierającym parametr typu AlgorithmIdentifier, na przykład:

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

Kategoria

Kryptografia

Dotyczy interfejsów API

Minimalny rozmiar generowania kluczy RSAOpenSsl został zwiększony

Minimalny rozmiar generowania nowych kluczy RSA w systemie Linux wzrósł z 384-bitowego do 512-bitowego.

Opis zmiany

Począwszy od platformy .NET Core 3.0, minimalny rozmiar klucza prawnego zgłoszony przez LegalKeySizes właściwość w wystąpieniach RSA z RSA.Create, RSAOpenSsli RSACryptoServiceProvider w systemie Linux wzrósł z 384 do 512.

W związku z tym w programie .NET Core 2.2 i starszych wersjach wywołanie metody, takie jak RSA.Create(384) powodzenie. W wersjach .NET Core 3.0 i nowszych wywołanie RSA.Create(384) metody zgłasza wyjątek wskazujący, że rozmiar jest zbyt mały.

Ta zmiana została wprowadzona, ponieważ program OpenSSL, który wykonuje operacje kryptograficzne w systemie Linux, podniósł wartość minimalną między wersjami 1.0.2 i 1.1.0. Platforma .NET Core 3.0 preferuje bibliotekę OpenSSL 1.1.x do wersji 1.0.x, a minimalna zgłoszona wersja została podniesiona, aby odzwierciedlić to nowe wyższe ograniczenie zależności.

Wprowadzona wersja

3.0

Jeśli wywołasz dowolny z interfejsów API, których dotyczy problem, upewnij się, że rozmiar wszystkich wygenerowanych kluczy nie jest mniejszy niż minimalna wartość dostawcy.

Uwaga

384-bitowa analiza RSA jest już uważana za niezabezpieczoną (podobnie jak 512-bitowa RSA). Nowoczesne zalecenia, takie jak NIST Special Publication 800-57 Part 1 Revision 4, sugerują 2048-bitowy minimalny rozmiar dla nowo wygenerowanych kluczy.

Kategoria

Kryptografia

Dotyczy interfejsów API

Platforma .NET Core 3.0 preferuje program OpenSSL 1.1.x do biblioteki OpenSSL 1.0.x

Platforma .NET Core dla systemu Linux, która działa w wielu dystrybucjach systemu Linux, może obsługiwać zarówno programy OpenSSL 1.0.x, jak i OpenSSL 1.1.x. .NET Core 2.1 i .NET Core 2.2 najpierw poszukaj wersji 1.0.x, a następnie wróć do wersji 1.1.x; platforma .NET Core 3.0 najpierw szuka wersji 1.1.x. Ta zmiana została wprowadzona w celu dodania obsługi nowych standardów kryptograficznych.

Ta zmiana może mieć wpływ na biblioteki lub aplikacje, które współdziałają między platformami z typami międzyoperacyjności specyficznymi dla bibliotek OpenSSL na platformie .NET Core.

Opis zmiany

W programie .NET Core 2.2 i starszych wersjach środowisko uruchomieniowe preferuje ładowanie biblioteki OpenSSL 1.0.x przez 1.1.x. Oznacza to, że IntPtr typy i SafeHandle dla międzyoperacyjności z biblioteką OpenSSL są używane z biblioteką libcrypto.so.1.0.0 / libcrypto.so.1.0 / libcrypto.so.10 według preferencji.

Począwszy od platformy .NET Core 3.0, środowisko uruchomieniowe preferuje ładowanie biblioteki OpenSSL 1.1.x za pośrednictwem biblioteki OpenSSL 1.0.x, więc IntPtr typy i SafeHandle dla międzyoperacyjności z biblioteką OpenSSL są używane z biblioteką libcrypto.so.1.1 / libcrypto.so.1.0 / libcrypto.so.1.1.1 według preferencji. W związku z tym biblioteki i aplikacje, które współdziałają bezpośrednio z biblioteką OpenSSL, mogą mieć niezgodne wskaźniki z wartościami uwidacznianymi na platformie .NET Core podczas uaktualniania z platformy .NET Core 2.1 lub .NET Core 2.2.

Wprowadzona wersja

3.0

Biblioteki i aplikacje, które wykonują bezpośrednie operacje za pomocą biblioteki OpenSSL, muszą być ostrożne, aby upewnić się, że używają one tej samej wersji biblioteki OpenSSL co środowisko uruchomieniowe platformy .NET Core.

Wszystkie biblioteki lub aplikacje używające IntPtr lub SafeHandle wartości z typów kryptograficznych platformy .NET Core bezpośrednio z biblioteką OpenSSL powinny porównać wersję biblioteki używanej z nową SafeEvpPKeyHandle.OpenSslVersion właściwością, aby upewnić się, że wskaźniki są zgodne.

Kategoria

Kryptografia

Dotyczy interfejsów API

CryptoStream.Dispose przekształca końcowy blok tylko podczas zapisywania

Metoda CryptoStream.Dispose , która służy do kończenie CryptoStream operacji, nie próbuje już przekształcić końcowego bloku podczas odczytywania.

Opis zmiany

Jeśli w poprzednich wersjach platformy .NET użytkownik wykonał niekompletne odczyty w CryptoStreamRead trybie, Dispose metoda może zgłosić wyjątek (na przykład w przypadku korzystania z AES z dopełnieniem). Wyjątek został zgłoszony, ponieważ ostatni blok próbowano przekształcić, ale dane były niekompletne.

W wersjach .NET Core 3.0 i nowszych Dispose nie próbuje już przekształcić końcowego bloku podczas odczytywania, co pozwala na niekompletne odczyty.

Przyczyna wprowadzenia zmiany

Ta zmiana umożliwia niekompletne odczyty ze strumienia kryptograficznego po anulowaniu operacji sieciowej bez konieczności przechwytywania wyjątku.

Wprowadzona wersja

3.0

Ta zmiana nie powinna mieć wpływu na większość aplikacji.

Jeśli aplikacja wcześniej przechwyciła wyjątek w przypadku niekompletnego odczytu, możesz usunąć ten catch blok. Jeśli aplikacja korzystała z przekształcania końcowego bloku w scenariuszach tworzenia skrótów, może być konieczne upewnienie się, że cały strumień jest odczytywany przed usunięciem.

Kategoria

Kryptografia

Dotyczy interfejsów API

Entity Framework Core

Zmiany powodujące niezgodność w programie Entity Framework Core

Globalizacja

Ustawienia regionalne "C" mapują na niezmienne ustawienia regionalne

Platforma .NET Core 2.2 i starsze wersje zależą od domyślnego zachowania ICU, które mapuje ustawienia regionalne "C" na ustawienia regionalne en_US_POSIX. Ustawienia regionalne en_US_POSIX mają niepożądane zachowanie sortowania, ponieważ nie obsługuje porównań ciągów bez uwzględniania wielkości liter. Ponieważ niektóre dystrybucje systemu Linux ustawiają ustawienia regionalne "C" jako domyślne ustawienia regionalne, użytkownicy napotykali nieoczekiwane zachowanie.

Opis zmiany

Począwszy od platformy .NET Core 3.0, mapowanie ustawień regionalnych "C" zmieniło się tak, aby używało niezmiennych ustawień regionalnych zamiast en_US_POSIX. Ustawienia regionalne "C" do niezmiennego mapowania są również stosowane do systemu Windows w celu zapewnienia spójności.

Mapowanie "C" na kulturę en_US_POSIX spowodowało zamieszanie klientów, ponieważ en_US_POSIX nie obsługuje operacji sortowania/wyszukiwania bez uwzględniania wielkości liter. Ponieważ ustawienia regionalne "C" są używane jako domyślne ustawienia regionalne w niektórych dystrybucjach systemu Linux, klienci doświadczyli tego niepożądanego zachowania w tych systemach operacyjnych.

Wprowadzona wersja

3.0

Nic bardziej szczegółowego niż świadomość tej zmiany. Ta zmiana dotyczy tylko aplikacji korzystających z mapowania ustawień regionalnych "C".

Kategoria

Globalizacja

Dotyczy interfejsów API

Ta zmiana ma wpływ na wszystkie interfejsy API sortowania i kultury.

MSBuild

Zmiana nazwy pliku manifestu zasobu

Począwszy od platformy .NET Core 3.0, w domyślnym przypadku program MSBuild generuje inną nazwę pliku manifestu dla plików zasobów.

Wprowadzona wersja

3.0

Opis zmiany

Przed programem .NET Core 3.0, jeśli dla elementu w pliku projektu nie LogicalNameokreślono EmbeddedResource żadnych metadanych lub DependentUpon , ManifestResourceNameprogram MSBuild wygenerował nazwę pliku manifestu we wzorcu <RootNamespace>.<ResourceFilePathFromProjectRoot>.resources. Jeśli RootNamespace plik projektu nie jest zdefiniowany, wartość domyślna to nazwa projektu. Na przykład wygenerowana nazwa manifestu dla pliku zasobu o nazwie Form1.resx w katalogu głównym projektu to MyProject.Form1.resources.

Począwszy od platformy .NET Core 3.0, jeśli plik zasobu jest kolokowany z plikiem źródłowym o tej samej nazwie (na przykład Form1.resx i Form1.cs), program MSBuild używa informacji o typie z pliku źródłowego w celu wygenerowania nazwy pliku manifestu we wzorcu <Namespace>.<ClassName>.resources. Przestrzeń nazw i nazwa klasy są wyodrębniane z pierwszego typu w kolokowanym pliku źródłowym. Na przykład wygenerowana nazwa manifestu dla pliku zasobu o nazwie Form1.resx , który jest współlokowany z plikiem źródłowym o nazwie Form1.cs to MyNamespace.Form1.resources. Należy pamiętać, że pierwsza część nazwy pliku różni się od wcześniejszych wersji platformy .NET Core (MyNamespace zamiast MyProject).

Uwaga

Jeśli masz LogicalNamemetadane , ManifestResourceNamelub DependentUpon określone w elemencie EmbeddedResource w pliku projektu, ta zmiana nie ma wpływu na ten plik zasobu.

Ta zmiana powodująca niezgodność została wprowadzona wraz z dodatkami EmbeddedResourceUseDependentUponConvention właściwości do projektów platformy .NET Core. Domyślnie pliki zasobów nie są jawnie wyświetlane w pliku projektu platformy .NET Core, dlatego nie DependentUpon mają żadnych metadanych, aby określić, jak nazwać wygenerowany plik resources . Gdy EmbeddedResourceUseDependentUponConvention jest ustawiona wartość true, która jest wartością domyślną, program MSBuild wyszukuje kolokowany plik źródłowy i wyodrębnia przestrzeń nazw i nazwę klasy z tego pliku. Jeśli ustawiono EmbeddedResourceUseDependentUponConventionfalsewartość , program MSBuild generuje nazwę manifestu zgodnie z poprzednim zachowaniem, które łączy RootNamespace i względną ścieżkę pliku.

W większości przypadków nie jest wymagana żadna akcja ze strony dewelopera, a aplikacja powinna nadal działać. Jeśli jednak ta zmiana ulegnie awarii aplikacji, możesz wykonać następujące czynności:

  • Zmień kod, aby oczekiwał nowej nazwy manifestu.

  • Zrezygnuj z nowej konwencji nazewnictwa, ustawiając wartość EmbeddedResourceUseDependentUponConvention na false w pliku projektu.

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

Kategoria

MSBuild

Dotyczy interfejsów API

Nie dotyczy

Sieć

Wartość domyślna httpRequestMessage.Version została zmieniona na 1.1

Wartość System.Net.Http.HttpRequestMessage.Version domyślna właściwości zmieniła się z 2.0 na 1.1.

Wprowadzona wersja

3.0

Opis zmiany

W programie .NET Core od 1.0 do 2.0 wartość System.Net.Http.HttpRequestMessage.Version domyślna właściwości to 1.1. Począwszy od platformy .NET Core 2.1, została zmieniona na 2.1.

Począwszy od platformy .NET Core 3.0, domyślny numer wersji zwracany przez System.Net.Http.HttpRequestMessage.Version właściwość to po raz kolejny 1.1.

Zaktualizuj kod, jeśli zależy to od System.Net.Http.HttpRequestMessage.Version właściwości zwracającej wartość domyślną 2.0.

Kategoria

Sieć

Dotyczy interfejsów API

Zobacz też