Bagikan melalui

Memutus perubahan di .NET Core 3.0

  • Artikel

Jika Anda bermigrasi ke .NET Core, ASP.NET Core, atau EF Core versi 3.0, atau EF Core, perubahan mencolok yang tercantum dalam artikel ini dapat memengaruhi aplikasi Anda.

Inti ASP.NET

API Antiforgery, CORS, Diagnostik, MVC, dan Perutean usang dihapus

Anggota usang dan sakelar kompatibilitas di ASP.NET Core 2.2 dihapus.

Versi yang diperkenalkan

3.0

Alasan untuk berubah

Peningkatan permukaan API dari waktu ke waktu.

Saat menargetkan .NET Core 2.2, ikuti panduan dalam pesan build usang untuk mengadopsi API baru sebagai gantinya.

Kategori

Inti ASP.NET

API yang Terpengaruh

Jenis dan anggota berikut ditandai sebagai usang untuk ASP.NET Core 2.1 dan 2.2:

Jenis

  • 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

Konstruktor

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

Properti

  • 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

Metode

API "Pubternal" dihapus

Untuk mempertahankan permukaan API publik ASP.NET Core dengan lebih baik, sebagian besar jenis di *.Internal namespace (disebut sebagai "pubternal" API) telah menjadi benar-benar internal. Anggota di namespace layanan ini tidak pernah dimaksudkan untuk didukung sebagai API yang menghadap publik. API dapat rusak dalam rilis kecil dan sering dilakukan. Kode yang bergantung pada API ini berhenti saat memperbarui ke ASP.NET Core 3.0.

Untuk informasi selengkapnya, lihat dotnet/aspnetcore#4932 dan dotnet/aspnetcore#11312.

Versi yang diperkenalkan

3.0

Perilaku yang lama

API yang terpengaruh ditandai dengan pengubah public akses dan ada di *.Internal namespace.

Perilaku yang baru

API yang terpengaruh ditandai dengan pengubah akses internal dan tidak dapat lagi digunakan oleh kode di luar rakitan tersebut.

Alasan untuk berubah

Panduan untuk API ini "pubternal" adalah bahwa mereka:

  • Bisa berubah tanpa pemberitahuan.
  • Tidak tunduk pada kebijakan .NET untuk mencegah perubahan yang melanggar.

Meninggalkan API public (bahkan di *.Internal namespace layanan) membingungkan pelanggan.

Berhenti menggunakan API ini "pubternal" . Jika Anda memiliki pertanyaan tentang API alternatif, buka masalah di repositori dotnet/aspnetcore .

Misalnya, pertimbangkan kode buffering permintaan HTTP berikut dalam proyek ASP.NET Core 2.2. Metode EnableRewind ekstensi ada di Microsoft.AspNetCore.Http.Internal namespace.

HttpContext.Request.EnableRewind();

Dalam proyek ASP.NET Core 3.0, ganti EnableRewind panggilan dengan panggilan ke EnableBuffering metode ekstensi. Fitur buffering permintaan berfungsi seperti yang terjadi di masa lalu. EnableBuffering memanggil API sekarang internal .

HttpContext.Request.EnableBuffering();

Kategori

Inti ASP.NET

API yang Terpengaruh

Semua API di Microsoft.AspNetCore.* namespace layanan dan Microsoft.Extensions.* yang memiliki Internal segmen dalam nama namespace. Contohnya:

  • 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

Autentikasi: Google+ tidak digunakan lagi dan diganti

Google mulai mematikan Proses Masuk Google+ untuk aplikasi pada 28 Januari 2019.

Deskripsi perubahan

ASP.NET 4.x dan ASP.NET Core telah menggunakan API Masuk Google+ untuk mengautentikasi pengguna akun Google di aplikasi web. Paket NuGet yang terpengaruh adalah Microsoft.AspNetCore.Authentication.Google untuk ASP.NET Core dan Microsoft.Owin.Security.Google untuk Microsoft.Owin dengan ASP.NET Web Forms dan MVC.

API pengganti Google menggunakan sumber dan format data yang berbeda. Mitigasi dan solusi yang disediakan di bawah ini memperhitungkan perubahan struktural. Aplikasi harus memverifikasi data itu sendiri masih memenuhi persyaratannya. Misalnya, nama, alamat email, tautan profil, dan foto profil dapat memberikan nilai yang sangat berbeda dari sebelumnya.

Versi yang diperkenalkan

Semua versi. Perubahan ini eksternal untuk ASP.NET Core.

Owin dengan ASP.NET Web Forms dan MVC

Untuk Microsoft.Owin 3.1.0 dan yang lebih baru, mitigasi sementara diuraikan di sini. Aplikasi harus menyelesaikan pengujian dengan mitigasi untuk memeriksa perubahan dalam format data. Ada rencana untuk merilis Microsoft.Owin 4.0.1 dengan perbaikan. Aplikasi yang menggunakan versi sebelumnya harus diperbarui ke versi 4.0.1.

ASP.NET Core 1.x

Mitigasi di Owin dengan ASP.NET Web Forms dan MVC dapat disesuaikan dengan ASP.NET Core 1.x. Patch paket NuGet tidak direncanakan karena 1.x telah mencapai status akhir masa pakai .

ASP.NET Core 2.x

Untuk Microsoft.AspNetCore.Authentication.Google versi 2.x, ganti panggilan yang sudah ada dengan AddGoogle Startup.ConfigureServices kode berikut:

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

Patch 2.1 dan 2.2 Februari menggabungkan konfigurasi ulang sebelumnya sebagai default baru. Tidak ada patch yang direncanakan untuk ASP.NET Core 2.0 karena telah mencapai akhir masa pakai.

ASP.NET Core 3.0

Mitigasi yang diberikan untuk ASP.NET Core 2.x juga dapat digunakan untuk ASP.NET Core 3.0. Dalam pratinjau 3.0 di masa mendatang, Microsoft.AspNetCore.Authentication.Google paket dapat dihapus. Pengguna akan diarahkan ke Microsoft.AspNetCore.Authentication.OpenIdConnect sebagai gantinya. Kode berikut menunjukkan cara mengganti AddGoogle dengan AddOpenIdConnect di Startup.ConfigureServices. Penggantian ini dapat digunakan dengan ASP.NET Core 2.0 dan yang lebih baru dan dapat disesuaikan untuk ASP.NET Core 1.x sesuai kebutuhan.

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

Kategori

Inti ASP.NET

API yang Terpengaruh

Microsoft.AspNetCore.Authentication.Google

Autentikasi: Properti HttpContext.Authentication dihapus

Properti HttpContext yang tidak digunakan Authentication lagi telah dihapus.

Deskripsi perubahan

Sebagai bagian dari dotnet/aspnetcore#6504, properti yang tidak digunakan lagi Authentication pada HttpContext telah dihapus. Properti Authentication tidak digunakan lagi sejak 2.0. Panduan migrasi diterbitkan untuk memigrasikan kode menggunakan properti yang tidak digunakan lagi ini ke API pengganti baru. Kelas /API yang tidak digunakan yang tersisa yang terkait dengan tumpukan autentikasi ASP.NET Core 1.x lama dihapus dalam penerapan dotnet/aspnetcore@d7a7c65.

Untuk diskusi, lihat dotnet/aspnetcore#6533.

Versi yang diperkenalkan

3.0

Alasan untuk berubah

ASP.NET API Core 1.0 telah digantikan oleh metode ekstensi di Microsoft.AspNetCore.Authentication.AuthenticationHttpContextExtensions.

Lihat panduan migrasi.

Kategori

Inti ASP.NET

API yang Terpengaruh

Autentikasi: Jenis Newtonsoft.Json diganti

Dalam ASP.NET Core 3.0, Newtonsoft.Json jenis yang digunakan dalam API Autentikasi telah diganti dengan System.Text.Json jenis. Kecuali untuk kasus berikut, penggunaan dasar paket Autentikasi tetap tidak terpengaruh:

  • Kelas yang berasal dari penyedia OAuth, seperti dari aspnet-contrib.
  • Implementasi manipulasi klaim tingkat lanjut.

Untuk informasi selengkapnya, lihat dotnet/aspnetcore#7105. Untuk diskusi, lihat dotnet/aspnetcore#7289.

Versi yang diperkenalkan

3.0

Untuk implementasi OAuth turunan, perubahan yang paling umum adalah mengganti JObject.Parse dengan JsonDocument.Parse dalam penimpaan seperti yang CreateTicketAsync ditunjukkan di sini. JsonDocument penerapan IDisposable.

Daftar berikut menguraikan perubahan yang diketahui:

Kategori

Inti ASP.NET

API yang Terpengaruh

Autentikasi: Tanda tangan OAuthHandler ExchangeCodeAsync berubah

Dalam ASP.NET Core 3.0, tanda tangan OAuthHandler.ExchangeCodeAsync diubah dari:

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

Kepada:

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

Versi yang diperkenalkan

3.0

Perilaku yang lama

String code dan redirectUri diteruskan sebagai argumen terpisah.

Perilaku yang baru

Code dan RedirectUri merupakan properti pada OAuthCodeExchangeContext yang dapat diatur melalui OAuthCodeExchangeContext konstruktor. Jenis baru OAuthCodeExchangeContext adalah satu-satunya argumen yang diteruskan ke OAuthHandler.ExchangeCodeAsync.

Alasan untuk berubah

Perubahan ini memungkinkan parameter tambahan disediakan dengan cara yang tidak melanggar. Tidak perlu membuat kelebihan beban baru ExchangeCodeAsync .

Buat OAuthCodeExchangeContext dengan nilai dan redirectUri yang sesuaicode. Instans AuthenticationProperties harus disediakan. Instans tunggal OAuthCodeExchangeContext ini dapat diteruskan ke OAuthHandler.ExchangeCodeAsync alih-alih beberapa argumen.

Kategori

Inti ASP.NET

API yang Terpengaruh

OAuthHandler<TOptions>.ExchangeCodeAsync(String, String)

Otorisasi: AddAuthorization overload dipindahkan ke rakitan yang berbeda

Metode inti AddAuthorization yang digunakan untuk tinggal diganti Microsoft.AspNetCore.Authorization namanya menjadi AddAuthorizationCore. Metode lama AddAuthorization masih ada, tetapi berada di perakitan Microsoft.AspNetCore.Authorization.Policy sebagai gantinya. Aplikasi yang menggunakan kedua metode tidak akan melihat dampak apa pun. Perhatikan bahwa sekarang dikirim dalam kerangka kerja bersama daripada paket mandiri seperti yang Microsoft.AspNetCore.Authorization.Policy dibahas dalam Kerangka kerja bersama: Rakitan dihapus dari Microsoft.AspNetCore.App.

Versi yang diperkenalkan

3.0

Perilaku yang lama

AddAuthorization metode ada di Microsoft.AspNetCore.Authorization.

Perilaku yang baru

AddAuthorization metode ada di Microsoft.AspNetCore.Authorization.Policy. AddAuthorizationCore adalah nama baru untuk metode lama.

Alasan untuk berubah

AddAuthorization adalah nama metode yang lebih baik untuk menambahkan semua layanan umum yang diperlukan untuk otorisasi.

Tambahkan referensi ke Microsoft.AspNetCore.Authorization.Policy atau gunakan AddAuthorizationCore sebagai gantinya.

Kategori

Inti ASP.NET

API yang Terpengaruh

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

Otorisasi: IAllowAnonymous dihapus dari AuthorizationFilterContext.Filters

Pada ASP.NET Core 3.0, MVC tidak menambahkan AllowAnonymousFilters untuk atribut [AllowAnonymous] yang ditemukan pada pengontrol dan metode tindakan. Perubahan ini ditangani secara lokal untuk turunan dari AuthorizeAttribute, tetapi ini adalah perubahan yang melanggar untuk IAsyncAuthorizationFilter implementasi dan IAuthorizationFilter . Implementasi tersebut dibungkus dalam atribut [TypeFilter] adalah cara yang populer dan didukung untuk mencapai otorisasi berbasis atribut yang sangat ditik ketika konfigurasi dan injeksi dependensi diperlukan.

Versi yang diperkenalkan

3.0

Perilaku yang lama

IAllowAnonymous muncul di koleksi AuthorizationFilterContext.Filters . Pengujian untuk kehadiran antarmuka adalah pendekatan yang valid untuk mengambil alih atau menonaktifkan filter pada metode pengontrol individual.

Perilaku yang baru

IAllowAnonymous tidak lagi muncul dalam AuthorizationFilterContext.Filters koleksi. IAsyncAuthorizationFilter implementasi yang bergantung pada perilaku lama biasanya menyebabkan respons HTTP 401 Tidak Sah atau HTTP 403 Terlarang.

Alasan untuk berubah

Strategi perutean titik akhir baru diperkenalkan di ASP.NET Core 3.0.

Cari metadata titik akhir untuk IAllowAnonymous. Contohnya:

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

Contoh teknik ini terlihat dalam metode HasAllowAnonymous ini.

Kategori

Inti ASP.NET

API yang Terpengaruh

Tidak

Otorisasi: Implementasi IAuthorizationPolicyProvider memerlukan metode baru

Dalam ASP.NET Core 3.0, metode baru GetFallbackPolicyAsync ditambahkan ke IAuthorizationPolicyProvider. Kebijakan fallback ini digunakan oleh middleware otorisasi ketika tidak ada kebijakan yang ditentukan.

Untuk informasi selengkapnya, lihat dotnet/aspnetcore#9759.

Versi yang diperkenalkan

3.0

Perilaku yang lama

IAuthorizationPolicyProvider Implementasi tidak memerlukan GetFallbackPolicyAsync metode.

Perilaku yang baru

IAuthorizationPolicyProvider Implementasi memerlukan GetFallbackPolicyAsync metode.

Alasan untuk berubah

Metode baru diperlukan agar baru AuthorizationMiddleware digunakan ketika tidak ada kebijakan yang ditentukan.

GetFallbackPolicyAsync Tambahkan metode ke implementasi Anda dari IAuthorizationPolicyProvider.

Kategori

Inti ASP.NET

API yang Terpengaruh

Microsoft.AspNetCore.Authorization.IAuthorizationPolicyProvider

Penembolokan: Properti CompactOnMemoryPressure dihapus

Rilis ASP.NET Core 3.0 menghapus API MemoryCacheOptions usang.

Deskripsi perubahan

Perubahan ini adalah tindak lanjut aspnet /Caching#221. Untuk diskusi, lihat dotnet/extensions#1062.

Versi yang diperkenalkan

3.0

Perilaku yang lama

MemoryCacheOptions.CompactOnMemoryPressure properti tersedia.

