Bagikan melalui

Apa yang baru dalam ASP.NET Core 3.0

  • Artikel

Artikel ini menyoroti perubahan paling signifikan dalam ASP.NET Core 3.0 dengan tautan ke dokumentasi yang relevan.

Blazor

Blazor adalah kerangka kerja baru di ASP.NET Core untuk membangun antarmuka pengguna web sisi klien interaktif dengan .NET:

  • Buat UI interaktif yang kaya menggunakan C#.
  • Bagikan logika aplikasi sisi server dan sisi klien yang ditulis dalam .NET.
  • Render UI sebagai HTML dan CSS untuk dukungan browser yang luas, termasuk browser seluler.

Blazor skenario kerangka kerja yang didukung:

  • Komponen UI yang dapat digunakan kembali (Razor komponen)
  • Perutean sisi klien
  • Tata letak komponen
  • Dukungan untuk injeksi dependensi
  • Formulir dan validasi
  • Komponen pasokan Razor di Razor pustaka kelas
  • Interop JavaScript

Untuk informasi selengkapnya, lihat ASP.NET Core Blazor.

Blazor Server

Blazor memisahkan logika penyajian komponen dari cara pembaruan UI diterapkan. Blazor Server memberikan dukungan untuk menghosting komponen Razor di server dalam aplikasi ASP.NET Core. Pembaruan UI ditangani melalui sambungan SignalR. Blazor Server didukung di ASP.NET Core 3.0.

Blazor WebAssembly (Pratinjau)

Blazor aplikasi juga dapat dijalankan langsung di browser menggunakan runtime .NET berbasis WebAssembly. Blazor WebAssembly dalam pratinjau dan tidak didukung di ASP.NET Core 3.0. Blazor WebAssembly akan didukung dalam rilis ASP.NET Core di masa mendatang.

Komponen Razor

Blazor aplikasi dibangun dari komponen. Komponen adalah potongan antarmuka pengguna (UI) mandiri, seperti halaman, dialog, atau formulir. Komponen adalah kelas .NET normal yang menentukan logika penyajian UI dan penanganan aktivitas sisi klien. Anda dapat membuat aplikasi web interaktif yang kaya tanpa JavaScript.

Komponen di Blazor biasanya ditulis menggunakan Razor sintaksis, perpaduan alami HTML dan C#. Razor komponen mirip Razor dengan tampilan Pages dan MVC karena keduanya menggunakan Razor. Tidak seperti halaman dan tampilan, yang didasarkan pada model respons permintaan, komponen digunakan khusus untuk menangani komposisi UI.

gRPC

gRPC:

  • Adalah kerangka kerja RPC (panggilan prosedur jarak jauh) berkinerja tinggi yang populer.

  • Menawarkan pendekatan kontrak-pertama yang dipendapatkan untuk pengembangan API.

  • Menggunakan teknologi modern seperti:

    • HTTP/2 untuk transportasi.
    • Buffer Protokol sebagai bahasa deskripsi antarmuka.
    • Format serialisasi biner.

  • Menyediakan fitur seperti:

    • Autentikasi
    • Streaming dua arah dan kontrol alur.
    • Pembatalan dan batas waktu.

Fungsionalitas gRPC di ASP.NET Core 3.0 meliputi:

  • Grpc.AspNetCore: Kerangka kerja ASP.NET Core untuk menghosting layanan gRPC. gRPC pada ASP.NET Core terintegrasi dengan fitur ASP.NET Core standar seperti pengelogan, injeksi dependensi (DI), autentikasi, dan otorisasi.
  • Grpc.Net.Client: Klien gRPC untuk .NET Core yang dibangun berdasarkan HttpClient.
  • Grpc.Net.ClientFactory: integrasi klien gRPC dengan HttpClientFactory.

Untuk informasi selengkapnya, lihat Gambaran Umum untuk gRPC di .NET.

SignalR

Lihat Memperbarui SignalR kode untuk instruksi migrasi. SignalR sekarang menggunakan untuk menserialisasikan System.Text.Json /mendeserialisasi JSpesan ON. Lihat Beralih ke Newtonsoft.Json untuk instruksi memulihkan Newtonsoft.Jsonserializer berbasis.

