Szkolenie
Moduł
Dowiedz się, jak dodać uwierzytelnianie i autoryzację do aplikacji internetowej platformy .NET przy użyciu platformy ASP.NET Core Identity.
Ta przeglądarka nie jest już obsługiwana.
Przejdź na przeglądarkę Microsoft Edge, aby korzystać z najnowszych funkcji, aktualizacji zabezpieczeń i pomocy technicznej.
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ę.
Przestarzałe elementy członkowskie i przełączniki zgodności w systemie ASP.NET Core 2.2 zostały usunięte.
3.0
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.
ASP.NET Core
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.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.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.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
Microsoft.AspNetCore.Mvc.LocalRedirectResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.RedirectResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.RedirectToActionResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.RedirectToPageResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.RedirectToRouteResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder.BindModelAsync(ActionContext,IValueProvider,ParameterDescriptor)
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.
3.0
Objęte interfejsy API są oznaczone modyfikatorem public
dostępu i istnieją w *.Internal
przestrzeniach nazw.
Objęte interfejsy API są oznaczone modyfikatorem dostępu wewnętrznego i nie mogą być już używane przez kod poza tym zestawem.
Wskazówki dotyczące tych "pubternal" interfejsów API były następujące:
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();
ASP.NET Core
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
Firma Google zaczyna zamykać logowanie Google+ dla aplikacji już 28 stycznia 2019 r.
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.
Wszystkie wersje. Ta zmiana jest zewnętrzna dla ASP.NET Core.
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.
Ś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 .
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.
Ś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();
ASP.NET Core
Microsoft.AspNetCore.Authentication.Google
Właściwość przestarzała Authentication
HttpContext
została usunięta.
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.
3.0
interfejsy API platformy ASP.NET Core 1.0 zostały zastąpione metodami rozszerzeń w programie Microsoft.AspNetCore.Authentication.AuthenticationHttpContextExtensions.
Zobacz przewodnik migracji.
ASP.NET Core
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:
Aby uzyskać więcej informacji, zobacz dotnet/aspnetcore#7105. Aby zapoznać się z dyskusją, zobacz dotnet/aspnetcore#7289.
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:
ClaimAction.Run(JsonElement userData, ClaimsIdentity identity, string issuer)
Wszystkie pochodne implementacje ClaimAction
programu mają podobny wpływ.MapCustomJson(this ClaimActionCollection collection, string claimType, Func<JsonElement, string> resolver)
MapCustomJson(this ClaimActionCollection collection, string claimType, string valueType, Func<JsonElement, string> resolver)
JObject
elementem JsonElement
. Właściwość User
i RunClaimActions
metoda zostały zaktualizowane w celu dopasowania.JsonDocument
zamiast JObject
. Właściwość została zaktualizowana tak, aby była zgodna Response
. OAuthTokenResponse
jest teraz jednorazowy i będzie usuwany przez OAuthHandler
program . Implementacje ExchangeCodeAsync
pochodnego uwierzytelniania OAuth nie muszą usuwać elementu JsonDocument
lub OAuthTokenResponse
.JObject
na JsonDocument
.JObject
na JsonElement
.JObject
na JsonElement
. Metoda zastępcza to TwitterHandler.CreateTicketAsync(ClaimsIdentity, AuthenticationProperties, AccessToken, JsonElement).ASP.NET Core
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; }
3.0
Ciągi code
i redirectUri
zostały przekazane jako oddzielne argumenty.
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.ExchangeCodeAsync
elementu .
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.
ASP.NET Core
OAuthHandler<TOptions>.ExchangeCodeAsync(String, String)
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).
3.0
AddAuthorization
metody istniały w systemie Microsoft.AspNetCore.Authorization
.
AddAuthorization
metody istnieją w systemie Microsoft.AspNetCore.Authorization.Policy
. AddAuthorizationCore
to nowa nazwa starych metod.
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
.
ASP.NET Core
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.
3.0
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.
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.
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.
ASP.NET Core
Brak
W ASP.NET Core 3.0 dodano nową GetFallbackPolicyAsync
metodę do IAuthorizationPolicyProvider
metody . 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.
3.0
Implementacje metody nie wymagały IAuthorizationPolicyProvider
GetFallbackPolicyAsync
metody.
Implementacje IAuthorizationPolicyProvider
metody wymagają GetFallbackPolicyAsync
metody.
Do użycia AuthorizationMiddleware
nowej metody potrzebna była nowa metoda, gdy nie określono żadnych zasad.
Dodaj metodę GetFallbackPolicyAsync
do implementacji elementu IAuthorizationPolicyProvider
.
ASP.NET Core
Microsoft.AspNetCore.Authorization.IAuthorizationPolicyProvider
Wersja ASP.NET Core 3.0 usunęła przestarzałe interfejsy API MemoryCacheOptions.
Ta zmiana jest kontynuacją pliku aspnet/Caching#221. Aby zapoznać się z dyskusją, zobacz dotnet/extensions#1062.
3.0
MemoryCacheOptions.CompactOnMemoryPressure
właściwość była dostępna.
Właściwość została usunięta MemoryCacheOptions.CompactOnMemoryPressure
.
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.
ASP.NET Core
MemoryCacheOptions.CompactOnMemoryPressure
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.
3.0
Pakiet Microsoft.Extensions.Caching.SqlServer
użył System.Data.SqlClient
pakietu.
Microsoft.Extensions.Caching.SqlServer
program korzysta teraz z Microsoft.Data.SqlClient
pakietu.
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. Na przykład jeśli ktoś rzutował element DbConnection
na stary typ SqlConnection, musiałby zmienić rzutowanie na nowy Microsoft.Data.SqlClient.SqlConnection
typ.
ASP.NET Core
Brak
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 .
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.
3.0
Te typy były widoczne publicznie, ale nieobsługiwane.
Te typy są teraz internal
.
Zakres internal
lepiej odzwierciedla nieobsługiwane zasady.
Kopiowanie typów używanych przez aplikację lub bibliotekę.
ASP.NET Core
Microsoft.AspNetCore.ResponseCaching.Internal.CachedResponse
Microsoft.AspNetCore.ResponseCaching.Internal.CachedVaryByRules
Microsoft.AspNetCore.ResponseCaching.Internal.IResponseCache
Microsoft.AspNetCore.ResponseCaching.Internal.IResponseCacheEntry
Microsoft.AspNetCore.ResponseCaching.Internal.IResponseCachingKeyProvider
Microsoft.AspNetCore.ResponseCaching.Internal.IResponseCachingPolicyProvider
Microsoft.AspNetCore.ResponseCaching.Internal.MemoryResponseCache
Microsoft.AspNetCore.ResponseCaching.Internal.ResponseCachingContext
Microsoft.AspNetCore.ResponseCaching.Internal.ResponseCachingKeyProvider
Microsoft.AspNetCore.ResponseCaching.Internal.ResponseCachingPolicyProvider
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.
3.0
Pakiet odwołuje się do WindowsAzure.Storage
pakietu NuGet.
Pakiet odwołuje się do Microsoft.Azure.Storage.Blob
pakietu NuGet.
Pakiet odwołuje się do Azure.Storage.Blob
pakietu NuGet.
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;
ASP.NET Core
Brak
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.
3.0
Program ANCM V1 jest dołączony do pakietu hostingu systemu Windows.
Program ANCM V1 nie jest uwzględniony w pakiecie hostingu systemu Windows.
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:
<AspNetCoreModuleName>AspNetCoreModule</AspNetCoreModuleName>
programem .<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
ASP.NET Core
Brak
Jedynymi typami host ogólny obsługuje Startup
iniekcję konstruktora klasy to IHostEnvironment
, IWebHostEnvironment
i IConfiguration
. Nie ma to wpływu na aplikacje korzystające z usługi WebHost
.
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:
ASP.NET Core 3.0:
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
, IWebHostEnvironment
i IConfiguration
można wstrzykiwać. Ta zmiana uniemożliwia problemy z di, takie jak zduplikowane tworzenie pojedynczej usługi.
3.0
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)
ASP.NET Core
Brak
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.
3.0
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.
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.
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ć:
ASPNETCORE_HTTPS_PORT
zmiennej środowiskowej na odpowiedni numer portu (443 w większości scenariuszy produkcyjnych).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.
ASP.NET Core
HttpsPolicyBuilderExtensions.UseHttpsRedirection(IApplicationBuilder)
Wprowadzono nowe typy, aby zastąpić istniejące IHostingEnvironment
i IApplicationLifetime
typy.
3.0
Istnieją dwa różne IHostingEnvironment
typy i IApplicationLifetime
od Microsoft.Extensions.Hosting
i Microsoft.AspNetCore.Hosting
.
Stare typy zostały oznaczone jako przestarzałe i zastąpione nowymi typami.
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.Hosting
programu . 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:
Microsoft.AspNetCore.Hosting.IWebHostEnvironment : IHostEnvironment
Nowe IHostEnvironment
IsDevelopment
metody i IsProduction
rozszerzenia znajdują się w Microsoft.Extensions.Hosting
przestrzeni nazw. Może być konieczne dodanie tej przestrzeni nazw do projektu.
ASP.NET Core
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.
3.0
WebHostBuilder
domyślnie w ObjectPoolProvider
kontenerze DI.
WebHostBuilder
Kontener DI nie jest już domyślnie dostępny ObjectPoolProvider
.
Ta zmiana została wprowadzona, aby ASP.NET Core płacić za grę.
Jeśli składnik wymaga ObjectPoolProvider
polecenia , należy go dodać do zależności za pośrednictwem elementu IServiceCollection
.
ASP.NET Core
Brak
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.
3.0
Klasy mogą pochodzić z klasy DefaultHttpContext
.
Klasy nie mogą pochodzić z klasy DefaultHttpContext
.
Rozszerzalność została udostępniona początkowo w celu umożliwienia HttpContext
tworzenia 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>
.
ASP.NET Core
Microsoft.AspNetCore.Http.DefaultHttpContext
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.
3.0
Te pola były używane jako const
.
Te pola są teraz static readonly
.
Zmiana:
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ć:
case
Jako instrukcja w instrukcji switch
const
Aby obejść zmianę powodującą niezgodność, przejdź do używania stałych nazwy nagłówka zdefiniowanego samodzielnie lub literałów ciągu.
ASP.NET Core
Microsoft.Net.Http.Headers.HeaderNames
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.Features
elementu .
3.0
Wystąpiły trzy interfejsy API skojarzone z treścią odpowiedzi HTTP:
IHttpResponseFeature.Body
IHttpSendFileFeature.SendFileAsync
IHttpBufferingFeature.DisableResponseBuffering
Jeśli zastąpisz HttpResponse.Body
element , 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.
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
, IHttpSendFileFeature
lub IHttpBufferingFeature
.
ASP.NET Core
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.
3.0
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.
Wszystkie interfejsy API, których dotyczy problem, domyślnie mają wartość SameSiteMode.None
.
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.
ASP.NET Core
Począwszy od ASP.NET Core 3.0, operacje synchroniczne serwera są domyślnie wyłączone.
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.Write
i 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:
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 Dispose
programie , wywołaj nowy DisposeAsync
interfejs API.
Aby zapoznać się z dyskusją, zobacz dotnet/aspnetcore#7644.
3.0
HttpRequest.Body.Read
, HttpResponse.Body.Write
i Stream.Flush
były domyślnie dozwolone.
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.
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;
}
ASP.NET Core
Począwszy od ASP.NET Core 3.0, przeciążenie metody IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework) już nie istnieje.
3.0
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>
ASP.NET Core
IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework)
Począwszy od ASP.NET Core 3.0, interfejs użytkownika tożsamości domyślnie używa wersji 4 bootstrap.
3.0
Wywołanie services.AddDefaultIdentity<IdentityUser>().AddDefaultUI();
metody było takie samo jak services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap3);
Wywołanie services.AddDefaultIdentity<IdentityUser>().AddDefaultUI();
metody jest takie samo jak services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap4);
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);
ASP.NET Core
Brak
Domyślnie SignInAsync
zgłasza wyjątek dla podmiotów zabezpieczeń/tożsamości, w których IsAuthenticated
jest .false
3.0
SignInAsync
akceptuje wszystkie podmioty zabezpieczeń/tożsamości, w tym tożsamości, w których IsAuthenticated
jest .false
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.
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 RequireAuthenticatedSignIn
AuthenticationOptions
true
. Ustaw tę flagę, aby false
przywrócić stare zachowanie.
ASP.NET Core
Brak
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.
3.0
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ę SignInManager
IUserConfirmation
lub pobierz jedną z iniekcji zależności, aby zapewnić.
ASP.NET Core
ASP.NET Core 3.0 wprowadziła funkcję statycznych zasobów internetowych, a interfejs użytkownika tożsamości go przyjął.
W wyniku interfejsu użytkownika tożsamości przyjmującej funkcję statycznych zasobów internetowych:
IdentityUIFrameworkVersion
właściwości w pliku projektu.3.0
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
.
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.
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>
ASP.NET Core
IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder, UIFramework)
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łączeń 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.
3.0
Składniki rozszerzalności Kestrel zostały utworzone przy użyciu polecenia IConnectionAdapter
.
Składniki rozszerzalności Kestrel są tworzone jako oprogramowanie pośredniczące.
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.
ASP.NET Core
Microsoft.AspNetCore.Server.Kestrel.Core.Adapter.Internal.IConnectionAdapter
Zestaw Microsoft.AspNetCore.Server.Kestrel.Https został usunięty.
3.0
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.
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.Microsoft.AspNetCore.Server.Kestrel.Https
pakietu NuGet.ASP.NET Core
Brak
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.
3.0
Do kolekcji zostaną dodane nagłówki zwiastuna HttpRequest.Headers
żądania.
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.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.
ASP.NET Core
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.
3.0
Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions
.ListenOptions.NoDelay
była dostępna.IConnectionListener
został wprowadzony w Microsoft.AspNetCore.Connections.Abstractions
bibliotece, aby uwidocznić najczęściej używane funkcje z ...Transport.Abstractions
biblioteki.NoDelay
jest teraz dostępny w opcjach transportu (LibuvTransportOptions
i SocketTransportOptions
).SchedulingMode
program nie jest już dostępny.ASP.NET Core 3.0 odeszła od interfejsów API "pubternal".
ASP.NET Core
Brak
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 ASP.NET Core 3.0. 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.
3.0
Metody nie zostały oznaczone jako Obsolete
.
Metody są oznaczone jako Obsolete
.
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 CurrentCulture
przez element . Jeśli nie jest to opcja, utwórz i użyj kopii elementu ResourceManagerWithCultureStringLocalizer.
ASP.NET Core
Microsoft.Extensions.Localization.ResourceManagerWithCultureStringLocalizer
Microsoft.Extensions.Localization.ResourceManagerStringLocalizer.WithCulture
Przed ASP.NET Core 3.0 DebugLogger
modyfikator dostępu to public
. W ASP.NET Core 3.0 modyfikator dostępu zmienił się na internal
.
3.0
Zmiana jest wprowadzana w następujących zmianami:
ConsoleLogger
.AddDebug ILoggingBuilder
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.
ASP.NET Core
Microsoft.Extensions.Logging.Debug.DebugLogger
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.
3.0
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>
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.ConfigureServices
pliku MvcOptions.SuppressAsyncSuffixInActionNames
false
:
services.AddMvc(options =>
{
options.SuppressAsyncSuffixInActionNames = false;
});
Zgodnie z konwencją Async
metody 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:
[ActionName]
aby zachować oryginalną nazwę.MvcOptions.SuppressAsyncSuffixInActionNames
false
:Startup.ConfigureServices
services.AddMvc(options =>
{
options.SuppressAsyncSuffixInActionNames = false;
});
ASP.NET Core
Brak
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.
3.0 (wersja zapoznawcza 6)
Aplikacja korzystająca z biblioteki opartej na wersji 2.2 została pomyślnie skompilowanych.
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.
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.
ASP.NET Core
Microsoft.AspNetCore.Mvc.JsonResult
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.
3.0
Pakiet Microsoft.AspNetCore.Mvc.Razor.ViewCompilation
został użyty do wstępnie skompilowania widoków MVC Razor.
Zestaw SDK Razor natywnie obsługuje tę funkcję. Pakiet Microsoft.AspNetCore.Mvc.Razor.ViewCompilation
nie jest już aktualizowany.
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.
ASP.NET Core
Brak
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.
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.
3.0
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ść.
Wszystkie takie typy są aktualizowane tak, aby były public
w obsługiwanej przestrzeni nazw lub oznaczone jako internal
.
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 public
można wziąć pod uwagę następujące kwestie: .
ASP.NET Core
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
Począwszy od ASP.NET Core 3.0, Microsoft.AspNetCore.Mvc.WebApiCompatShim
pakiet nie jest już dostępny.
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.
3.0
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.
ASP.NET Core
Microsoft.AspNetCore.Mvc.WebApiCompatShim
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.
3.0
Aparat szablonu można utworzyć i użyć do analizowania i generowania kodu dla plików Razor.
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.
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.
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
});
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();
ASP.NET Core
RazorTemplateEngine
RazorTemplateEngineOptions
Obsługa kompilacji w czasie wykonywania widoków Razor i stron Razor została przeniesiona do oddzielnego pakietu.
3.0
Kompilacja środowiska uruchomieniowego jest dostępna bez konieczności używania dodatkowych pakietów.
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.
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:
Dodaj odwołanie do Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation
pakietu.
Zaktualizuj metodę projektu Startup.ConfigureServices
, aby uwzględnić wywołanie metody AddRazorRuntimeCompilation
. Na przykład:
services.AddMvc()
.AddRazorRuntimeCompilation();
ASP.NET Core
Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions
Usunięto przestarzałe interfejsy API do konfigurowania plików cookie sesji. Aby uzyskać więcej informacji, zobacz aspnet/Announcements#257.
3.0
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;
});
}
ASP.NET Core
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.
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
.
3.0
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:
Newtonsoft.Json
)Microsoft.EntityFrameworkCore.
)Microsoft.CodeAnalysis
)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.
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).Microsoft.AspNetCore.App
. Na przykład następujące składniki są dostępne jako pakiety NuGet: 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.
ASP.NET Core
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.
3.0
Aplikacje mogą używać Microsoft.AspNetCore.All
metapakiet do określania docelowej platformy udostępnionej Microsoft.AspNetCore.All
na platformie .NET Core.
Platforma .NET Core 3.0 nie zawiera struktury udostępnionej Microsoft.AspNetCore.All
.
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.
ASP.NET Core
Brak
Pole HandshakeProtocol.SuccessHandshakeData zostało usunięte i zastąpione metodą pomocnika, która generuje pomyślną odpowiedź uzgadniania na podstawie określonego IHubProtocol
elementu .
3.0
HandshakeProtocol.SuccessHandshakeData
był polem public static ReadOnlyMemory<byte>
.
HandshakeProtocol.SuccessHandshakeData
został zastąpiony przez metodę static
GetSuccessfulHandshake(IHubProtocol protocol)
, która zwraca ReadOnlyMemory<byte>
element na podstawie określonego protokołu.
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. public
Jest 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.
ASP.NET Core
HandshakeProtocol.SuccessHandshakeData
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.
3.0
Dostępne były interfejsy API.
Interfejsy API są usuwane.
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.
ASP.NET Core
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.
3.0
HubConnectionContext
ma dwa konstruktory:
public HubConnectionContext(ConnectionContext connectionContext, TimeSpan keepAliveInterval, ILoggerFactory loggerFactory);
public HubConnectionContext(ConnectionContext connectionContext, TimeSpan keepAliveInterval, ILoggerFactory loggerFactory, TimeSpan clientTimeoutInterval);
Dwa konstruktory zostały usunięte i zastąpione jednym konstruktorem:
public HubConnectionContext(ConnectionContext connectionContext, HubConnectionContextOptions contextOptions, ILoggerFactory loggerFactory)
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);
ASP.NET Core
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.
3.0
Pakiet klienta nosił nazwę @aspnet/signalr
.
Pakiet klienta ma nazwę @microsoft/signalr
.
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
.
ASP.NET Core
Brak
Metody UseConnections
i UseSignalR
klasy ConnectionsRouteBuilder
i HubRouteBuilder
są oznaczone jako przestarzałe w ASP.NET Core 3.0.
3.0
Routing koncentratora usługi SignalR został skonfigurowany przy użyciu polecenia UseSignalR
lub UseConnections
.
Stary sposób konfigurowania routingu został przestarzały i zastąpiony routingiem punktów końcowych.
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");
});
ASP.NET Core
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.
3.0
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.
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.
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:
Jeśli używasz tych pakietów, zaktualizuj aplikacje, aby korzystały z funkcji:
Microsoft.AspNetCore.SpaServices.Extensions
.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.
ASP.NET Core
Microsoft.AspNetCore.NodeServices.HostingModels.INodeInstance
Microsoft.AspNetCore.NodeServices.HostingModels.NodeInvocationException
Microsoft.AspNetCore.NodeServices.HostingModels.NodeInvocationInfo
Microsoft.AspNetCore.NodeServices.HostingModels.NodeServicesOptionsExtensions
Microsoft.AspNetCore.NodeServices.HostingModels.OutOfProcessNodeInstance
Microsoft.AspNetCore.SpaServices.Prerendering.ISpaPrerenderer
Microsoft.AspNetCore.SpaServices.Prerendering.ISpaPrerendererBuilder
Microsoft.AspNetCore.SpaServices.Prerendering.JavaScriptModuleExport
Microsoft.AspNetCore.SpaServices.Prerendering.PrerenderTagHelper
Microsoft.AspNetCore.SpaServices.Prerendering.RenderToStringResult
Microsoft.AspNetCore.SpaServices.Webpack.WebpackDevMiddlewareOptions
Microsoft.Extensions.DependencyInjection.NodeServicesServiceCollectionExtensions
Microsoft.Extensions.DependencyInjection.PrerenderingServiceCollectionExtensions
Microsoft.AspNetCore.SpaServices i Microsoft.AspNetCore.NodeServices nie będzie wyświetlać dzienników konsoli, chyba że rejestrowanie jest skonfigurowane.
3.0
Microsoft.AspNetCore.SpaServices
i Microsoft.AspNetCore.NodeServices
służy do automatycznego tworzenia rejestratora konsoli, gdy rejestrowanie nie jest skonfigurowane.
Microsoft.AspNetCore.SpaServices
i Microsoft.AspNetCore.NodeServices
nie będzie wyświetlać dzienników konsoli, chyba że rejestrowanie jest skonfigurowane.
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 .
ASP.NET Core
Brak
Począwszy od platformy ASP.NET Core 3.0, platforma .NET Framework jest nieobsługiwaną platformą docelową.
.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.
3.0
aplikacje ASP.NET Core mogą działać na platformie .NET Core lub .NET Framework.
aplikacje ASP.NET Core można uruchamiać tylko na platformie .NET Core.
Przeprowadź jedną z następujących czynności:
ASP.NET Core
Brak
Wiele interfejsów API, które zwracają wersje na platformie .NET Core, zwraca teraz wersję produktu, a nie wersję pliku.
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.
3.0
Brak. Ta zmiana powinna sprawić, że wykrywanie wersji powinno być intuicyjne, a nie zatusze.
Podstawowe biblioteki platformy .NET
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.
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:
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.
Podstawowe biblioteki platformy .NET
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
.
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 .
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.
Podstawowe biblioteki platformy .NET
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.
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.
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.IsInfinity Double.IsInfinity element ma true
wartość .
W kodzie przyjęto założenie, że wartości zmiennoprzecinkowe nie Infinity
są . W takim przypadku należy dodać niezbędny kod, aby sprawdzić wartości PositiveInfinity
zmiennoprzecinkowe i NegativeInfinity
.
Podstawowe biblioteki platformy .NET
Klasa została przeniesiona InvalidAsynchronousStateException .
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 .
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.
Podstawowe biblioteki platformy .NET
Brak.
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.
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: true
polecenia , 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.
3.0
Ze strony dewelopera nie jest wymagana żadna akcja.
Podstawowe biblioteki platformy .NET
Klasa została przeniesiona TypeDescriptionProviderAttribute .
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 .
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.
Windows Forms
Brak.
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.
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.
3.0
Zapakuj ponownie wszelkie archiwum zip, które wykazuje te problemy.
Podstawowe biblioteki platformy .NET
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.
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.
Porada
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.
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.
Podstawowe biblioteki platformy .NET
Podczas wywoływania metody rozszerzenia, która przyjmuje IEnumerable<T>
element na GroupCollectionobiekcie , należy uściślić typ przy użyciu rzutowania.
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.
3.0
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);
Podstawowe biblioteki platformy .NET
Dotyczy to dowolnej metody rozszerzenia, która akceptuje IEnumerable<T> element . Na przykład:
System.Linq.Enumerable
Większość metod, na przykład,System.Linq.Enumerable.CountCertyfikaty 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.
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).
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
Kryptografia
Domyślny algorytm szyfrowania symetrycznego używany przez EnvelopedCms
program został zmieniony z TripleDES na AES-256.
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();
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();
Kryptografia
Minimalny rozmiar generowania nowych kluczy RSA w systemie Linux wzrósł z 384-bitowego do 512-bitowego.
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.
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.
Kryptografia
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.
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.
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.
Kryptografia
Metoda CryptoStream.Dispose , która służy do kończenie CryptoStream
operacji, nie próbuje już przekształcić końcowego bloku podczas odczytywania.
Jeśli w poprzednich wersjach platformy .NET użytkownik wykonał niekompletne odczyty w CryptoStream Read 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.
Ta zmiana umożliwia niekompletne odczyty ze strumienia kryptograficznego po anulowaniu operacji sieciowej bez konieczności przechwytywania wyjątku.
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.
Kryptografia
Zmiany powodujące niezgodność w programie Entity Framework Core
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.
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.
3.0
Nic bardziej szczegółowego niż świadomość tej zmiany. Ta zmiana dotyczy tylko aplikacji korzystających z mapowania ustawień regionalnych "C".
Globalizacja
Ta zmiana ma wpływ na wszystkie interfejsy API sortowania i kultury.
Począwszy od platformy .NET Core 3.0, w domyślnym przypadku program MSBuild generuje inną nazwę pliku manifestu dla plików zasobów.
3.0
Przed programem .NET Core 3.0, jeśli dla elementu w pliku projektu nie LogicalName
określono EmbeddedResource
żadnych metadanych lub DependentUpon
, ManifestResourceName
program 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 LogicalName
metadane , ManifestResourceName
lub 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 EmbeddedResourceUseDependentUponConvention
false
wartość , 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>
MSBuild
Nie dotyczy
Wartość System.Net.Http.HttpRequestMessage.Version domyślna właściwości zmieniła się z 2.0 na 1.1.
3.0
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.
Sieć
Program .NET Core 3.0 wprowadził zmianę sposobu tworzenia System.Windows.DataObject kontrolki edytora tekstu podczas przeciągania tekstu do innej kontrolki. Zmiana wyłączyła autokonwersję, powodując, że operacja zachowuje dane jako DataFormats.Text lub DataFormats.UnicodeText zamiast konwertować je na DataFormats.StringFormat.
.NET Core 3.0
Windows Presentation Foundation
Typ danych podczas System.Windows.DataObject przeciągania tekstu z kontrolki edytora tekstu to DataFormats.StringFormat.
Typ danych podczas System.Windows.DataObject przeciągania tekstu z kontrolki edytora tekstu to DataFormats.Text lub DataFormats.UnicodeText.
Ta zmiana jest zmianą behawioralną.
Zmiana była niezamierzona.
Ta zmiana została przywrócona na platformie .NET 7. Uaktualnij do platformy .NET 7 lub nowszej.
Opinia o produkcie .NET
.NET to projekt typu open source. Wybierz link, aby przekazać opinię:
Szkolenie
Moduł
Dowiedz się, jak dodać uwierzytelnianie i autoryzację do aplikacji internetowej platformy .NET przy użyciu platformy ASP.NET Core Identity.
Dokumentacja
Istotne zmiany w programie .NET Core 3.1 - .NET
Wyświetla listę zmian powodujących niezgodność w wersji 3.1 platformy .NET Core i ASP.NET Core.
Zmiany powodujące niezgodność na platformie .NET 6
Przejdź do zmian powodujących niezgodność na platformie .NET 6.
Dowiedz się więcej o zmianach powodujących niezgodność w systemie ASP.NET Core 6.0, w których niektóre zestawy zostały usunięte z platformy udostępnionej Microsoft.AspNetCore.App.