Perilaku yang baru

Properti MemoryCacheOptions.CompactOnMemoryPressure telah dihapus.

Alasan untuk berubah

Memampatkan cache secara otomatis menyebabkan masalah. Untuk menghindari perilaku tak terduga, cache hanya boleh dipadatkan saat diperlukan.

Untuk memampatkan cache, downcast ke MemoryCache dan panggil Compact saat diperlukan.

Kategori

Inti ASP.NET

API yang Terpengaruh

MemoryCacheOptions.CompactOnMemoryPressure

Penembolokan: Microsoft.Extensions.Caching.SqlServer menggunakan paket SqlClient baru

Paket Microsoft.Extensions.Caching.SqlServer akan menggunakan paket baru Microsoft.Data.SqlClient alih-alih System.Data.SqlClient paket. Perubahan ini dapat menyebabkan sedikit perubahan pemecahan perilaku. Untuk informasi selengkapnya, lihat Memperkenalkan Microsoft.Data.SqlClient baru.

Versi yang diperkenalkan

3.0

Perilaku yang lama

Paket menggunakan Microsoft.Extensions.Caching.SqlServer System.Data.SqlClient paket.

Perilaku yang baru

Microsoft.Extensions.Caching.SqlServer sekarang menggunakan Microsoft.Data.SqlClient paket.

Alasan untuk berubah

Microsoft.Data.SqlClient adalah paket baru yang dibangun dari System.Data.SqlClient. Di sinilah semua pekerjaan fitur baru akan dilakukan mulai sekarang.

Pelanggan tidak perlu khawatir tentang perubahan yang melanggar ini kecuali mereka menggunakan jenis yang dikembalikan oleh Microsoft.Extensions.Caching.SqlServer paket dan mentransmisikannya ke System.Data.SqlClient jenis. Misalnya, jika seseorang mentransmisikan DbConnection ke jenis SqlConnection lama, mereka perlu mengubah cast ke jenis baru Microsoft.Data.SqlClient.SqlConnection .

Kategori

Inti ASP.NET

API yang Terpengaruh

Tidak

Penembolokan: Jenis "pubternal" ResponseCaching berubah menjadi internal

Dalam ASP.NET Core 3.0, jenis "pubternal" di ResponseCaching telah diubah menjadi internal.

Selain itu, implementasi default dan IResponseCachingPolicyProvider IResponseCachingKeyProvider tidak lagi ditambahkan ke layanan sebagai bagian AddResponseCaching dari metode .

Deskripsi perubahan

Dalam ASP.NET Core, jenis "pubternal" dinyatakan sebagai public tetapi berada di namespace yang diaffiks dengan .Internal. Meskipun jenis ini bersifat publik, mereka tidak memiliki kebijakan dukungan dan tunduk pada perubahan yang melanggar. Sayangnya, penggunaan yang tidak disengaja dari jenis ini telah umum, mengakibatkan perubahan yang melanggar pada proyek-proyek ini dan membatasi kemampuan untuk mempertahankan kerangka kerja.

Versi yang diperkenalkan

3.0

Perilaku yang lama

Jenis ini terlihat secara publik, tetapi tidak didukung.

Perilaku yang baru

Jenis-jenis ini sekarang internal.

Alasan untuk berubah

Cakupan internal lebih mencerminkan kebijakan yang tidak didukung.

Salin jenis yang digunakan oleh aplikasi atau pustaka Anda.

Kategori

Inti ASP.NET

API yang Terpengaruh

Perlindungan Data: DataProtection.Blobs menggunakan API Azure Storage baru

Azure.Extensions.AspNetCore.DataProtection.Blobs bergantung pada pustaka Azure Storage. Pustaka ini mengganti nama rakitan, paket, dan namespace layanannya. Mulai dari ASP.NET Core 3.0, Azure.Extensions.AspNetCore.DataProtection.Blobs menggunakan API dan paket baru Azure.Storage.yang diawali.

Untuk pertanyaan tentang API Azure Storage, gunakan https://github.com/Azure/azure-storage-net. Untuk diskusi tentang masalah ini, lihat dotnet/aspnetcore#19570.

Versi yang diperkenalkan

3.0

Perilaku yang lama

Paket mereferensikan WindowsAzure.Storage paket NuGet. Paket mereferensikan Microsoft.Azure.Storage.Blob paket NuGet.

Perilaku yang baru

Paket mereferensikan Azure.Storage.Blob paket NuGet.

Alasan untuk berubah

Perubahan ini memungkinkan Azure.Extensions.AspNetCore.DataProtection.Blobs migrasi ke paket Azure Storage yang direkomendasikan.

Jika Anda masih perlu menggunakan API Azure Storage yang lebih lama dengan ASP.NET Core 3.0, tambahkan dependensi langsung ke paket WindowsAzure.Storage atau Microsoft.Azure.Storage. Paket ini dapat diinstal bersama API baru Azure.Storage .

Dalam banyak kasus, peningkatan hanya melibatkan perubahan using pernyataan untuk menggunakan namespace baru:

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

Kategori

Inti ASP.NET

API yang Terpengaruh

Tidak

Hosting: AspNetCoreModule V1 dihapus dari Windows Hosting Bundle

Dimulai dengan ASP.NET Core 3.0, Windows Hosting Bundle tidak akan berisi AspNetCoreModule (ANCM) V1.

ANCM V2 kompatibel dengan ANCM OutOfProcess dan direkomendasikan untuk digunakan dengan aplikasi ASP.NET Core 3.0.

Untuk diskusi, lihat dotnet/aspnetcore#7095.

Versi yang diperkenalkan

3.0

Perilaku yang lama

ANCM V1 disertakan dalam Bundel Hosting Windows.

Perilaku yang baru

ANCM V1 tidak disertakan dalam Windows Hosting Bundle.

Alasan untuk berubah

ANCM V2 kompatibel dengan ANCM OutOfProcess dan direkomendasikan untuk digunakan dengan aplikasi ASP.NET Core 3.0.

Gunakan ANCM V2 dengan aplikasi ASP.NET Core 3.0.

Jika ANCM V1 diperlukan, ANCM V1 dapat diinstal menggunakan Bundel Windows Hosting ASP.NET Core 2.1 atau 2.2.

Perubahan ini akan merusak aplikasi ASP.NET Core 3.0 yang:

  • Secara eksplisit memilih menggunakan ANCM V1 dengan <AspNetCoreModuleName>AspNetCoreModule</AspNetCoreModuleName>.
  • Memiliki file web.config kustom dengan <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />.

Kategori

Inti ASP.NET

API yang Terpengaruh

Tidak

Hosting: Host generik membatasi injeksi konstruktor Startup

Satu-satunya jenis yang didukung host generik untuk Startup injeksi konstruktor kelas adalah IHostEnvironment, , IWebHostEnvironmentdan IConfiguration. Aplikasi yang menggunakan WebHost tidak terpengaruh.

Deskripsi perubahan

Sebelum ASP.NET Core 3.0, injeksi konstruktor dapat digunakan untuk jenis arbitrer di Startup konstruktor kelas. Di ASP.NET Core 3.0, tumpukan web direplatformasi ke pustaka host generik. Anda dapat melihat perubahan dalam file Program.cs templat:

ASP.NET Core 2.x:

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

ASP.NET Core 3.0:

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

Host menggunakan satu kontainer injeksi dependensi (DI) untuk membangun aplikasi. WebHost menggunakan dua kontainer: satu untuk host dan satu untuk aplikasi. Akibatnya, Startup konstruktor tidak lagi mendukung injeksi layanan kustom. Hanya IHostEnvironment, IWebHostEnvironment, dan IConfiguration dapat disuntikkan. Perubahan ini mencegah masalah DI seperti pembuatan duplikat layanan singleton.

Versi yang diperkenalkan

3.0

Alasan untuk berubah

Perubahan ini adalah konsekuensi dari mereplatformasi tumpukan web ke pustaka host generik.

Masukkan layanan ke Startup.Configure dalam tanda tangan metode. Contohnya:

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

Kategori

Inti ASP.NET

API yang Terpengaruh

Tidak

Hosting: Pengalihan HTTPS diaktifkan untuk aplikasi IIS di luar proses

Versi 13.0.19218.0 ASP.NET Core Module (ANCM) untuk hosting melalui IIS di luar proses memungkinkan fitur pengalihan HTTPS yang ada untuk aplikasi ASP.NET Core 3.0 dan 2.2.

Untuk diskusi, lihat dotnet/AspNetCore#15243.

Versi yang diperkenalkan

3.0

Perilaku yang lama

Templat proyek ASP.NET Core 2.1 pertama kali memperkenalkan dukungan untuk metode middleware HTTPS seperti UseHttpsRedirection dan UseHsts. Mengaktifkan pengalihan HTTPS memerlukan penambahan konfigurasi, karena aplikasi dalam pengembangan tidak menggunakan port default 443. HTTP Strict Transport Security (HSTS) hanya aktif jika permintaan sudah menggunakan HTTPS. Localhost dilewati secara default.

Perilaku yang baru

Dalam ASP.NET Core 3.0, skenario HTTPS IIS ditingkatkan. Dengan peningkatan, aplikasi dapat menemukan port HTTPS server dan bekerja UseHttpsRedirection secara default. Penemuan port yang dicapai komponen dalam proses dengan fitur , IServerAddresses yang hanya memengaruhi aplikasi ASP.NET Core 3.0 karena pustaka dalam proses diversi dengan kerangka kerja. Komponen di luar proses berubah untuk secara otomatis menambahkan ASPNETCORE_HTTPS_PORT variabel lingkungan. Perubahan ini memengaruhi aplikasi ASP.NET Core 2.2 dan 3.0 karena komponen di luar proses dibagikan secara global. ASP.NET aplikasi Core 2.1 tidak terpengaruh karena mereka menggunakan versi ANCM sebelumnya secara default.

Perilaku sebelumnya dimodifikasi di ASP.NET Core 3.0.1 dan 3.1.0 Pratinjau 3 untuk membalikkan perubahan perilaku di ASP.NET Core 2.x. Perubahan ini hanya memengaruhi aplikasi IIS di luar proses.

Seperti yang dijelaskan di atas, menginstal ASP.NET Core 3.0.0 memiliki efek samping juga mengaktifkan UseHttpsRedirection middleware di aplikasi ASP.NET Core 2.x. Perubahan dilakukan pada ANCM di ASP.NET Core 3.0.1 dan 3.1.0 Pratinjau 3 sehingga menginstalnya tidak lagi memiliki efek ini pada aplikasi ASP.NET Core 2.x. ASPNETCORE_HTTPS_PORT Variabel lingkungan yang diisi ANCM di ASP.NET Core 3.0.0 diubah menjadi ASPNETCORE_ANCM_HTTPS_PORT di ASP.NET Core 3.0.1 dan 3.1.0 Pratinjau 3. UseHttpsRedirection juga diperbarui dalam rilis ini untuk memahami variabel baru dan lama. ASP.NET Core 2.x tidak akan diperbarui. Akibatnya, ia kembali ke perilaku sebelumnya yang dinonaktifkan secara default.

Alasan untuk berubah

Fungsionalitas ASP.NET Core 3.0 yang disempurnakan.

Tidak ada tindakan yang diperlukan jika Anda ingin semua klien menggunakan HTTPS. Untuk mengizinkan beberapa klien menggunakan HTTP, lakukan salah satu langkah berikut:

  • Hapus panggilan ke UseHttpsRedirection dan UseHsts dari metode proyek Startup.Configure Anda, dan sebarkan ulang aplikasi.

  • Dalam file web.config Anda, atur ASPNETCORE_HTTPS_PORT variabel lingkungan ke string kosong. Perubahan ini dapat terjadi langsung di server tanpa menyebarkan ulang aplikasi. Contohnya:

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

UseHttpsRedirection masih dapat berupa:

  • Diaktifkan secara manual di ASP.NET Core 2.x dengan mengatur ASPNETCORE_HTTPS_PORT variabel lingkungan ke nomor port yang sesuai (443 dalam sebagian besar skenario produksi).
  • Dinonaktifkan di ASP.NET Core 3.x dengan menentukan ASPNETCORE_ANCM_HTTPS_PORT dengan nilai string kosong. Nilai ini diatur dengan cara yang sama dengan contoh sebelumnya ASPNETCORE_HTTPS_PORT .

Komputer yang menjalankan aplikasi ASP.NET Core 3.0.0 harus menginstal runtime ASP.NET Core 3.0.1 sebelum menginstal ASP.NET Core 3.1.0 Pratinjau 3 ANCM. Melakukannya memastikan bahwa terus beroperasi seperti yang UseHttpsRedirection diharapkan untuk aplikasi ASP.NET Core 3.0.

Di Azure App Service, ANCM menyebarkan jadwal terpisah dari runtime karena sifat globalnya. ANCM disebarkan ke Azure dengan perubahan ini setelah ASP.NET Core 3.0.1 dan 3.1.0 disebarkan.

Kategori

Inti ASP.NET

API yang Terpengaruh

HttpsPolicyBuilderExtensions.UseHttpsRedirection(IApplicationBuilder)

Hosting: Jenis IHostingEnvironment dan IApplicationLifetime ditandai usang dan diganti

Jenis baru telah diperkenalkan untuk menggantikan jenis dan IApplicationLifetime yang IHostingEnvironment ada.

Versi yang diperkenalkan

3.0

Perilaku yang lama

Ada dua jenis dan IApplicationLifetime berbeda IHostingEnvironment dari Microsoft.Extensions.Hosting dan Microsoft.AspNetCore.Hosting.

Perilaku yang baru

Jenis lama telah ditandai sebagai usang dan diganti dengan jenis baru.

Alasan untuk berubah

Ketika Microsoft.Extensions.Hosting diperkenalkan di ASP.NET Core 2.1, beberapa jenis seperti IHostingEnvironment dan IApplicationLifetime disalin dari Microsoft.AspNetCore.Hosting. Beberapa perubahan ASP.NET Core 3.0 menyebabkan aplikasi menyertakan Microsoft.Extensions.Hosting namespace layanan dan Microsoft.AspNetCore.Hosting . Setiap penggunaan jenis duplikat tersebut menyebabkan kesalahan kompilator "referensi ambigu" ketika kedua namespace dirujuk.

Ganti penggunaan apa pun dari jenis lama dengan jenis yang baru diperkenalkan seperti di bawah ini:

Jenis usang (peringatan):

Jenis baru:

Metode baru IHostEnvironment IsDevelopment dan IsProduction ekstensi ada di Microsoft.Extensions.Hosting namespace layanan. Namespace layanan tersebut mungkin perlu ditambahkan ke proyek Anda.