Di Klien JavaScript dan .NET untuk SignalR, dukungan ditambahkan untuk koneksi ulang otomatis. Secara default, klien mencoba untuk segera terhubung kembali dan mencoba kembali setelah 2, 10, dan 30 detik jika perlu. Jika klien berhasil tersambung kembali, klien akan menerima ID koneksi baru. Koneksi ulang otomatis adalah keikutsertaan:

const connection = new signalR.HubConnectionBuilder()
    .withUrl("/chathub")
    .withAutomaticReconnect()
    .build();

Interval koneksi ulang dapat ditentukan dengan melewati array durasi berbasis milidetik:

.withAutomaticReconnect([0, 3000, 5000, 10000, 15000, 30000])
//.withAutomaticReconnect([0, 2000, 10000, 30000]) The default intervals.

Implementasi kustom dapat diteruskan untuk kontrol penuh interval koneksi ulang.

Jika koneksi ulang gagal setelah interval koneksi ulang terakhir:

  • Klien menganggap koneksi offline.
  • Klien berhenti mencoba menyambungkan kembali.

Selama upaya koneksi ulang, perbarui UI aplikasi untuk memberi tahu pengguna bahwa koneksi ulang sedang dicoba.

Untuk memberikan umpan balik UI saat koneksi terganggu, SignalR API klien telah diperluas untuk menyertakan penanganan aktivitas berikut:

  • onreconnecting: Memberi pengembang kesempatan untuk menonaktifkan UI atau memberi tahu pengguna bahwa aplikasi sedang offline.
  • onreconnected: Memberi pengembang kesempatan untuk memperbarui UI setelah koneksi dibangun kembali.

Kode berikut menggunakan onreconnecting untuk memperbarui UI saat mencoba menyambungkan:

connection.onreconnecting((error) => {
    const status = `Connection lost due to error "${error}". Reconnecting.`;
    document.getElementById("messageInput").disabled = true;
    document.getElementById("sendButton").disabled = true;
    document.getElementById("connectionStatus").innerText = status;
});

Kode berikut menggunakan onreconnected untuk memperbarui UI pada koneksi:

connection.onreconnected((connectionId) => {
    const status = `Connection reestablished. Connected.`;
    document.getElementById("messageInput").disabled = false;
    document.getElementById("sendButton").disabled = false;
    document.getElementById("connectionStatus").innerText = status;
});

SignalR 3.0 dan yang lebih baru menyediakan sumber daya kustom untuk penangan otorisasi saat metode hub memerlukan otorisasi. Sumber daya adalah instans .HubInvocationContext meliputi HubInvocationContext :

  • HubCallerContext
  • Nama metode hub yang sedang dipanggil.
  • Argumen ke metode hub.

Pertimbangkan contoh aplikasi ruang obrolan berikut yang memungkinkan beberapa organisasi masuk melalui Azure Active Directory. Siapa pun dengan akun Microsoft dapat masuk ke obrolan, tetapi hanya anggota organisasi pemilik yang dapat melarang pengguna atau melihat riwayat obrolan pengguna. Aplikasi ini dapat membatasi fungsionalitas tertentu dari pengguna tertentu.

public class DomainRestrictedRequirement :
    AuthorizationHandler<DomainRestrictedRequirement, HubInvocationContext>,
    IAuthorizationRequirement
{
    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context,
        DomainRestrictedRequirement requirement,
        HubInvocationContext resource)
    {
        if (context.User?.Identity?.Name == null)
        {
            return Task.CompletedTask;
        }

        if (IsUserAllowedToDoThis(resource.HubMethodName, context.User.Identity.Name))
        {
            context.Succeed(requirement);
        }

        return Task.CompletedTask;
    }

    private bool IsUserAllowedToDoThis(string hubMethodName, string currentUsername)
    {
        if (hubMethodName.Equals("banUser", StringComparison.OrdinalIgnoreCase))
        {
            return currentUsername.Equals("bob42@jabbr.net", StringComparison.OrdinalIgnoreCase);
        }

        return currentUsername.EndsWith("@jabbr.net", StringComparison.OrdinalIgnoreCase));
    }
}

Dalam kode sebelumnya, DomainRestrictedRequirement berfungsi sebagai kustom IAuthorizationRequirement. HubInvocationContext Karena parameter sumber daya sedang diteruskan, logika internal dapat:

  • Periksa konteks di mana Hub sedang dipanggil.
  • Buat keputusan untuk mengizinkan pengguna menjalankan metode Hub individual.