Kategori

Inti ASP.NET

API yang Terpengaruh

Hosting: ObjectPoolProvider dihapus dari dependensi WebHostBuilder

Sebagai bagian dari membuat ASP.NET Core lebih membayar untuk bermain, ObjectPoolProvider dihapus dari set dependensi utama. Komponen tertentu yang mengandalkan ObjectPoolProvider sekarang menambahkannya sendiri.

Untuk diskusi, lihat dotnet/aspnetcore#5944.

Versi yang diperkenalkan

3.0

Perilaku yang lama

WebHostBuilder menyediakan ObjectPoolProvider secara default dalam kontainer DI.

Perilaku yang baru

WebHostBuilder tidak lagi menyediakan ObjectPoolProvider secara default dalam kontainer DI.

Alasan untuk berubah

Perubahan ini dilakukan untuk membuat ASP.NET Core lebih membayar untuk bermain.

Jika komponen Anda memerlukan ObjectPoolProvider, komponen perlu ditambahkan ke dependensi Anda melalui IServiceCollection.

Kategori

Inti ASP.NET

API yang Terpengaruh

Tidak

HTTP: Ekstensibilitas DefaultHttpContext dihapus

Sebagai bagian dari peningkatan performa ASP.NET Core 3.0, ekstensibilitas DefaultHttpContext dihapus. Kelas sekarang sealed. Untuk informasi selengkapnya, lihat dotnet/aspnetcore#6504.

Jika pengujian unit Anda menggunakan Mock<DefaultHttpContext>, gunakan Mock<HttpContext> atau new DefaultHttpContext() sebagai gantinya.

Untuk diskusi, lihat dotnet/aspnetcore#6534.

Versi yang diperkenalkan

3.0

Perilaku yang lama

Kelas dapat berasal dari DefaultHttpContext.

Perilaku yang baru

Kelas tidak dapat berasal dari DefaultHttpContext.

Alasan untuk berubah

Ekstensibilitas disediakan awalnya untuk memungkinkan pengumpulan HttpContext, tetapi memperkenalkan kompleksitas yang tidak perlu dan menghambat pengoptimalan lainnya.

Jika Anda menggunakan Mock<DefaultHttpContext> dalam pengujian unit, mulai gunakan Mock<HttpContext> sebagai gantinya.

Kategori

Inti ASP.NET

API yang Terpengaruh

Microsoft.AspNetCore.Http.DefaultHttpContext

HTTP: Konstanta HeaderNames berubah menjadi readonly statis

Mulai ASP.NET Core 3.0 Pratinjau 5, bidang di Microsoft.Net.Http.Headers.HeaderNames diubah dari const ke static readonly.

Untuk diskusi, lihat dotnet/aspnetcore#9514.

Versi yang diperkenalkan

3.0

Perilaku yang lama

Bidang-bidang ini dulunya .const

Perilaku yang baru

Bidang-bidang ini sekarang static readonly.

Alasan untuk berubah

Perubahan:

  • Mencegah nilai disematkan di seluruh batas perakitan, memungkinkan koreksi nilai sesuai kebutuhan.
  • Mengaktifkan pemeriksaan kesetaraan referensi yang lebih cepat.

Kompilasi ulang terhadap 3.0. Kode sumber menggunakan bidang ini dengan cara berikut tidak dapat lagi melakukannya:

  • Sebagai argumen atribut
  • Sebagai dalam case pernyataan switch
  • Saat menentukan yang lain const

Untuk mengatasi perubahan yang melanggar, beralihlah menggunakan konstanta nama header atau literal string yang ditentukan sendiri.

Kategori

Inti ASP.NET

API yang Terpengaruh

Microsoft.Net.Http.Headers.HeaderNames

HTTP: Respons perubahan infrastruktur isi

Infrastruktur yang mendukung isi respons HTTP telah berubah. Jika Anda menggunakan HttpResponse secara langsung, Anda tidak perlu membuat perubahan kode apa pun. Baca lebih lanjut jika Anda membungkus atau mengganti HttpResponse.Body atau mengakses HttpContext.Features.

Versi yang diperkenalkan

3.0

Perilaku yang lama

Ada tiga API yang terkait dengan isi respons HTTP:

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

Perilaku yang baru

Jika Anda mengganti HttpResponse.Body, itu mengganti seluruh IHttpResponseBodyFeature dengan pembungkus di sekitar aliran yang Anda berikan menggunakan StreamResponseBodyFeature untuk memberikan implementasi default untuk semua API yang diharapkan. Mengatur kembali aliran asli mengembalikan perubahan ini.

Alasan untuk berubah

Motivasinya adalah menggabungkan API isi respons menjadi satu antarmuka fitur baru.

Gunakan IHttpResponseBodyFeature tempat Anda sebelumnya menggunakan IHttpResponseFeature.Body, , IHttpSendFileFeatureatau IHttpBufferingFeature.

Kategori

Inti ASP.NET

API yang Terpengaruh

SameSite adalah opsi untuk cookie yang dapat membantu mengurangi beberapa serangan Pemalsuan Permintaan Lintas Situs (CSRF). Ketika opsi ini awalnya diperkenalkan, default yang tidak konsisten digunakan di berbagai API Inti ASP.NET. Inkonsistensi telah menyebabkan hasil yang membingungkan. Pada ASP.NET Core 3.0, default ini lebih selaras. Anda harus ikut serta dalam fitur ini berdasarkan per komponen.

Versi yang diperkenalkan

3.0

Perilaku yang lama

API ASP.NET Core serupa menggunakan nilai default SameSiteMode yang berbeda. Contoh inkonsistensi terlihat di HttpResponse.Cookies.Append(String, String) dan HttpResponse.Cookies.Append(String, String, CookieOptions), yang secara default ke SameSiteMode.None dan SameSiteMode.Lax, masing-masing.

Perilaku yang baru

Semua API yang terpengaruh default ke SameSiteMode.None.

Alasan untuk berubah

Nilai default diubah untuk membuat SameSite fitur keikutsertaan.

Setiap komponen yang memancarkan cookie perlu memutuskan apakah SameSite sesuai untuk skenarionya. Tinjau penggunaan API yang terpengaruh dan konfigurasi SameSite ulang sesuai kebutuhan.

Kategori

Inti ASP.NET

API yang Terpengaruh

HTTP: IO sinkron dinonaktifkan di semua server

Dimulai dengan ASP.NET Core 3.0, operasi server sinkron dinonaktifkan secara default.

Deskripsi perubahan

AllowSynchronousIO adalah opsi di setiap server yang mengaktifkan atau menonaktifkan API IO sinkron seperti HttpRequest.Body.Read, , HttpResponse.Body.Writedan Stream.Flush. API ini telah lama menjadi sumber kelaparan utas dan aplikasi macet. Mulai ASP.NET Core 3.0 Pratinjau 3, operasi sinkron ini dinonaktifkan secara default.

Server yang terpengaruh:

  • Kestrel
  • HttpSys
  • IIS sedang dalam proses
  • TestServer

Mengharapkan kesalahan yang mirip dengan:

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

Setiap server memiliki AllowSynchronousIO opsi yang mengontrol perilaku ini dan default untuk semuanya sekarang falseadalah .

Perilaku ini juga dapat ditimpa berdasarkan per permintaan sebagai mitigasi sementara. Contohnya:

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

Jika Anda mengalami masalah dengan aliran lain yang TextWriter memanggil API sinkron di Dispose, panggil API baru DisposeAsync sebagai gantinya.

Untuk diskusi, lihat dotnet/aspnetcore#7644.

Versi yang diperkenalkan

3.0

Perilaku yang lama

HttpRequest.Body.Read, HttpResponse.Body.Write, dan Stream.Flush diizinkan secara default.

Perilaku yang baru

API sinkron ini tidak diizinkan secara default:

Mengharapkan kesalahan yang mirip dengan:

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

Alasan untuk berubah

API sinkron ini telah lama menjadi sumber kelaparan utas dan aplikasi macet. Mulai ASP.NET Core 3.0 Pratinjau 3, operasi sinkron dinonaktifkan secara default.

Gunakan versi asinkron metode. Perilaku ini juga dapat ditimpa berdasarkan per permintaan sebagai mitigasi sementara.

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

Kategori

Inti ASP.NET

API yang Terpengaruh

Identitas: AddDefaultUI metode overload dihapus

Dimulai dengan ASP.NET Core 3.0, metode IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework) tidak lagi ada.

Versi yang diperkenalkan

3.0

Alasan untuk berubah

Perubahan ini adalah hasil adopsi fitur aset web statis.

Panggil IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder) alih-alih kelebihan beban yang mengambil dua argumen. Jika Anda menggunakan Bootstrap 3, tambahkan juga baris berikut ke <PropertyGroup> elemen dalam file proyek Anda:

<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>

Kategori

Inti ASP.NET

API yang Terpengaruh

IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework)

Identitas: Versi Bootstrap default antarmuka pengguna berubah

Mulai ASP.NET Core 3.0, Antarmuka Pengguna Identitas default menggunakan Bootstrap versi 4.

Versi yang diperkenalkan

3.0

Perilaku yang lama

Panggilan services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(); metode sama dengan services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap3);

Perilaku yang baru

Panggilan services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(); metode sama dengan services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap4);

Alasan untuk berubah

Bootstrap 4 dirilis selama jangka waktu ASP.NET Core 3.0.

Anda terpengaruh oleh perubahan ini jika Anda menggunakan UI Identitas default dan telah menambahkannya seperti yang ditunjukkan Startup.ConfigureServices dalam contoh berikut:

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

Ikuti salah satu tindakan berikut:

  • Migrasikan aplikasi Anda untuk menggunakan Bootstrap 4 menggunakan panduan migrasi mereka.

  • Perbarui Startup.ConfigureServices untuk memberlakukan penggunaan Bootstrap 3. Contohnya:

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

Kategori

Inti ASP.NET

API yang Terpengaruh

Tidak

Identitas: SignInAsync memunculkan pengecualian untuk identitas yang tidak diaturentikasi

Secara default, SignInAsync melemparkan pengecualian untuk prinsipal / identitas di mana IsAuthenticated adalah false.

Versi yang diperkenalkan

3.0

Perilaku yang lama

SignInAsync menerima prinsipal / identitas apa pun, termasuk identitas di mana IsAuthenticated adalah false.

Perilaku yang baru

Secara default, SignInAsync melemparkan pengecualian untuk prinsipal / identitas di mana IsAuthenticated adalah false. Ada bendera baru untuk menekan perilaku ini, tetapi perilaku default telah berubah.

Alasan untuk berubah

Perilaku lama bermasalah karena, secara default, prinsipal ini ditolak oleh [Authorize] / RequireAuthenticatedUser().

Di ASP.NET Core 3.0 Pratinjau 6, ada RequireAuthenticatedSignIn bendera pada AuthenticationOptions yang secara true default. Atur bendera ini ke false untuk memulihkan perilaku lama.

Kategori

Inti ASP.NET

API yang Terpengaruh

Tidak

Identitas: Konstruktor SignInManager menerima parameter baru

Dimulai dengan ASP.NET Core 3.0, parameter baru IUserConfirmation<TUser> ditambahkan ke SignInManager konstruktor. Untuk informasi selengkapnya, lihat dotnet/aspnetcore#8356.

Versi yang diperkenalkan

3.0

Alasan untuk berubah

Motivasi untuk perubahan adalah menambahkan dukungan untuk alur email/ konfirmasi baru di Identitas.

Jika membangun secara SignInManagermanual , berikan implementasi atau ambil dari IUserConfirmation injeksi dependensi untuk disediakan.

Kategori

Inti ASP.NET

API yang Terpengaruh

SignInManager<TUser>

Identitas: UI menggunakan fitur aset web statis

ASP.NET Core 3.0 memperkenalkan fitur aset web statis, dan Antarmuka Pengguna Identitas telah mengadopsinya.

Deskripsi perubahan

Sebagai hasil dari Antarmuka Pengguna Identitas yang mengadopsi fitur aset web statis:

  • Pemilihan kerangka kerja dilakukan dengan menggunakan IdentityUIFrameworkVersion properti dalam file proyek Anda.
  • Bootstrap 4 adalah kerangka kerja UI default untuk Antarmuka Pengguna Identitas. Bootstrap 3 telah mencapai akhir masa pakai, dan Anda harus mempertimbangkan untuk bermigrasi ke versi yang didukung.

Versi yang diperkenalkan

3.0

Perilaku yang lama

Kerangka kerja UI default untuk Antarmuka Pengguna Identitas adalah Bootstrap 3. Kerangka kerja UI dapat dikonfigurasi menggunakan parameter untuk AddDefaultUI panggilan metode di Startup.ConfigureServices.

Perilaku yang baru

Kerangka kerja UI default untuk Antarmuka Pengguna Identitas adalah Bootstrap 4. Kerangka kerja UI harus dikonfigurasi dalam file proyek Anda, bukan dalam AddDefaultUI panggilan metode.

Alasan untuk berubah

Adopsi fitur aset web statis mengharuskan konfigurasi kerangka kerja UI pindah ke MSBuild. Keputusan kerangka kerja mana yang akan disematkan adalah keputusan build-time, bukan keputusan runtime.

Tinjau UI situs Anda untuk memastikan komponen Bootstrap 4 baru kompatibel. Jika perlu, gunakan IdentityUIFrameworkVersion properti MSBuild untuk kembali ke Bootstrap 3. Tambahkan properti ke <PropertyGroup> elemen dalam file proyek Anda:

<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>

Kategori

Inti ASP.NET

API yang Terpengaruh

IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder, UIFramework)

Kestrel: Adaptor koneksi dihapus

Sebagai bagian dari langkah untuk memindahkan API "pubternal" ke public, konsep dihapus IConnectionAdapter dari Kestrel. Adaptor koneksi diganti dengan middleware koneksi (mirip dengan middleware HTTP di alur ASP.NET Core, tetapi untuk koneksi tingkat bawah). HTTPS dan pengelogan koneksi telah berpindah dari adaptor koneksi ke middleware koneksi. Metode ekstensi tersebut harus terus bekerja dengan mulus, tetapi detail implementasi telah berubah.

Untuk informasi selengkapnya, lihat dotnet/aspnetcore#11412. Untuk diskusi, lihat dotnet/aspnetcore#11475.

Versi yang diperkenalkan

3.0

Perilaku yang lama

Komponen ekstensibilitas Kestrel dibuat menggunakan IConnectionAdapter.

Perilaku yang baru

Komponen ekstensibilitas kestrel dibuat sebagai middleware.

Alasan untuk berubah

Perubahan ini dimaksudkan untuk memberikan arsitektur ekstensibilitas yang lebih fleksibel.

Konversikan implementasi IConnectionAdapter apa pun untuk menggunakan pola middleware baru seperti yang ditunjukkan di sini.

Kategori

Inti ASP.NET

API yang Terpengaruh

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

Kestrel: rakitan HTTPS kosong dihapus

Rakitan Microsoft.AspNetCore.Server.Kestrel.Https telah dihapus.

Versi yang diperkenalkan

3.0

Alasan untuk berubah

Dalam ASP.NET Core 2.1, konten Microsoft.AspNetCore.Server.Kestrel.Https dipindahkan ke Microsoft.AspNetCore.Server.Kestrel.Core. Perubahan ini dilakukan dengan cara yang tidak melanggar menggunakan [TypeForwardedTo] atribut.

  • Pustaka yang merujuk Microsoft.AspNetCore.Server.Kestrel.Https 2.0 harus memperbarui semua dependensi inti ASP.NET ke 2.1 atau yang lebih baru. Jika tidak, mereka dapat pecah saat dimuat ke dalam aplikasi ASP.NET Core 3.0.
  • Aplikasi dan pustaka yang menargetkan ASP.NET Core 2.1 dan yang lebih baru harus menghapus referensi langsung apa pun ke Microsoft.AspNetCore.Server.Kestrel.Https paket NuGet.

Kategori

Inti ASP.NET

API yang Terpengaruh

Tidak

Kestrel: Meminta header trailer dipindahkan ke koleksi baru

Dalam versi sebelumnya, Kestrel menambahkan header trailer terpotong HTTP/1.1 ke dalam koleksi header permintaan saat isi permintaan dibaca ke akhir. Perilaku ini menyebabkan kekhawatiran tentang ambiguitas antara header dan trailer. Keputusan tersebut dibuat untuk memindahkan trailer ke koleksi baru.

Trailer permintaan HTTP/2 tidak tersedia di ASP.NET Core 2.2 tetapi sekarang juga tersedia dalam koleksi baru ini di ASP.NET Core 3.0.

Metode ekstensi permintaan baru telah ditambahkan untuk mengakses trailer ini.

Trailer HTTP/1.1 tersedia setelah seluruh isi permintaan dibaca.

Trailer HTTP/2 tersedia setelah diterima dari klien. Klien tidak akan mengirim trailer sampai seluruh isi permintaan setidaknya di-buffer oleh server. Anda mungkin perlu membaca isi permintaan untuk membebaskan ruang buffer. Trailer selalu tersedia jika Anda membaca isi permintaan ke akhir. Trailer menandai akhir tubuh.

Versi yang diperkenalkan

3.0

Perilaku yang lama

Header trailer permintaan akan ditambahkan ke HttpRequest.Headers koleksi.

Perilaku yang baru

Header trailer permintaan tidak ada dalam HttpRequest.Headers koleksi. Gunakan metode ekstensi berikut untuk HttpRequest mengaksesnya:

  • GetDeclaredTrailers() - Mendapatkan header "Trailer" permintaan yang mencantumkan trailer mana yang diharapkan setelah isi.
  • SupportsTrailers() - Menunjukkan apakah permintaan mendukung penerimaan header trailer.
  • CheckTrailersAvailable() - Menentukan apakah permintaan mendukung trailer dan apakah mereka tersedia untuk dibaca.
  • GetTrailer(string trailerName) - Mendapatkan header berikutnya yang diminta dari respons.

Alasan untuk berubah

Trailer adalah fitur utama dalam skenario seperti gRPC. Menggabungkan trailer ke header permintaan membingungkan bagi pengguna.

Gunakan metode HttpRequest ekstensi terkait trailer untuk mengakses trailer.

Kategori

Inti ASP.NET

API yang Terpengaruh

HttpRequest.Headers

Kestrel: Abstraksi transportasi dihapus dan dipublikasikan

Sebagai bagian dari menjauh dari API "pubternal", API lapisan transportasi Kestrel diekspos sebagai antarmuka publik di Microsoft.AspNetCore.Connections.Abstractions pustaka.

Versi yang diperkenalkan

3.0

Perilaku yang lama

  • Abstraksi terkait transportasi tersedia di Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions pustaka.
  • Properti ListenOptions.NoDelay tersedia.

Perilaku yang baru

  • Antarmuka IConnectionListener diperkenalkan di Microsoft.AspNetCore.Connections.Abstractions pustaka untuk mengekspos fungsionalitas yang paling banyak digunakan dari ...Transport.Abstractions pustaka.
  • sekarang NoDelay tersedia dalam opsi transportasi (LibuvTransportOptions dan SocketTransportOptions).
  • SchedulingMode tidak lagi tersedia.

Alasan untuk berubah

ASP.NET Core 3.0 telah pindah dari API "pubternal".

Kategori

Inti ASP.NET

API yang Terpengaruh

Tidak

Pelokalan: ResourceManagerWithCultureStringLocalizer dan WithCulture ditandai usang

Kelas ResourceManagerWithCultureStringLocalizer dan anggota antarmuka WithCulture sering menjadi sumber kebingungan bagi pengguna pelokalan, terutama saat membuat implementasi mereka sendiri IStringLocalizer . Item ini memberi pengguna kesan bahwa IStringLocalizer instans adalah "per bahasa, per sumber daya". Pada kenyataannya, instans hanya boleh "per sumber daya". Bahasa yang dicari ditentukan oleh pada CultureInfo.CurrentUICulture waktu eksekusi. Untuk menghilangkan sumber kebingungan, API ditandai sebagai usang di ASP.NET Core 3.0. API akan dihapus dalam rilis mendatang.

Untuk konteksnya, lihat dotnet/aspnetcore#3324. Untuk diskusi, lihat dotnet/aspnetcore#7756.

Versi yang diperkenalkan

3.0

Perilaku yang lama

Metode tidak ditandai sebagai Obsolete.

Perilaku yang baru

Metode ditandai Obsolete.

Alasan untuk berubah

API mewakili kasus penggunaan yang tidak disarankan. Ada kebingungan tentang desain pelokalan.

Rekomendasinya adalah menggunakan ResourceManagerStringLocalizer sebagai gantinya. Biarkan budaya diatur oleh CurrentCulture. Jika itu bukan opsi, buat dan gunakan salinan ResourceManagerWithCultureStringLocalizer.

Kategori

Inti ASP.NET

API yang Terpengaruh

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

Pengelogan: Kelas DebugLogger dibuat internal

Sebelum ASP.NET Core 3.0, DebugLoggerpengubah akses adalah public. Di ASP.NET Core 3.0, pengubah akses berubah menjadi internal.

Versi yang diperkenalkan

3.0

Alasan untuk berubah

Perubahan sedang dilakukan pada:

  • Terapkan konsistensi dengan implementasi pencatat lainnya seperti ConsoleLogger.
  • Kurangi permukaan API.

AddDebug ILoggingBuilder Gunakan metode ekstensi untuk mengaktifkan pengelogan debug. DebugLoggerProvider juga masih public dalam hal layanan perlu didaftarkan secara manual.

Kategori

Inti ASP.NET

API yang Terpengaruh

Microsoft.Extensions.Logging.Debug.DebugLogger

MVC: Akhiran asinkron dipangkas dari nama tindakan pengontrol

Sebagai bagian dari mengatasi dotnet/aspnetcore#4849, ASP.NET Core MVC memangkas akhiran Async dari nama tindakan secara default. Dimulai dengan ASP.NET Core 3.0, perubahan ini memengaruhi pembuatan perutean dan tautan.

Versi yang diperkenalkan

3.0

Perilaku yang lama

Pertimbangkan pengontrol MVC Inti ASP.NET berikut:

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

Tindakan ini dapat dirutekan melalui Product/ListAsync. Pembuatan tautan memerlukan penentuan akhiran Async . Contohnya:

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

Perilaku yang baru

Dalam ASP.NET Core 3.0, tindakan dapat dirutekan melalui Product/List. Kode pembuatan tautan harus menghilangkan akhiran Async . Contohnya:

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

Perubahan ini tidak memengaruhi nama yang ditentukan menggunakan [ActionName] atribut . Perilaku baru dapat dinonaktifkan dengan mengatur MvcOptions.SuppressAsyncSuffixInActionNames ke false di Startup.ConfigureServices:

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

Alasan untuk berubah

Menurut konvensi, metode .NET asinkron dicukupkan dengan Async. Namun, ketika metode mendefinisikan tindakan MVC, tidak diinginkan untuk menggunakan akhiran Async .

Jika aplikasi Anda bergantung pada tindakan MVC yang mempertahankan akhiran nama Async , pilih salah satu mitigasi berikut:

  • [ActionName] Gunakan atribut untuk mempertahankan nama asli.
  • Nonaktifkan penggantian nama sepenuhnya dengan mengatur MvcOptions.SuppressAsyncSuffixInActionNames ke false di Startup.ConfigureServices:
services.AddMvc(options =>
{
   options.SuppressAsyncSuffixInActionNames = false;
});

Kategori

Inti ASP.NET

API yang Terpengaruh

Tidak

MVC: JsonResult dipindahkan ke Microsoft.AspNetCore.Mvc.Core

JsonResult telah pindah ke assembly Microsoft.AspNetCore.Mvc.Core . Jenis ini digunakan untuk didefinisikan dalam Microsoft.AspNetCore.Mvc.Formatters.Json. Atribut tingkat rakitan [TypeForwardedTo] ditambahkan untuk Microsoft.AspNetCore.Mvc.Formatters.Json mengatasi masalah ini bagi sebagian besar pengguna. Aplikasi yang menggunakan pustaka pihak ketiga mungkin mengalami masalah.

Versi yang diperkenalkan

3.0 Pratinjau 6

Perilaku yang lama

Aplikasi yang menggunakan build pustaka berbasis 2.2 berhasil dibuat.

Perilaku yang baru

Aplikasi yang menggunakan pustaka berbasis 2.2 gagal kompilasi. Kesalahan yang berisi variasi teks berikut disediakan:

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'

Untuk contoh masalah seperti itu, lihat dotnet/aspnetcore#7220.

Alasan untuk berubah

Perubahan tingkat platform pada komposisi ASP.NET Core seperti yang dijelaskan di aspnet/Pengumuman#325.

Pustaka yang dikompilasi terhadap versi Microsoft.AspNetCore.Mvc.Formatters.Json 2.2 mungkin perlu dikompilasi ulang untuk mengatasi masalah bagi semua konsumen. Jika terpengaruh, hubungi penulis pustaka. Minta kompilasi ulang pustaka untuk menargetkan ASP.NET Core 3.0.

Kategori

Inti ASP.NET

API yang Terpengaruh

Microsoft.AspNetCore.Mvc.JsonResult

MVC: Alat kompilasi tidak digunakan lagi

Dalam ASP.NET Core 1.1, Microsoft.AspNetCore.Mvc.Razor.ViewCompilation paket (alat prakompemasi MVC) diperkenalkan untuk menambahkan dukungan untuk kompilasi file Razor (file.cshtml ) waktu publik. Dalam ASP.NET Core 2.1, Razor SDK diperkenalkan untuk memperluas fitur alat prakompilasi. Razor SDK menambahkan dukungan untuk kompilasi build dan publish-time file Razor. SDK memverifikasi kebenaran file .cshtml pada waktu build sambil meningkatkan waktu mulai aplikasi. Razor SDK aktif secara default, dan tidak ada gerakan yang diperlukan untuk mulai menggunakannya.

Dalam ASP.NET Core 3.0, alat prakompekulasi MVC era ASP.NET Core 1.1 dihapus. Versi paket sebelumnya akan terus menerima perbaikan bug dan keamanan penting dalam rilis patch.

Versi yang diperkenalkan

3.0

Perilaku yang lama

Paket ini Microsoft.AspNetCore.Mvc.Razor.ViewCompilation digunakan untuk pra-kompilasi tampilan MVC Razor.

Perilaku yang baru

Razor SDK secara asli mendukung fungsionalitas ini. Paket Microsoft.AspNetCore.Mvc.Razor.ViewCompilation tidak lagi diperbarui.

Alasan untuk berubah

Razor SDK menyediakan lebih banyak fungsionalitas dan memverifikasi kebenaran file .cshtml pada waktu build. SDK juga meningkatkan waktu pengaktifan aplikasi.

Untuk pengguna ASP.NET Core 2.1 atau yang lebih baru, perbarui untuk menggunakan dukungan asli untuk kompilasi sebelumnya di Razor SDK. Jika bug atau fitur yang hilang mencegah migrasi ke Razor SDK, buka masalah di dotnet/aspnetcore.

Kategori

Inti ASP.NET

API yang Terpengaruh

Tidak

MVC: Jenis "Pubternal" berubah menjadi internal

Dalam ASP.NET Core 3.0, semua jenis "pubternal" di MVC diperbarui agar berada public di namespace yang didukung atau internal yang sesuai.

Deskripsi perubahan

Dalam ASP.NET Core, jenis "pubternal" dinyatakan sebagai public tetapi berada di .Internalnamespace layanan -akhiran. Meskipun jenis ini adalah public, mereka tidak memiliki kebijakan dukungan dan tunduk pada perubahan yang melanggar. Sayangnya, penggunaan yang tidak disengaja dari jenis ini telah umum, mengakibatkan perubahan yang melanggar pada proyek-proyek ini dan membatasi kemampuan untuk mempertahankan kerangka kerja.

Versi yang diperkenalkan

3.0

Perilaku yang lama

Beberapa jenis di MVC hanya ada public di .Internal namespace layanan. Jenis-jenis ini tidak memiliki kebijakan dukungan dan tunduk pada perubahan yang melanggar.

Perilaku yang baru

Semua jenis tersebut diperbarui baik untuk berada public di namespace yang didukung atau ditandai sebagai internal.

Alasan untuk berubah

Penggunaan yang tidak disengaja dari jenis "pubternal" telah umum, mengakibatkan perubahan yang melanggar pada proyek-proyek ini dan membatasi kemampuan untuk mempertahankan kerangka kerja.

Jika Anda menggunakan jenis yang telah menjadi benar-benar public dan telah dipindahkan ke namespace baru yang didukung, perbarui referensi Anda agar sesuai dengan namespace baru.

Jika Anda menggunakan jenis yang telah ditandai sebagai internal, Anda harus menemukan alternatif. Jenis "pubternal" sebelumnya tidak pernah didukung untuk penggunaan publik. Jika ada jenis tertentu di namespace layanan ini yang penting bagi aplikasi Anda, ajukan masalah di dotnet/aspnetcore. Pertimbangan dapat dibuat untuk membuat jenis publicyang diminta .