Metode Hub Individual dapat ditandai dengan nama kebijakan yang diperiksa kode pada run-time. Saat klien mencoba memanggil metode Hub individual, DomainRestrictedRequirement handler menjalankan dan mengontrol akses ke metode . Berdasarkan cara DomainRestrictedRequirement kontrol mengakses:

  • Semua pengguna yang masuk dapat memanggil SendMessage metode .
  • Hanya pengguna yang telah masuk dengan alamat email yang @jabbr.net dapat melihat riwayat pengguna.
  • Hanya bob42@jabbr.net dapat melarang pengguna dari ruang obrolan.
[Authorize]
public class ChatHub : Hub
{
    public void SendMessage(string message)
    {
    }

    [Authorize("DomainRestricted")]
    public void BanUser(string username)
    {
    }

    [Authorize("DomainRestricted")]
    public void ViewUserHistory(string username)
    {
    }
}

DomainRestricted Membuat kebijakan mungkin melibatkan:

  • Di Startup.cs, menambahkan kebijakan baru.
  • Berikan persyaratan kustom DomainRestrictedRequirement sebagai parameter.
  • Mendaftar DomainRestricted dengan middleware otorisasi.
services
    .AddAuthorization(options =>
    {
        options.AddPolicy("DomainRestricted", policy =>
        {
            policy.Requirements.Add(new DomainRestrictedRequirement());
        });
    });

SignalR hub menggunakan Perutean Titik Akhir. SignalR koneksi hub sebelumnya dilakukan secara eksplisit:

app.UseSignalR(routes =>
{
    routes.MapHub<ChatHub>("hubs/chat");
});

Dalam versi sebelumnya, pengembang perlu menghubungkan pengontrol, Razor halaman, dan hub di berbagai tempat. Koneksi eksplisit menghasilkan serangkaian segmen perutean yang hampir identik:

app.UseSignalR(routes =>
{
    routes.MapHub<ChatHub>("hubs/chat");
});

app.UseRouting(routes =>
{
    routes.MapRazorPages();
});

SignalR Hub 3.0 dapat dirutekan melalui perutean titik akhir. Dengan perutean titik akhir, biasanya semua perutean dapat dikonfigurasi di UseRouting:

app.UseRouting(routes =>
{
    routes.MapRazorPages();
    routes.MapHub<ChatHub>("hubs/chat");
});

ASP.NET Core 3.0 SignalR ditambahkan:

Streaming klien-ke-server. Dengan streaming klien-ke-server, metode sisi server dapat mengambil instans baik dari atau IAsyncEnumerable<T>ChannelReader<T>. Dalam sampel C# berikut, UploadStream metode di Hub akan menerima aliran string dari klien:

public async Task UploadStream(IAsyncEnumerable<string> stream)
{
    await foreach (var item in stream)
    {
        // process content
    }
}

Aplikasi klien .NET dapat meneruskan instans IAsyncEnumerable<T> atau ChannelReader<T> sebagai stream argumen metode Hub di UploadStream atas.

Setelah perulangan for selesai dan fungsi lokal keluar, penyelesaian aliran dikirim:

async IAsyncEnumerable<string> clientStreamData()
{
    for (var i = 0; i < 5; i++)
    {
        var data = await FetchSomeData();
        yield return data;
    }
}

await connection.SendAsync("UploadStream", clientStreamData());

Aplikasi klien JavaScript menggunakan SignalRSubject (atau Subjek RxJS) untuk stream argumen metode Hub di UploadStream atas.

let subject = new signalR.Subject();
await connection.send("StartStream", "MyAsciiArtStream", subject);

Kode JavaScript dapat menggunakan subject.next metode untuk menangani string saat diambil dan siap dikirim ke server.

subject.next("example");
subject.complete();

Menggunakan kode seperti dua cuplikan sebelumnya, pengalaman streaming real time dapat dibuat.

Serialisasi ON baru JS

ASP.NET Core 3.0 sekarang menggunakan System.Text.Json secara default untuk JSserialisasi ON:

  • Membaca dan menulis JSON secara asinkron.
  • Dioptimalkan untuk teks UTF-8.
  • Biasanya performa lebih tinggi daripada Newtonsoft.Json.

Untuk menambahkan Json.NET ke ASP.NET Core 3.0, lihat Menambahkan dukungan format ON berbasis JSNewtonsoft.Json.

Direktif baru Razor

Daftar berikut berisi direktif baru Razor :

  • @attribute: Direktif @attribute menerapkan atribut yang diberikan ke kelas halaman atau tampilan yang dihasilkan. Misalnya, @attribute [Authorize].
  • @implements: Direktif @implements mengimplementasikan antarmuka untuk kelas yang dihasilkan. Misalnya, @implements IDisposable.

IdentityServer4 mendukung autentikasi dan otorisasi untuk API web dan SPAs

ASP.NET Core 3.0 menawarkan autentikasi di Aplikasi Halaman Tunggal (SPAs) menggunakan dukungan untuk otorisasi API web. ASP.NET Core Identity untuk mengautentikasi dan menyimpan pengguna dikombinasikan dengan IdentityServer4 untuk menerapkan Koneksi OpenID.

IdentityServer4 adalah kerangka kerja OpenID Koneksi dan OAuth 2.0 untuk ASP.NET Core 3.0. Ini memungkinkan fitur keamanan berikut:

  • Autentikasi sebagai Layanan (AaaS)
  • Akses menyeluruh (SSO) melalui beberapa jenis aplikasi
  • Kontrol akses untuk API
  • Gateway Federasi

Untuk informasi selengkapnya, lihat Identitydokumentasi Server4 atau Autentikasi dan otorisasi untuk SPAs.

Autentikasi Sertifikat dan Kerberos

Autentikasi sertifikat memerlukan:

  • Mengonfigurasi server untuk menerima sertifikat.
  • Menambahkan middleware autentikasi di Startup.Configure.
  • Menambahkan layanan autentikasi sertifikat di Startup.ConfigureServices.
public void ConfigureServices(IServiceCollection services)
{
    services.AddAuthentication(
        CertificateAuthenticationDefaults.AuthenticationScheme)
            .AddCertificate();
    // Other service configuration removed.
}

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    app.UseAuthentication();
    // Other app configuration removed.
}

Opsi untuk autentikasi sertifikat mencakup kemampuan untuk:

  • Terima sertifikat yang ditandatangani sendiri.
  • Periksa pencabutan sertifikat.
  • Periksa apakah sertifikat yang di-proffer memiliki bendera penggunaan yang tepat di dalamnya.

Prinsipal pengguna default dibangun dari properti sertifikat. Prinsipal pengguna berisi peristiwa yang memungkinkan pelengkapan atau mengganti prinsipal. Untuk informasi selengkapnya, lihat Mengonfigurasi autentikasi sertifikat di ASP.NET Core.

Autentikasi Windows telah diperluas ke Linux dan macOS. Di versi sebelumnya, Autentikasi Windows terbatas pada IIS dan HTTP.sys. Dalam ASP.NET Core 3.0, Kestrel memiliki kemampuan untuk menggunakan Negosiasi, Kerberos, dan NTLM di Windows, Linux, dan macOS untuk host yang bergabung dengan domain Windows. Kestrel dukungan skema autentikasi ini disediakan oleh paket NuGet Microsoft.AspNetCore.Authentication.Negosiasi. Seperti halnya layanan autentikasi lainnya, konfigurasikan lebar aplikasi autentikasi, lalu konfigurasikan layanan:

public void ConfigureServices(IServiceCollection services)
{
    services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
        .AddNegotiate();
    // Other service configuration removed.
}

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    app.UseAuthentication();
    // Other app configuration removed.
}

Persyaratan host:

  • Host Windows harus menambahkan Nama Prinsipal Layanan (SPN) ke akun pengguna yang menghosting aplikasi.
  • Komputer Linux dan macOS harus bergabung ke domain.
    • SPN harus dibuat untuk proses web.
    • File keytab harus dibuat dan dikonfigurasi pada komputer host.

Untuk informasi selengkapnya, lihat Mengonfigurasi Autentikasi Windows di ASP.NET Core.

Perubahan templat

Templat UI web (Razor Halaman, MVC dengan pengontrol dan tampilan) memiliki hal berikut yang dihapus:

Templat Angular diperbarui untuk menggunakan Angular 8.

Templat Razor pustaka kelas (RCL) default ke Razor pengembangan komponen secara default. Opsi templat baru di Visual Studio menyediakan dukungan templat untuk halaman dan tampilan. Saat membuat RCL dari templat di shell perintah, teruskan --support-pages-and-views opsi (dotnet new razorclasslib --support-pages-and-views).