Kategori

Inti ASP.NET

API yang Terpengaruh

Perubahan ini mencakup jenis di namespace berikut:

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

MVC: Shim kompatibilitas API Web dihapus

Dimulai dengan ASP.NET Core 3.0, Microsoft.AspNetCore.Mvc.WebApiCompatShim paket tidak lagi tersedia.

Deskripsi perubahan

Paket Microsoft.AspNetCore.Mvc.WebApiCompatShim (WebApiCompatShim) menyediakan kompatibilitas parsial di ASP.NET Core dengan ASP.NET 4.x Web API 2 untuk menyederhanakan migrasi implementasi WEB API yang ada ke ASP.NET Core. Namun, aplikasi yang menggunakan WebApiCompatShim tidak mendapat manfaat dari fitur terkait API yang dikirim dalam rilis ASP.NET Core baru-baru ini. Fitur tersebut termasuk peningkatan pembuatan spesifikasi Open API, penanganan kesalahan standar, dan pembuatan kode klien. Untuk memfokuskan upaya API dengan lebih baik di 3.0, WebApiCompatShim dihapus. Aplikasi yang ada menggunakan WebApiCompatShim harus bermigrasi ke model yang lebih [ApiController] baru.

Versi yang diperkenalkan

3.0

Alasan untuk berubah

Shim kompatibilitas API Web adalah alat migrasi. Ini membatasi akses pengguna ke fungsionalitas baru yang ditambahkan di ASP.NET Core.

Hapus penggunaan shim ini dan migrasikan langsung ke fungsionalitas serupa di ASP.NET Core itu sendiri.

Kategori

Inti ASP.NET

API yang Terpengaruh

Microsoft.AspNetCore.Mvc.WebApiCompatShim

Razor: RazorTemplateEngine API dihapus

RazorTemplateEngine API dihapus dan diganti dengan Microsoft.AspNetCore.Razor.Language.RazorProjectEngine.

Untuk diskusi, lihat Masalah GitHub dotnet/aspnetcore#25215.

Versi yang diperkenalkan

3.0

Perilaku yang lama

Mesin templat dapat dibuat dan digunakan untuk mengurai dan menghasilkan kode untuk file Razor.

Perilaku yang baru

RazorProjectEngine dapat dibuat dan diberikan jenis informasi RazorTemplateEngine yang sama untuk mengurai dan menghasilkan kode untuk file Razor. RazorProjectEngine juga menyediakan tingkat konfigurasi tambahan.

Alasan untuk berubah

RazorTemplateEngine terlalu erat digabungkan dengan implementasi yang ada. Konektor ketat ini menyebabkan lebih banyak pertanyaan ketika mencoba mengonfigurasi alur penguraian/pembuatan Razor dengan benar.

Gunakan RazorProjectEngine alih-alih RazorTemplateEngine. Pertimbangkan contoh berikut.

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

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

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

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

Kategori

Inti ASP.NET

API yang Terpengaruh

  • RazorTemplateEngine
  • RazorTemplateEngineOptions

Razor: Kompilasi runtime dipindahkan ke paket

Dukungan untuk kompilasi runtime tampilan Razor dan Halaman Razor telah dipindahkan ke paket terpisah.

Versi yang diperkenalkan

3.0

Perilaku yang lama

Kompilasi runtime tersedia tanpa memerlukan paket tambahan.

Perilaku yang baru

Fungsionalitas telah dipindahkan ke paket Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation .

API berikut sebelumnya tersedia Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions untuk mendukung kompilasi runtime. API sekarang tersedia melalui Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation.MvcRazorRuntimeCompilationOptions.

  • RazorViewEngineOptions.FileProviders sekarang MvcRazorRuntimeCompilationOptions.FileProviders
  • RazorViewEngineOptions.AdditionalCompilationReferences sekarang MvcRazorRuntimeCompilationOptions.AdditionalReferencePaths

Selain itu, Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions.AllowRecompilingViewsOnFileChange telah dihapus. Kompilasi ulang pada perubahan file diaktifkan secara default dengan mereferensikan Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation paket.

Alasan untuk berubah

Perubahan ini diperlukan untuk menghapus dependensi kerangka kerja bersama ASP.NET Core pada Roslyn.

Aplikasi yang memerlukan kompilasi runtime atau kompilasi ulang file Razor harus mengambil langkah-langkah berikut:

  1. Tambahkan referensi ke Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation paket.

  2. Perbarui metode proyek Startup.ConfigureServices untuk menyertakan panggilan ke AddRazorRuntimeCompilation. Contohnya:

    services.AddMvc()
    .AddRazorRuntimeCompilation();

Kategori

Inti ASP.NET

API yang Terpengaruh

Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions

Status sesi: API usang dihapus

API usang untuk mengonfigurasi cookie sesi dihapus. Untuk informasi selengkapnya, lihat aspnet/Pengumuman#257.

Versi yang diperkenalkan

3.0

Alasan untuk berubah

Perubahan ini memberlakukan konsistensi di seluruh API untuk mengonfigurasi fitur yang menggunakan cookie.

Migrasikan penggunaan API yang dihapus ke penggantian yang lebih baru. Pertimbangkan contoh berikut di Startup.ConfigureServices:

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

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

Kategori

Inti ASP.NET

API yang Terpengaruh

Kerangka kerja bersama: Rakitan dihapus dari Microsoft.AspNetCore.App

Mulai ASP.NET Core 3.0, kerangka kerja bersama ASP.NET Core (Microsoft.AspNetCore.App) hanya berisi rakitan pihak pertama yang sepenuhnya dikembangkan, didukung, dan dapat dilayankan oleh Microsoft.

Deskripsi perubahan

Anggap perubahan sebagai pendefinisan ulang batas untuk "platform" ASP.NET Core." Kerangka kerja bersama akan dapat dibangun sumber oleh siapa pun melalui GitHub dan akan terus menawarkan manfaat yang ada dari kerangka kerja bersama .NET Core ke aplikasi Anda. Beberapa manfaat termasuk ukuran penyebaran yang lebih kecil, patching terpusat, dan waktu mulai yang lebih cepat.

Sebagai bagian dari perubahan, beberapa perubahan mencolok penting diperkenalkan di Microsoft.AspNetCore.App.

Versi yang diperkenalkan

3.0

Perilaku yang lama

Proyek yang dirujuk Microsoft.AspNetCore.App melalui <PackageReference> elemen dalam file proyek.

Selain itu, Microsoft.AspNetCore.App berisi subkomponen berikut:

  • Json.NET (Newtonsoft.Json)
  • Entity Framework Core (rakitan diawali dengan Microsoft.EntityFrameworkCore.)
  • Roslyn (Microsoft.CodeAnalysis)

Perilaku yang baru

Referensi ke Microsoft.AspNetCore.App tidak lagi memerlukan <PackageReference> elemen dalam file proyek. .NET Core SDK mendukung elemen baru yang disebut <FrameworkReference>, yang menggantikan penggunaan <PackageReference>.

Untuk informasi selengkapnya, lihat dotnet/aspnetcore#3612.

Entity Framework Core dikirim sebagai paket NuGet. Perubahan ini menyelaraskan model pengiriman dengan semua pustaka akses data lainnya di .NET. Ini menyediakan Entity Framework Core jalur paling sederhana untuk terus berinovasi sambil mendukung berbagai platform .NET. Pemindahan Entity Framework Core dari kerangka kerja bersama tidak berdampak pada statusnya sebagai pustaka yang dikembangkan, didukung, dan dapat dilayankan Microsoft. Kebijakan dukungan .NET Core terus mencakupnya.

Json.NET dan Entity Framework Core terus bekerja dengan ASP.NET Core. Namun, mereka tidak akan disertakan dalam kerangka kerja bersama.

Untuk informasi selengkapnya, lihat Masa depan JSON di .NET Core 3.0. Lihat juga daftar lengkap biner yang dihapus dari kerangka kerja bersama.

Alasan untuk berubah

Perubahan ini menyederhanakan konsumsi Microsoft.AspNetCore.App dan mengurangi duplikasi antara paket NuGet dan kerangka kerja bersama.

Untuk informasi selengkapnya tentang motivasi untuk perubahan ini, lihat posting blog ini.

Dimulai dengan ASP.NET Core 3.0, proyek tidak perlu lagi menggunakan rakitan sebagai Microsoft.AspNetCore.App paket NuGet. Untuk menyederhanakan penargetan dan penggunaan kerangka kerja bersama ASP.NET Core, banyak paket NuGet yang dikirim karena ASP.NET Core 1.0 tidak lagi diproduksi. API yang disediakan paket tersebut masih tersedia untuk aplikasi dengan menggunakan <FrameworkReference> ke Microsoft.AspNetCore.App. Contoh API umum termasuk Kestrel, MVC, dan Razor.