Host Umum

Templat ASP.NET Core 3.0 menggunakan .NET Generic Host di ASP.NET Core. Versi sebelumnya menggunakan WebHostBuilder. Menggunakan .NET Core Generic Host (HostBuilder) menyediakan integrasi aplikasi ASP.NET Core yang lebih baik dengan skenario server lain yang tidak spesifik untuk web. Untuk informasi selengkapnya, lihat HostBuilder menggantikan WebHostBuilder.

Konfigurasi host

Sebelum rilis ASP.NET Core 3.0, variabel lingkungan yang diawali dimuat ASPNETCORE_ untuk konfigurasi host Web Host. Dalam 3.0, AddEnvironmentVariables digunakan untuk memuat variabel lingkungan yang diawali dengan DOTNET_ untuk konfigurasi host dengan CreateDefaultBuilder.

Perubahan pada injeksi konstruktor Startup

Host Generik hanya mendukung jenis berikut untuk Startup injeksi konstruktor:

Semua layanan masih dapat disuntikkan langsung sebagai argumen ke Startup.Configure metode . Untuk informasi selengkapnya, lihat Host Generik membatasi injeksi konstruktor Startup (aspnet/Pengumuman #353).

Kestrel

  • Kestrel konfigurasi telah diperbarui untuk migrasi ke Host Generik. Dalam 3.0, Kestrel dikonfigurasi pada penyusun host web yang disediakan oleh ConfigureWebHostDefaults.
  • Adaptor Koneksi ion telah dihapus dari Kestrel dan diganti dengan middleware Koneksi ion, yang mirip dengan HTTP Middleware di alur ASP.NET Core tetapi untuk koneksi tingkat bawah.
  • Lapisan Kestrel transportasi telah diekspos sebagai antarmuka publik di Connections.Abstractions.
  • Ambiguitas antara header dan trailer telah diselesaikan dengan memindahkan header berikutnya ke koleksi baru.
  • API I/O sinkron, seperti HttpRequest.Body.Read, adalah sumber umum kelaparan utas yang menyebabkan crash aplikasi. Dalam 3.0, AllowSynchronousIO dinonaktifkan secara default.

Untuk informasi selengkapnya, lihat Migrasi dari ASP.NET Core 2.2 ke 3.0.

HTTP/2 diaktifkan secara default

HTTP/2 diaktifkan secara default untuk Kestrel titik akhir HTTPS. Dukungan HTTP/2 untuk IIS atau HTTP.sys diaktifkan ketika didukung oleh sistem operasi.

EventCounters berdasarkan permintaan

Hosting EventSource, Microsoft.AspNetCore.Hosting, memancarkan jenis baru EventCounter berikut yang terkait dengan permintaan masuk:

  • requests-per-second
  • total-requests
  • current-requests
  • failed-requests

Perutean titik akhir

Perutean Titik Akhir, yang memungkinkan kerangka kerja (misalnya, MVC) berfungsi dengan baik dengan middleware, ditingkatkan:

  • Urutan middleware dan titik akhir dapat dikonfigurasi dalam alur pemrosesan permintaan .Startup.Configure
  • Titik akhir dan middleware menyusun dengan baik dengan teknologi berbasis ASP.NET Core lainnya, seperti Pemeriksaan Kesehatan.
  • Titik akhir dapat menerapkan kebijakan, seperti CORS atau otorisasi, baik di middleware maupun MVC.
  • Filter dan atribut dapat ditempatkan pada metode di pengontrol.

Untuk informasi lebih lanjut, lihat Perutean di ASP.NET Core.

Pemeriksaan Kesehatan

Pemeriksaan Kesehatan menggunakan perutean titik akhir dengan Host Generik. Di Startup.Configure, panggil MapHealthChecks pembangun titik akhir dengan URL titik akhir atau jalur relatif:

app.UseEndpoints(endpoints =>
{
    endpoints.MapHealthChecks("/health");
});

Titik akhir Pemeriksaan Kesehatan dapat:

  • Tentukan satu atau beberapa host/port yang diizinkan.
  • Memerlukan otorisasi.
  • Memerlukan CORS.

Untuk informasi lebih lanjut, baca artikel berikut:

Pipa di HttpContext

Sekarang dimungkinkan untuk membaca isi permintaan dan menulis isi respons menggunakan System.IO.Pipelines API. Properti HttpRequest.BodyReader menyediakan yang PipeReader dapat digunakan untuk membaca isi permintaan. Properti HttpResponse.BodyWriter menyediakan PipeWriter yang dapat digunakan untuk menulis isi respons. HttpRequest.BodyReader adalah analog dari HttpRequest.Body aliran. HttpResponse.BodyWriter adalah analog dari HttpResponse.Body aliran.

Pelaporan kesalahan yang disempurnakan di IIS

Kesalahan startup saat menghosting aplikasi ASP.NET Core di IIS sekarang menghasilkan data diagnostik yang lebih kaya. Kesalahan ini dilaporkan ke Log Peristiwa Windows dengan jejak tumpukan di mana pun berlaku. Selain itu, semua peringatan, kesalahan, dan pengecualian yang tidak tertangani dicatat ke Log Peristiwa Windows.

Layanan Pekerja dan SDK Pekerja

.NET Core 3.0 memperkenalkan templat aplikasi Layanan Pekerja baru. Templat ini menyediakan titik awal untuk menulis layanan jangka panjang di .NET Core.

Untuk informasi selengkapnya, lihat:

Peningkatan Middleware Header yang Diteruskan

Dalam versi ASP.NET Core sebelumnya, memanggil UseHsts dan UseHttpsRedirection bermasalah saat disebarkan ke Azure Linux atau di belakang proksi terbalik selain IIS. Perbaikan untuk versi sebelumnya didokumenkan dalam Meneruskan skema untuk proksi terbalik Linux dan non-IIS.

Skenario ini diperbaiki di ASP.NET Core 3.0. Host mengaktifkan Middleware Header yang Diteruskan saat ASPNETCORE_FORWARDEDHEADERS_ENABLED variabel lingkungan diatur ke true. ASPNETCORE_FORWARDEDHEADERS_ENABLED diatur ke true dalam gambar kontainer kami.

Peningkatan performa

ASP.NET Core 3.0 mencakup banyak peningkatan yang mengurangi penggunaan memori dan meningkatkan throughput:

  • Pengurangan penggunaan memori saat menggunakan kontainer injeksi dependensi bawaan untuk layanan tercakup.
  • Pengurangan alokasi di seluruh kerangka kerja, termasuk skenario middleware dan perutean.
  • Pengurangan penggunaan memori untuk koneksi WebSocket.
  • Pengurangan memori dan peningkatan throughput untuk koneksi HTTPS.
  • Serializer ON baru yang dioptimalkan dan sepenuhnya asinkron JS.
  • Pengurangan penggunaan memori dan peningkatan throughput dalam penguraian formulir.

ASP.NET Core 3.0 hanya berjalan pada .NET Core 3.0

Pada ASP.NET Core 3.0, .NET Framework bukan lagi kerangka kerja target yang didukung. Proyek yang menargetkan .NET Framework dapat dilanjutkan dengan cara yang didukung penuh menggunakan rilis .NET Core 2.1 LTS. Sebagian besar paket terkait ASP.NET Core 2.1.x akan didukung tanpa batas waktu, di luar periode LTS tiga tahun untuk .NET Core 2.1.

Untuk informasi migrasi, lihat Port kode Anda dari .NET Framework ke .NET Core.

Menggunakan kerangka kerja bersama ASP.NET Core

Kerangka kerja bersama ASP.NET Core 3.0, yang terkandung dalam metapackage Microsoft.AspNetCore.App, tidak lagi memerlukan elemen eksplisit <PackageReference /> dalam file proyek. Kerangka kerja bersama secara otomatis dirujuk saat menggunakan Microsoft.NET.Sdk.Web SDK dalam file proyek:

<Project Sdk="Microsoft.NET.Sdk.Web">

Rakitan dihapus dari kerangka kerja bersama ASP.NET Core

Rakitan yang paling terkenal yang dihapus dari kerangka kerja bersama ASP.NET Core 3.0 adalah:

Untuk daftar lengkap rakitan yang dihapus dari kerangka kerja bersama, lihat Rakitan yang dihapus dari Microsoft.AspNetCore.App 3.0. Untuk informasi selengkapnya tentang motivasi perubahan ini, lihat Melanggar perubahan pada Microsoft.AspNetCore.App di 3.0 dan Melihat perubahan pertama yang masuk ASP.NET Core 3.0.