Perubahan ini tidak berlaku untuk semua biner yang direferensikan melalui Microsoft.AspNetCore.App di ASP.NET Core 2.x. Pengecualian penting meliputi:

  • Microsoft.Extensions pustaka yang terus menargetkan .NET Standard tersedia sebagai paket NuGet (lihat https://github.com/dotnet/extensions).
  • API yang diproduksi oleh tim ASP.NET Core yang bukan bagian Microsoft.AspNetCore.Appdari . Misalnya, komponen berikut tersedia sebagai paket NuGet:
  • Ekstensi ke MVC yang mempertahankan dukungan untuk Json.NET. API disediakan sebagai paket NuGet untuk mendukung penggunaan Json.NET dan MVC. Lihat panduan migrasi ASP.NET Core untuk detail selengkapnya.
  • Klien SignalR .NET terus mendukung .NET Standard dan dikirim sebagai paket NuGet. Ini ditujukan untuk digunakan pada banyak runtime .NET, seperti Xamarin dan UWP.

Untuk informasi selengkapnya, lihat Berhenti memproduksi paket untuk rakitan kerangka kerja bersama di 3.0. Untuk diskusi, lihat dotnet/aspnetcore#3757.

Kategori

Inti ASP.NET

API yang Terpengaruh

Kerangka kerja bersama: Dihapus Microsoft.AspNetCore.All

Mulai ASP.NET Core 3.0, Microsoft.AspNetCore.All metapackage dan kerangka kerja bersama yang cocok Microsoft.AspNetCore.All tidak lagi diproduksi. Paket ini tersedia di ASP.NET Core 2.2 dan akan terus menerima pembaruan layanan di ASP.NET Core 2.1.

Versi yang diperkenalkan

3.0

Perilaku yang lama

Aplikasi dapat menggunakan Microsoft.AspNetCore.All metapackage untuk menargetkan Microsoft.AspNetCore.All kerangka kerja bersama di .NET Core.

Perilaku yang baru

.NET Core 3.0 tidak menyertakan Microsoft.AspNetCore.All kerangka kerja bersama.

Alasan untuk berubah

Metapackage Microsoft.AspNetCore.All menyertakan sejumlah besar dependensi eksternal.

Migrasikan proyek Anda untuk menggunakan Microsoft.AspNetCore.App kerangka kerja. Komponen yang sebelumnya tersedia di Microsoft.AspNetCore.All masih tersedia di NuGet. Komponen tersebut sekarang disebarkan dengan aplikasi Anda alih-alih disertakan dalam kerangka kerja bersama.

Kategori

Inti ASP.NET

API yang Terpengaruh

Tidak

SignalR: HandshakeProtocol.SuccessHandshakeData diganti

Bidang HandshakeProtocol.SuccessHandshakeData dihapus dan diganti dengan metode pembantu yang menghasilkan respons jabat tangan yang berhasil diberikan .IHubProtocol

Versi yang diperkenalkan

3.0

Perilaku yang lama

HandshakeProtocol.SuccessHandshakeData adalah bidang public static ReadOnlyMemory<byte> .

Perilaku yang baru

HandshakeProtocol.SuccessHandshakeData telah digantikan oleh static GetSuccessfulHandshake(IHubProtocol protocol) metode yang mengembalikan ReadOnlyMemory<byte> berdasarkan protokol yang ditentukan.

Alasan untuk berubah

Bidang tambahan ditambahkan ke respons jabat tangan yang tidak konstan dan berubah tergantung pada protokol yang dipilih.

Tidak ada. Jenis ini tidak dirancang untuk digunakan dari kode pengguna. publicIni adalah , sehingga dapat dibagikan antara server SignalR dan klien. Ini juga dapat digunakan oleh klien SignalR pelanggan yang ditulis dalam .NET. Pengguna SignalR tidak boleh terpengaruh oleh perubahan ini.

Kategori

Inti ASP.NET

API yang Terpengaruh

HandshakeProtocol.SuccessHandshakeData

SignalR: Metode HubConnection ResetSendPing dan ResetTimeout dihapus

Metode ResetSendPing dan ResetTimeout dihapus dari SignalR HubConnection API. Metode ini awalnya hanya ditujukan untuk penggunaan internal tetapi dipublikasikan di ASP.NET Core 2.2. Metode ini tidak akan tersedia mulai dari rilis ASP.NET Core 3.0 Pratinjau 4. Untuk diskusi, lihat dotnet/aspnetcore#8543.

Versi yang diperkenalkan

3.0

Perilaku yang lama

API tersedia.

Perilaku yang baru

API dihapus.

Alasan untuk berubah

Metode ini awalnya hanya ditujukan untuk penggunaan internal tetapi dipublikasikan di ASP.NET Core 2.2.

Jangan gunakan metode ini.

Kategori

Inti ASP.NET

API yang Terpengaruh

SignalR: Konstruktor HubConnectionContext berubah

Konstruktor SignalR HubConnectionContext berubah untuk menerima jenis opsi, bukan beberapa parameter, menjadi opsi penambahan bukti di masa mendatang. Perubahan ini menggantikan dua konstruktor dengan satu konstruktor yang menerima jenis opsi.

Versi yang diperkenalkan

3.0

Perilaku yang lama

HubConnectionContext memiliki dua konstruktor:

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

Perilaku yang baru

Dua konstruktor dihapus dan diganti dengan satu konstruktor:

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

Alasan untuk berubah

Konstruktor baru menggunakan objek opsi baru. Akibatnya, fitur HubConnectionContext dapat diperluas di masa depan tanpa membuat lebih banyak konstruktor dan melanggar perubahan.

Alih-alih menggunakan konstruktor berikut:

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

Gunakan konstruktor berikut:

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

Kategori

Inti ASP.NET

API yang Terpengaruh

SignalR: Nama paket klien JavaScript berubah

Dalam ASP.NET Core 3.0 Preview 7, nama paket klien SignalR JavaScript berubah dari @aspnet/signalr menjadi @microsoft/signalr. Perubahan nama mencerminkan fakta bahwa SignalR berguna di lebih dari sekadar aplikasi ASP.NET Core, berkat Azure SignalR Service.

Untuk bereaksi terhadap perubahan ini, ubah referensi dalam package.json file, pernyataan, dan pernyataan ECMAScript import Anda. require Tidak ada API yang akan berubah sebagai bagian dari penggantian nama ini.

Untuk diskusi, lihat dotnet/aspnetcore#11637.

Versi yang diperkenalkan

3.0

Perilaku yang lama

Paket klien diberi nama @aspnet/signalr.

Perilaku yang baru

Paket klien diberi nama @microsoft/signalr.

Alasan untuk berubah

Perubahan nama mengklarifikasi bahwa SignalR berguna di luar aplikasi ASP.NET Core, berkat Azure SignalR Service.

Beralih ke paket @microsoft/signalrbaru .

Kategori

Inti ASP.NET

API yang Terpengaruh

Tidak

SignalR: Metode UseSignalR dan UseConnections ditandai usang

Metode UseConnections dan UseSignalR dan kelas ConnectionsRouteBuilder dan HubRouteBuilder ditandai sebagai usang dalam ASP.NET Core 3.0.

Versi yang diperkenalkan

3.0

Perilaku yang lama

Perutean hub SignalR dikonfigurasi menggunakan UseSignalR atau UseConnections.

Perilaku yang baru

Cara lama mengonfigurasi perutean telah usang dan diganti dengan perutean titik akhir.

Alasan untuk berubah

Middleware sedang dipindahkan ke sistem perutean titik akhir baru. Cara lama menambahkan middleware sedang usang.

Ganti UseSignalR dengan UseEndpoints:

Kode lama:

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

Kode baru:

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

Kategori

Inti ASP.NET

API yang Terpengaruh

SPAs: SpaServices dan NodeServices ditandai usang

Konten paket NuGet berikut semuanya tidak perlu sejak ASP.NET Core 2.1. Akibatnya, paket berikut ditandai sebagai usang:

Untuk alasan yang sama, modul npm berikut ditandai sebagai tidak digunakan lagi:

Paket sebelumnya dan modul npm nantinya akan dihapus di .NET 5.

Versi yang diperkenalkan

3.0

Perilaku yang lama

Paket dan modul npm yang tidak digunakan lagi dimaksudkan untuk mengintegrasikan ASP.NET Core dengan berbagai kerangka kerja Aplikasi Halaman Tunggal (SPA). Kerangka kerja tersebut termasuk Angular, React, dan React with Redux.

Perilaku yang baru

Mekanisme integrasi baru ada di paket NuGet Microsoft.AspNetCore.SpaServices.Extensions . Paket tetap menjadi dasar templat proyek Angular dan React sejak ASP.NET Core 2.1.

Alasan untuk berubah

ASP.NET Core mendukung integrasi dengan berbagai kerangka kerja Aplikasi Halaman Tunggal (SPA), termasuk Angular, React, dan React with Redux. Awalnya, integrasi dengan kerangka kerja ini dicapai dengan komponen khusus ASP.NET Core yang menangani skenario seperti prarendering dan integrasi sisi server dengan Webpack. Seiring berjalannya waktu, standar industri berubah. Masing-masing kerangka kerja SPA merilis antarmuka baris perintah standar mereka sendiri. Misalnya, Angular CLI dan create-react-app.

Ketika ASP.NET Core 2.1 dirilis pada Mei 2018, tim merespons perubahan standar. Cara yang lebih baru dan lebih sederhana untuk berintegrasi dengan toolchains kerangka kerja SPA sendiri disediakan. Mekanisme integrasi baru ada dalam paket Microsoft.AspNetCore.SpaServices.Extensions dan tetap menjadi dasar templat proyek Angular dan React sejak ASP.NET Core 2.1.

Untuk mengklarifikasi bahwa komponen ASP.NET khusus Core yang lebih lama tidak relevan dan tidak disarankan:

  • Mekanisme integrasi pra-2.1 ditandai sebagai usang.
  • Paket npm pendukung ditandai sebagai tidak digunakan lagi.

Jika Anda menggunakan paket ini, perbarui aplikasi Anda untuk menggunakan fungsionalitas:

  • Microsoft.AspNetCore.SpaServices.Extensions Dalam paket.
  • Disediakan oleh kerangka kerja SPA yang Anda gunakan

Untuk mengaktifkan fitur seperti prarendering sisi server dan pemuatan ulang modul panas, lihat dokumentasi untuk kerangka kerja SPA yang sesuai. Fungsionalitas dalam Microsoft.AspNetCore.SpaServices.Extensions tidak usang dan akan terus didukung.

Kategori

Inti ASP.NET

API yang Terpengaruh

SPAs: SpaServices dan NodeServices tidak lagi kembali ke pencatat konsol

Microsoft.AspNetCore.SpaServices dan Microsoft.AspNetCore.NodeServices tidak akan menampilkan log konsol kecuali pengelogan dikonfigurasi.

Versi yang diperkenalkan

3.0

Perilaku yang lama

Microsoft.AspNetCore.SpaServices dan Microsoft.AspNetCore.NodeServices digunakan untuk membuat pencatat konsol secara otomatis saat pengelogan tidak dikonfigurasi.

Perilaku yang baru

Microsoft.AspNetCore.SpaServices dan Microsoft.AspNetCore.NodeServices tidak akan menampilkan log konsol kecuali pengelogan dikonfigurasi.

Alasan untuk berubah

Ada kebutuhan untuk menyelaraskan dengan bagaimana paket ASP.NET Core lainnya menerapkan pengelogan.

Jika perilaku lama diperlukan, untuk mengonfigurasi pengelogan konsol, tambahkan services.AddLogging(builder => builder.AddConsole()) ke metode Anda Setup.ConfigureServices .

Kategori

Inti ASP.NET

API yang Terpengaruh

Tidak

Kerangka kerja target: Dukungan .NET Framework dihilangkan

Dimulai dengan ASP.NET Core 3.0, .NET Framework adalah kerangka kerja target yang tidak didukung.

Deskripsi perubahan

.NET Framework 4.8 adalah versi utama terakhir dari .NET Framework. Aplikasi ASP.NET Core baru harus dibangun di .NET Core. Dimulai dengan rilis .NET Core 3.0, Anda dapat menganggap ASP.NET Core 3.0 sebagai bagian dari .NET Core.

Pelanggan yang menggunakan ASP.NET Core dengan .NET Framework dapat melanjutkan dengan cara yang didukung penuh menggunakan rilis 2.1 LTS. Dukungan dan layanan untuk 2.1 berlanjut hingga setidaknya 21 Agustus 2021. Tanggal ini adalah tiga tahun setelah deklarasi rilis LTS per Kebijakan Dukungan .NET. Dukungan untuk paket ASP.NET Core 2.1 pada .NET Framework akan diperluas tanpa batas waktu, mirip dengan kebijakan layanan untuk kerangka kerja ASP.NET berbasis paket lainnya.

Untuk informasi selengkapnya tentang porting dari .NET Framework ke .NET Core, lihat Porting ke .NET Core.

Microsoft.Extensions paket (seperti pengelogan, injeksi dependensi, dan konfigurasi) dan Core Kerangka Kerja Entitas tidak terpengaruh. Mereka akan terus mendukung .NET Standard.

Untuk informasi selengkapnya tentang motivasi untuk perubahan ini, lihat posting blog asli.

Versi yang diperkenalkan

3.0

Perilaku yang lama

aplikasi ASP.NET Core dapat berjalan pada .NET Core atau .NET Framework.

Perilaku yang baru

ASP.NET Core hanya dapat dijalankan di .NET Core.

Ikuti salah satu tindakan berikut:

  • Simpan aplikasi Anda di ASP.NET Core 2.1.
  • Migrasikan aplikasi dan dependensi Anda ke .NET Core.

Kategori

Inti ASP.NET

API yang Terpengaruh

Tidak

Pustaka .NET Inti

API yang melaporkan versi sekarang melaporkan produk dan bukan versi file

Banyak API yang mengembalikan versi di .NET Core sekarang mengembalikan versi produk daripada versi file.

Deskripsi perubahan

Di .NET Core 2.2 dan versi sebelumnya, metode seperti Environment.Version, RuntimeInformation.FrameworkDescription, dan dialog properti file untuk rakitan .NET Core mencerminkan versi file. Dimulai dengan .NET Core 3.0, mereka mencerminkan versi produk.

Gambar berikut mengilustrasikan perbedaan informasi versi untuk rakitan System.Runtime.dll untuk .NET Core 2.2 (di sebelah kiri) dan .NET Core 3.0 (di sebelah kanan) seperti yang ditampilkan oleh dialog properti file Windows Explorer .

Perbedaan informasi versi produk

Versi yang diperkenalkan

3.0

Tidak ada. Perubahan ini harus membuat deteksi versi intuitif daripada obtuse.

Kategori

Pustaka .NET Inti

API yang Terpengaruh

Instans EncoderFallbackBuffer kustom tidak dapat mundur secara rekursif

Instans kustom EncoderFallbackBuffer tidak dapat mundur secara rekursif. Implementasi EncoderFallbackBuffer.GetNextChar() harus menghasilkan urutan karakter yang dapat dikonversi ke pengodean tujuan. Jika tidak, pengecualian terjadi.

Deskripsi perubahan

Selama operasi transcoding karakter-ke-byte, runtime mendeteksi urutan UTF-16 yang tidak terbentuk atau tidak dapat dikonvertbel dan menyediakan karakter tersebut EncoderFallbackBuffer.Fallback ke metode . Metode menentukan Fallback karakter mana yang harus diganti untuk data asli yang tidak dapat dikonvertbel, dan karakter ini dikosongkan dengan memanggil EncoderFallbackBuffer.GetNextChar dalam perulangan.

Runtime kemudian mencoba untuk mentranskode karakter substitusi ini ke pengodean target. Jika operasi ini berhasil, runtime melanjutkan transcoding dari tempatnya ditinggalkan dalam string input asli.

Sebelumnya, implementasi EncoderFallbackBuffer.GetNextChar() kustom dapat mengembalikan urutan karakter yang tidak dapat dikonversi ke pengodean tujuan. Jika karakter yang diganti tidak dapat ditranskodekan ke pengodean target, runtime memanggil EncoderFallbackBuffer.Fallback metode sekali lagi dengan karakter pengganti, mengharapkan EncoderFallbackBuffer.GetNextChar() metode untuk mengembalikan urutan penggantian baru. Proses ini berlanjut sampai runtime akhirnya melihat substitusi yang terbentuk dengan baik, dapat dikonversi, atau sampai jumlah rekursi maksimum tercapai.

Dimulai dengan .NET Core 3.0, implementasi EncoderFallbackBuffer.GetNextChar() kustom harus mengembalikan urutan karakter yang dapat dikonversi ke pengodean tujuan. Jika karakter yang diganti tidak dapat ditranskodekan ke pengodean target, akan ArgumentException dilemparkan. Runtime tidak akan lagi melakukan panggilan rekursif ke EncoderFallbackBuffer dalam instans.

Perilaku ini hanya berlaku ketika ketiga kondisi berikut terpenuhi:

  • Runtime mendeteksi urutan UTF-16 yang tidak terbentuk atau urutan UTF-16 yang tidak dapat dikonversi ke pengodean target.
  • Kustom EncoderFallback telah ditentukan.
  • Upaya kustom EncoderFallback untuk mengganti urutan UTF-16 baru yang tidak terbentuk atau tidak dapat dikonversi.

Versi yang diperkenalkan

3.0

Sebagian besar pengembang tidak perlu mengambil tindakan apa pun.

Jika aplikasi menggunakan kustom EncoderFallback dan EncoderFallbackBuffer kelas, pastikan implementasi EncoderFallbackBuffer.Fallback mengisi buffer fallback dengan data UTF-16 yang terbentuk dengan baik yang langsung dapat dikonversi ke pengodean target ketika Fallback metode pertama kali dipanggil oleh runtime.

Kategori

Pustaka .NET Inti

API yang Terpengaruh

Perilaku pemformatan dan penguraian titik mengambang berubah

Perilaku penguraian dan pemformatan titik mengambang (berdasarkan Double jenis dan Single ) sekarang sesuai dengan IEEE. Ini memastikan bahwa perilaku jenis floating-point di .NET cocok dengan bahasa lain yang sesuai dengan IEEE. Misalnya, double.Parse("SomeLiteral") harus selalu cocok dengan apa yang dihasilkan C# untuk double x = SomeLiteral.

Deskripsi perubahan

Di .NET Core 2.2 dan versi yang lebih lama, pemformatan dengan Double.ToString dan Single.ToString, dan penguraian dengan Double.Parse, Double.TryParse, Single.Parse, dan Single.TryParse tidak sesuai dengan IEEE. Akibatnya, tidak mungkin untuk menjamin bahwa nilai akan pulang pergi dengan string format standar atau kustom yang didukung. Untuk beberapa input, upaya untuk mengurai nilai yang diformat dapat gagal, dan untuk yang lain, nilai yang diurai tidak sama dengan nilai asli.

Dimulai dengan .NET Core 3.0, operasi penguraian dan pemformatan floating-point mematuhi IEEE 754.

Tabel berikut menunjukkan dua cuplikan kode dan bagaimana output berubah antara .NET Core 2.2 dan .NET Core 3.1.

Cuplikan kode Output pada .NET Core 2.2 Output pada .NET Core 3.1
Console.WriteLine((-0.0).ToString()); 0 0-
var value = -3.123456789123456789;
Console.WriteLine(value == double.Parse(value.ToString()));		 False True

Untuk informasi selengkapnya, lihat penguraian titik mengambang dan peningkatan pemformatan dalam posting blog .NET Core 3.0 .

Versi yang diperkenalkan

3.0

Bagian Dampak potensial ke kode yang ada dari penguraian titik float dan peningkatan pemformatan dalam posting blog .NET Core 3.0 menunjukkan beberapa perubahan yang dapat Anda lakukan pada kode Anda jika Anda ingin mempertahankan perilaku sebelumnya.

  • Untuk beberapa perbedaan dalam pemformatan, Anda bisa mendapatkan perilaku yang setara dengan perilaku sebelumnya dengan menentukan string format yang berbeda.
  • Untuk perbedaan penguraian, tidak ada mekanisme untuk kembali ke perilaku sebelumnya.

Kategori

Pustaka .NET Inti

API yang Terpengaruh

Operasi penguraian floating-point tidak lagi gagal atau melempar OverflowException

Metode penguraian Single floating-point tidak lagi melempar OverflowException atau mengembalikan false ketika mereka mengurai string yang nilai numeriknya berada di luar rentang jenis atau Double floating-point.

Deskripsi perubahan

Dalam .NET Core 2.2 dan versi yang lebih lama, Double.Parse metode dan Single.Parse melemparkan OverflowException untuk nilai yang di luar rentang jenisnya masing-masing. Metode Double.TryParse dan Single.TryParse mengembalikan false untuk representasi string dari nilai numerik di luar rentang.

Dimulai dengan .NET Core 3.0, Double.Parsemetode , Double.TryParse, Single.Parse, dan Single.TryParse tidak lagi gagal saat mengurai string numerik di luar rentang. Sebagai gantinya Double , metode penguraian mengembalikan Double.PositiveInfinity nilai yang melebihi Double.MaxValue, dan mereka mengembalikan Double.NegativeInfinity untuk nilai yang kurang dari Double.MinValue. Demikian pula, Single metode penguraian kembali Single.PositiveInfinity untuk nilai yang melebihi Single.MaxValue, dan mereka mengembalikan Single.NegativeInfinity untuk nilai yang kurang dari Single.MinValue.

Perubahan ini dilakukan untuk meningkatkan kepatuhan IEEE 754:2008.

Versi yang diperkenalkan

3.0

Perubahan ini dapat memengaruhi kode Anda dengan salah satu dari dua cara:

  • Kode Anda bergantung pada handler untuk OverflowException dijalankan saat luapan terjadi. Dalam hal ini, Anda harus menghapus catch pernyataan dan menempatkan kode yang If diperlukan dalam pernyataan yang menguji apakah Double.IsInfinity atau Single.IsInfinity .true

  • Kode Anda mengasumsikan bahwa nilai floating-point bukan Infinity. Dalam hal ini, Anda harus menambahkan kode yang diperlukan untuk memeriksa nilai PositiveInfinity floating-point dan NegativeInfinity.

Kategori

Pustaka .NET Inti

API yang Terpengaruh

InvalidAsynchronousStateException dipindahkan ke rakitan lain

Kelas InvalidAsynchronousStateException telah dipindahkan.

Deskripsi perubahan

Di .NET Core 2.2 dan versi yang lebih lama, InvalidAsynchronousStateException kelas ditemukan di rakitan System.ComponentModel.TypeConverter .

Dimulai dengan .NET Core 3.0, ditemukan di rakitan System.ComponentModel.Primitives .

Versi yang diperkenalkan

3.0

Perubahan ini hanya memengaruhi aplikasi yang menggunakan pantulan untuk memuat InvalidAsynchronousStateException dengan memanggil metode seperti Assembly.GetType atau kelebihan beban Activator.CreateInstance yang mengasumsikan jenisnya berada dalam rakitan tertentu. Jika demikian, perbarui rakitan yang dirujuk dalam panggilan metode untuk mencerminkan lokasi rakitan baru jenis tersebut.

Kategori

Pustaka .NET Inti

API yang Terpengaruh

Tidak ada.

Mengganti urutan byte UTF-8 yang tidak terbentuk mengikuti panduan Unicode

UTF8Encoding Ketika kelas mengalami urutan byte UTF-8 yang tidak terbentuk selama operasi transcoding byte-to-character, kelas mengganti urutan tersebut dengan karakter ' ' (KARAKTER PENGGANTIan U+FFFD) dalam string output. .NET Core 3.0 berbeda dari versi .NET Core dan .NET Framework sebelumnya dengan mengikuti praktik terbaik Unicode untuk melakukan penggantian ini selama operasi transcoding.

Ini adalah bagian dari upaya yang lebih besar untuk meningkatkan penanganan UTF-8 di seluruh .NET, termasuk oleh yang baru System.Text.Unicode.Utf8 dan System.Text.Rune jenis. Jenis ini UTF8Encoding diberikan mekanisme penanganan kesalahan yang ditingkatkan sehingga menghasilkan output yang konsisten dengan jenis yang baru diperkenalkan.

Deskripsi perubahan

Dimulai dengan .NET Core 3.0, saat transcoding byte ke karakter, UTF8Encoding kelas melakukan penggantian karakter berdasarkan praktik terbaik Unicode. Mekanisme substitusi yang digunakan dijelaskan oleh The Unicode Standard, Version 12.0, Sec. 3.9 (PDF) dalam judul berjudul Subsitusi U+FFFD Subbagian Maksimal.

Perilaku ini hanya berlaku ketika urutan byte input berisi data UTF-8 yang tidak terbentuk. Selain itu, jika UTF8Encoding instans telah dibangun dengan throwOnInvalidBytes: true, UTF8Encoding instans akan terus melemparkan input yang tidak valid daripada melakukan penggantian U+FFFD. Untuk informasi selengkapnya tentang UTF8Encoding konstruktor, lihat UTF8Encoding(Boolean, Boolean).

Tabel berikut mengilustrasikan dampak perubahan ini dengan input 3-byte yang tidak valid:

Input 3 byte yang tidak terbentuk Output sebelum .NET Core 3.0 Output dimulai dengan .NET Core 3.0
[ ED A0 90 ] [ FFFD FFFD ] (output 2 karakter) [ FFFD FFFD FFFD ] (output 3 karakter)

Output 3 karakter adalah output pilihan, menurut Tabel 3-9 dari PDF Standar Unicode yang ditautkan sebelumnya.

Versi yang diperkenalkan

3.0

Tidak ada tindakan yang diperlukan pada bagian pengembang.

Kategori

Pustaka .NET Inti

API yang Terpengaruh

TypeDescriptionProviderAttribute dipindahkan ke rakitan lain

Kelas TypeDescriptionProviderAttribute telah dipindahkan.

Deskripsi perubahan

Di .NET Core 2.2 dan versi yang lebih lama, Kelas TypeDescriptionProviderAttribute ini ditemukan di rakitan System.ComponentModel.TypeConverter .

Dimulai dengan .NET Core 3.0, ditemukan di rakitan System.ObjectModel .

Versi yang diperkenalkan

3.0

Perubahan ini hanya memengaruhi aplikasi yang menggunakan pantulan untuk memuat TypeDescriptionProviderAttribute jenis dengan memanggil metode seperti Assembly.GetType atau kelebihan beban Activator.CreateInstance yang mengasumsikan jenisnya berada dalam rakitan tertentu. Jika demikian, rakitan yang dirujuk dalam panggilan metode harus diperbarui untuk mencerminkan lokasi perakitan baru jenis tersebut.

Kategori

Formulir Windows

API yang Terpengaruh

Tidak ada.

ZipArchiveEntry tidak lagi menangani arsip dengan ukuran entri yang tidak konsisten

Arsip Zip mencantumkan ukuran terkompresi dan ukuran yang tidak dikompresi di direktori pusat dan header lokal. Data entri itu sendiri juga menunjukkan ukurannya. Di .NET Core 2.2 dan versi yang lebih lama, nilai-nilai ini tidak pernah diperiksa untuk konsistensi. Dimulai dengan .NET Core 3.0, sekarang.

Deskripsi perubahan

Di .NET Core 2.2 dan versi yang lebih lama, ZipArchiveEntry.Open() berhasil bahkan jika header lokal tidak setuju dengan header pusat file zip. Data didekompresi hingga akhir aliran terkompresi tercapai, bahkan jika panjangnya melebihi ukuran file yang tidak dikompresi yang tercantum di direktori pusat/header lokal.

Dimulai dengan .NET Core 3.0, ZipArchiveEntry.Open() metode memeriksa bahwa header lokal dan header pusat setuju pada ukuran entri yang dikompresi dan tidak dikompresi. Jika tidak, metode melemparkan InvalidDataException jika header lokal arsip dan/atau ukuran daftar deskriptor data yang tidak setuju dengan direktori pusat file zip. Saat membaca entri, data yang didekompresi dipotong ke ukuran file yang tidak dikompresi yang tercantum di header.

Perubahan ini dilakukan untuk memastikan bahwa ZipArchiveEntry dengan benar mewakili ukuran datanya dan hanya jumlah data yang dibaca.

Versi yang diperkenalkan

3.0

Mengemas ulang arsip zip apa pun yang menunjukkan masalah ini.

Kategori

Pustaka .NET Inti

API yang Terpengaruh

FieldInfo.SetValue melempar pengecualian untuk bidang statis khusus init

Mulai dari .NET Core 3.0, pengecualian dilemparkan ketika Anda mencoba mengatur nilai pada bidang statis dengan InitOnly memanggil System.Reflection.FieldInfo.SetValue.

Deskripsi perubahan

Dalam .NET Framework dan versi .NET Core sebelum 3.0, Anda dapat mengatur nilai bidang statis yang konstan setelah diinisialisasi (baca saja di C#) dengan memanggil System.Reflection.FieldInfo.SetValue. Namun, pengaturan bidang seperti itu dengan cara ini mengakibatkan perilaku yang tidak dapat diprediksi berdasarkan kerangka kerja target dan pengaturan pengoptimalan.

Di .NET Core 3.0 dan versi yang lebih baru, saat Anda memanggil SetValue bidang statis, InitOnly System.FieldAccessException pengecualian akan dilemparkan.

Tip

Bidang InitOnly adalah bidang yang hanya dapat diatur pada saat dideklarasikan atau di konstruktor untuk kelas yang berisi. Dengan kata lain, konstan setelah diinisialisasi.

Versi yang diperkenalkan

3.0

Menginisialisasi bidang statis InitOnly dalam konstruktor statis. Ini berlaku untuk jenis dinamis dan non-dinamis.

Atau, Anda dapat menghapus FieldAttributes.InitOnly atribut dari bidang, lalu memanggil FieldInfo.SetValue.

Kategori

Pustaka .NET Inti

API yang Terpengaruh

Meneruskan GroupCollection ke metode ekstensi mengambil IEnumerable<T> memerlukan disambiguasi

Saat memanggil metode ekstensi yang mengambil IEnumerable<T> pada GroupCollection, Anda harus membedakan jenis menggunakan cast.

Deskripsi perubahan

Mulai dari .NET Core 3.0, System.Text.RegularExpressions.GroupCollection mengimplementasikan IEnumerable<KeyValuePair<String,Group>> selain jenis lain yang diterapkannya, termasuk IEnumerable<Group>. Ini menghasilkan ambiguitas saat memanggil metode ekstensi yang mengambil IEnumerable<T>. Jika Anda memanggil metode ekstensi seperti itu pada GroupCollection instans, misalnya, Enumerable.Count, Anda akan melihat kesalahan pengkompilasi berikut:

CS1061: 'GroupCollection' tidak berisi definisi untuk 'Count' dan tidak ada metode ekstensi yang dapat diakses 'Count' yang menerima argumen pertama jenis 'GroupCollection' dapat ditemukan (apakah Anda kehilangan menggunakan direktif atau referensi perakitan?)

Dalam versi .NET sebelumnya, tidak ada ambiguitas dan tidak ada kesalahan kompilator.

Versi yang diperkenalkan

3.0

Alasan untuk berubah

Ini adalah perubahan melanggar yang tidak disengaja. Karena sudah seperti ini untuk beberapa waktu, kami tidak berencana untuk mengembalikannya. Selain itu, perubahan seperti itu sendiri akan melanggar.

Misalnya GroupCollection , disambiguasi panggilan ke metode ekstensi yang menerima IEnumerable<T> dengan cast.

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

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

Kategori

Pustaka .NET Inti

API yang Terpengaruh

Metode ekstensi apa pun yang menerima IEnumerable<T> terpengaruh. Contohnya:

Kriptografi

Sintaks "BEGIN TRUSTED CERTIFICATE" tidak lagi didukung untuk sertifikat akar di Linux

Sertifikat akar di Linux dan sistem seperti Unix lainnya (tetapi tidak macOS) dapat disajikan dalam dua bentuk: header PEM standar BEGIN CERTIFICATE , dan header PEM khusus BEGIN TRUSTED CERTIFICATE OpenSSL. Sintaks terakhir memungkinkan konfigurasi tambahan yang telah menyebabkan masalah kompatibilitas dengan kelas .NET Core System.Security.Cryptography.X509Certificates.X509Chain . BEGIN TRUSTED CERTIFICATE konten sertifikat akar tidak lagi dimuat oleh mesin rantai yang dimulai di .NET Core 3.0.

Deskripsi perubahan

Sebelumnya, sintaks BEGIN CERTIFICATE dan BEGIN TRUSTED CERTIFICATE digunakan untuk mengisi daftar kepercayaan akar. BEGIN TRUSTED CERTIFICATE Jika sintaks digunakan dan opsi tambahan ditentukan dalam file, X509Chain mungkin telah melaporkan bahwa kepercayaan rantai secara eksplisit tidak diizinkan (X509ChainStatusFlags.ExplicitDistrust). Namun, jika sertifikat juga ditentukan dengan BEGIN CERTIFICATE sintaks dalam file yang dimuat sebelumnya, kepercayaan rantai diizinkan.

Mulai dari .NET Core 3.0, BEGIN TRUSTED CERTIFICATE konten tidak lagi dibaca. Jika sertifikat tidak juga ditentukan melalui sintaks standar BEGIN CERTIFICATE , X509Chain laporan bahwa akar tidak tepercaya (X509ChainStatusFlags.UntrustedRoot).

Versi yang diperkenalkan

3.0

Sebagian besar aplikasi tidak terpengaruh oleh perubahan ini, tetapi aplikasi yang tidak dapat melihat kedua sumber sertifikat akar karena masalah izin mungkin mengalami kesalahan yang tidak terduga UntrustedRoot setelah peningkatan.

Banyak distribusi Linux (atau distro) menulis sertifikat akar ke dua lokasi: direktori satu sertifikat per file, dan perangkaian satu file. Pada beberapa distro, direktori satu-sertifikat-per-file menggunakan BEGIN TRUSTED CERTIFICATE sintaks sementara perangkaian file menggunakan sintaks standar BEGIN CERTIFICATE . Pastikan bahwa sertifikat akar kustom ditambahkan seperti BEGIN CERTIFICATE di setidaknya salah satu lokasi ini, dan kedua lokasi dapat dibaca oleh aplikasi Anda.

Direktori yang khas adalah /etc/ssl/certs/ dan file yang digabungkan yang khas adalah /etc/ssl/cert.pem. Gunakan perintah openssl version -d untuk menentukan root khusus platform, yang mungkin berbeda dari /etc/ssl/. Misalnya, pada Ubuntu 18.04, direktorinya adalah /usr/lib/ssl/certs/ dan filenya adalah /usr/lib/ssl/cert.pem. Namun, /usr/lib/ssl/certs/ adalah symlink ke /etc/ssl/certs/ dan /usr/lib/ssl/cert.pem tidak ada.

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

Kategori

Kriptografi

API yang Terpengaruh

EnvelopedCms default ke enkripsi AES-256

Algoritma enkripsi simetris default yang digunakan oleh EnvelopedCms telah berubah dari TripleDES menjadi AES-256.

Deskripsi perubahan

Dalam versi sebelumnya, ketika EnvelopedCms digunakan untuk mengenkripsi data tanpa menentukan algoritma enkripsi simetris melalui kelebihan beban konstruktor, data dienkripsi dengan algoritma TripleDES/3DES/3DEA/DES3-EDE.

Dimulai dengan .NET Core 3.0 (melalui versi 4.6.0 dari paket NuGet System.Security.Cryptography.Pkcs ), algoritma default telah diubah ke AES-256 untuk modernisasi algoritma dan untuk meningkatkan keamanan opsi default. Jika sertifikat penerima pesan memiliki kunci umum Diffie-Hellman (non-EC), operasi enkripsi mungkin gagal karena CryptographicException keterbatasan di platform yang mendasar.

Dalam kode sampel berikut, data dienkripsi dengan TripleDES jika berjalan pada .NET Core 2.2 atau yang lebih lama. Jika berjalan pada .NET Core 3.0 atau yang lebih baru, itu dienkripsi dengan AES-256.

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

Versi yang diperkenalkan

3.0

Jika Anda terkena dampak negatif dari perubahan tersebut, Anda dapat memulihkan enkripsi TripleDES dengan secara eksplisit menentukan pengidentifikasi algoritma enkripsi dalam EnvelopedCms konstruktor yang menyertakan parameter jenis AlgorithmIdentifier, seperti:

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

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

Kategori

Kriptografi

API yang Terpengaruh

Ukuran minimum untuk pembuatan kunci RSAOpenSsl telah meningkat

Ukuran minimum untuk menghasilkan kunci RSA baru di Linux telah meningkat dari 384-bit menjadi 512-bit.

Deskripsi perubahan

Dimulai dengan .NET Core 3.0, ukuran kunci hukum minimum yang dilaporkan oleh LegalKeySizes properti pada instans RSA dari RSA.Create, RSAOpenSsl, dan RSACryptoServiceProvider di Linux telah meningkat dari 384 menjadi 512.

Akibatnya, dalam .NET Core 2.2 dan versi yang lebih lama, panggilan metode seperti RSA.Create(384) berhasil. Di .NET Core 3.0 dan versi yang lebih baru, panggilan RSA.Create(384) metode melempar pengecualian yang menunjukkan ukurannya terlalu kecil.

Perubahan ini dilakukan karena OpenSSL, yang melakukan operasi kriptografi di Linux, meningkatkan minimumnya antara versi 1.0.2 dan 1.1.0. .NET Core 3.0 lebih memilih OpenSSL 1.1.x hingga 1.0.x, dan versi minimum yang dilaporkan dinaikkan untuk mencerminkan batasan dependensi baru yang lebih tinggi ini.

Versi yang diperkenalkan

3.0

Jika Anda memanggil salah satu API yang terpengaruh, pastikan bahwa ukuran kunci yang dihasilkan tidak kurang dari minimum penyedia.

Catatan

RSA 384-bit sudah dianggap tidak aman (seperti RSA 512-bit). Rekomendasi modern, seperti Publikasi Khusus NIST 800-57 Bagian 1 Revisi 4, menyarankan 2048-bit sebagai ukuran minimum untuk kunci yang baru dihasilkan.

Kategori

Kriptografi

API yang Terpengaruh

.NET Core 3.0 lebih suka OpenSSL 1.1.x ke OpenSSL 1.0.x

.NET Core untuk Linux, yang berfungsi di beberapa distribusi Linux, dapat mendukung OpenSSL 1.0.x dan OpenSSL 1.1.x. .NET Core 2.1 dan .NET Core 2.2 mencari 1.0.x terlebih dahulu, lalu kembali ke 1.1.x; .NET Core 3.0 mencari 1.1.x terlebih dahulu. Perubahan ini dilakukan untuk menambahkan dukungan untuk standar kriptografi baru.

Perubahan ini dapat memengaruhi pustaka atau aplikasi yang melakukan interop platform dengan jenis interop khusus OpenSSL di .NET Core.

Deskripsi perubahan

Di .NET Core 2.2 dan versi yang lebih lama, runtime lebih suka memuat OpenSSL 1.0.x lebih dari 1.1.x. Ini berarti bahwa IntPtr jenis dan SafeHandle untuk interop dengan OpenSSL digunakan dengan libcrypto.so.1.0.0 / libcrypto.so.1.0 / libcrypto.so.10 berdasarkan preferensi.

Dimulai dengan .NET Core 3.0, runtime lebih suka memuat OpenSSL 1.1.x daripada OpenSSL 1.0.x, sehingga IntPtr jenis dan SafeHandle untuk interop dengan OpenSSL digunakan dengan libcrypto.so.1.1 / libcrypto.so.11 / libcrypto.so.1.1.0 / libcrypto.so.1.1 berdasarkan preferensi. Akibatnya, pustaka dan aplikasi yang beroperasi dengan OpenSSL secara langsung mungkin memiliki pointer yang tidak kompatibel dengan nilai .NET Core-exposed saat meningkatkan dari .NET Core 2.1 atau .NET Core 2.2.

Versi yang diperkenalkan

3.0

Pustaka dan aplikasi yang melakukan operasi langsung dengan OpenSSL perlu berhati-hati untuk memastikan mereka menggunakan versi OpenSSL yang sama dengan runtime .NET Core.

Semua pustaka atau aplikasi yang menggunakan IntPtr atau SafeHandle nilai dari jenis kriptografi .NET Core secara langsung dengan OpenSSL harus membandingkan versi pustaka yang mereka gunakan dengan properti baru SafeEvpPKeyHandle.OpenSslVersion untuk memastikan pointer kompatibel.

Kategori

Kriptografi

API yang Terpengaruh

CryptoStream.Dispose mengubah blok akhir hanya saat menulis

Metode CryptoStream.Dispose ini, yang digunakan untuk menyelesaikan CryptoStream operasi, tidak lagi mencoba mengubah blok akhir saat membaca.

Deskripsi perubahan

Dalam versi .NET sebelumnya, jika pengguna melakukan pembacaan yang tidak lengkap saat menggunakan CryptoStream dalam Read mode, Dispose metode dapat melemparkan pengecualian (misalnya, saat menggunakan AES dengan padding). Pengecualian dilemparkan karena blok akhir dicoba untuk diubah tetapi data tidak lengkap.

Di .NET Core 3.0 dan versi yang lebih baru, Dispose tidak lagi mencoba mengubah blok akhir saat membaca, yang memungkinkan pembacaan yang tidak lengkap.

Alasan untuk berubah

Perubahan ini memungkinkan pembacaan yang tidak lengkap dari aliran kripto ketika operasi jaringan dibatalkan, tanpa perlu menangkap pengecualian.

Versi yang diperkenalkan

3.0

Sebagian besar aplikasi tidak boleh terpengaruh oleh perubahan ini.

Jika aplikasi Anda sebelumnya menangkap pengecualian jika pembacaan tidak lengkap, Anda dapat menghapus blok tersebut catch . Jika aplikasi Anda menggunakan transformasi blok akhir dalam skenario hashing, Anda mungkin perlu memastikan bahwa seluruh aliran dibaca sebelum dibuang.

Kategori

Kriptografi

API yang Terpengaruh

Entity Framework Core

Perubahan pemecahan Inti Kerangka Kerja Entitas

Globalisasi

Peta lokal "C" ke lokal invariant

.NET Core 2.2 dan versi yang lebih lama bergantung pada perilaku ICU default, yang memetakan lokal "C" ke lokal en_US_POSIX. Lokal en_US_POSIX memiliki perilaku kolaborasi yang tidak diinginkan, karena tidak mendukung perbandingan string yang tidak peka huruf besar/kecil. Karena beberapa distribusi Linux menetapkan lokal "C" sebagai lokal default, pengguna mengalami perilaku yang tidak terduga.

Deskripsi perubahan

Dimulai dengan .NET Core 3.0, pemetaan lokal "C" telah berubah untuk menggunakan lokal Invariant alih-alih en_US_POSIX. Lokal "C" untuk pemetaan Invariant juga diterapkan ke Windows untuk konsistensi.

Pemetaan "C" ke budaya en_US_POSIX menyebabkan kebingungan pelanggan, karena en_US_POSIX tidak mendukung operasi pengurutan/pencarian string yang tidak sensitif. Karena lokal "C" digunakan sebagai lokal default di beberapa distro Linux, pelanggan mengalami perilaku yang tidak diinginkan ini pada sistem operasi ini.

Versi yang diperkenalkan

3.0

Tidak ada yang lebih spesifik daripada kesadaran akan perubahan ini. Perubahan ini hanya memengaruhi aplikasi yang menggunakan pemetaan lokal "C".

Kategori

Globalisasi

API yang Terpengaruh

Semua API kolase dan budaya dipengaruhi oleh perubahan ini.

MSBuild

Perubahan nama file manifes sumber daya

Mulai dari .NET Core 3.0, dalam kasus default, MSBuild menghasilkan nama file manifes yang berbeda untuk file sumber daya.

Versi yang diperkenalkan

3.0

Deskripsi perubahan

Sebelum .NET Core 3.0, jika tidak ada LogicalName, , atau DependentUpon metadata yang ditentukan untuk EmbeddedResource item dalam file proyek, MSBuild menghasilkan nama file manifes dalam pola <RootNamespace>.<ResourceFilePathFromProjectRoot>.resourcesManifestResourceName. Jika RootNamespace tidak didefinisikan dalam file proyek, itu default ke nama proyek. Misalnya, nama manifes yang dihasilkan untuk file sumber daya bernama Form1.resx di direktori proyek akar adalah MyProject.Form1.resources.

Mulai dari .NET Core 3.0, jika file sumber daya dikolokasikan dengan file sumber dengan nama yang sama (misalnya, Form1.resx dan Form1.cs), MSBuild menggunakan informasi jenis dari file sumber untuk menghasilkan nama file manifes dalam pola <Namespace>.<ClassName>.resources. Namespace layanan dan nama kelas diekstrak dari jenis pertama dalam file sumber yang dikolokasi. Misalnya, nama manifes yang dihasilkan untuk file sumber daya bernama Form1.resx yang dikolokasi dengan file sumber bernama Form1.cs adalah MyNamespace.Form1.resources. Hal utama yang perlu diperhatikan adalah bahwa bagian pertama dari nama file berbeda dengan versi .NET Core sebelumnya (MyNamespace alih-alih MyProject).

Catatan

Jika Anda memiliki LogicalNamemetadata , ManifestResourceName, atau DependentUpon yang ditentukan pada EmbeddedResource item dalam file proyek, perubahan ini tidak memengaruhi file sumber daya tersebut.

Perubahan yang melanggar ini diperkenalkan dengan penambahan properti ke EmbeddedResourceUseDependentUponConvention proyek .NET Core. Secara default, file sumber daya tidak secara eksplisit tercantum dalam file proyek .NET Core, sehingga file tersebut tidak DependentUpon memiliki metadata untuk menentukan cara menamai file .resources yang dihasilkan. Ketika EmbeddedResourceUseDependentUponConvention diatur ke true, yang merupakan default, MSBuild mencari file sumber yang dikolokasi dan mengekstrak namespace layanan dan nama kelas dari file tersebut. Jika Anda mengatur EmbeddedResourceUseDependentUponConvention ke false, MSBuild menghasilkan nama manifes sesuai dengan perilaku sebelumnya, yang menggabungkan RootNamespace dan jalur file relatif.

Dalam kebanyakan kasus, tidak ada tindakan yang diperlukan di bagian pengembang, dan aplikasi Anda harus terus berfungsi. Namun, jika perubahan ini merusak aplikasi, Anda dapat:

  • Ubah kode Anda untuk mengharapkan nama manifes baru.

  • Pilih keluar dari konvensi penamaan baru dengan mengatur EmbeddedResourceUseDependentUponConvention ke false dalam file proyek Anda.

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

Kategori

MSBuild

API yang Terpengaruh

T/A

Jaringan

Nilai default HttpRequestMessage.Version diubah menjadi 1.1

Nilai System.Net.Http.HttpRequestMessage.Version default properti telah berubah dari 2.0 menjadi 1.1.

Versi yang diperkenalkan

3.0

Deskripsi perubahan

Di .NET Core 1.0 hingga 2.0, nilai System.Net.Http.HttpRequestMessage.Version default properti adalah 1.1. Dimulai dengan .NET Core 2.1, diubah menjadi 2.1.

Dimulai dengan .NET Core 3.0, nomor versi default yang dikembalikan oleh System.Net.Http.HttpRequestMessage.Version properti sekali lagi adalah 1.1.

Perbarui kode Anda jika bergantung pada System.Net.Http.HttpRequestMessage.Version properti yang mengembalikan nilai default 2.0.

Kategori

Jaringan

API yang Terpengaruh

WPF

Mengubah perilaku seret dan letakkan pada editor teks

.NET Core 3.0 memperkenalkan perubahan dalam cara editor teks mengontrol pembuatan System.Windows.DataObject saat menyeret teks ke kontrol lain. Perubahan autoconversion yang dinonaktifkan, menyebabkan operasi menyimpan data sebagai DataFormats.Text atau DataFormats.UnicodeText alih-alih mengonversinya menjadi DataFormats.StringFormat.

Versi yang diperkenalkan

.NET Core 3.0

Kategori

Windows Presentation Foundation

Perilaku sebelumnya

Jenis data saat System.Windows.DataObject menyeret teks dari kontrol editor teks adalah DataFormats.StringFormat.

Perilaku yang baru

Jenis data aktif System.Windows.DataObject saat menyeret teks dari kontrol editor teks adalah DataFormats.Text atau DataFormats.UnicodeText.

Jenis perubahan yang melanggar

Perubahan ini adalah perubahan perilaku.

Alasan untuk berubah

Perubahan ini tidak disengaja.

Perubahan ini dikembalikan dalam .NET 7. Tingkatkan ke .NET 7 atau yang lebih baru.

API yang Terpengaruh

Lihat juga