Geekly articles weekly

Mengumumkan Pratinjau .NET Core 3.0 6

Hari ini, kami mengumumkan .NET Core 3.0 Preview 6 . Ini termasuk pembaruan untuk menyusun rakitan untuk startup yang lebih baik, mengoptimalkan aplikasi untuk ukuran dengan tautan dan perbaikan EventPipe. Kami juga telah merilis gambar Docker baru untuk Alpine di ARM64.





Pembaruan WPF dan Windows Forms


Tim WPF sekarang telah menyelesaikan penerbitan sebagian besar basis kode WPF ke GitHub . Bahkan, mereka hanya menerbitkan sumber untuk lima belas majelis . Bagi siapa pun yang akrab dengan WPF, nama-nama majelis harus sangat akrab.


Dalam beberapa kasus, tes masih di backlog untuk dipublikasikan pada atau sebelum 3,0 GA. Yang mengatakan, kehadiran semua kode ini harus memungkinkan komunitas WPF untuk sepenuhnya berpartisipasi dalam membuat perubahan di WPF. Jelas dari membaca beberapa masalah GitHub bahwa komunitas memiliki simpanan sendiri yang telah menunggu untuk disadari. Tema gelap, mungkin?


Gambar buruh pelabuhan Alpine


Gambar Docker sekarang tersedia untuk .NET Core dan ASP.NET Core di ARM64. Mereka sebelumnya hanya tersedia untuk x64.


Gambar-gambar berikut dapat digunakan dalam Dockerfile , atau dengan docker pull , seperti yang ditunjukkan di bawah ini:


  • docker pull mcr.microsoft.com/dotnet/core/runtime:3.0-alpine-arm64v8
  • docker pull mcr.microsoft.com/dotnet/core/aspnet:3.0-alpine-arm64v8

Perbaikan pipa acara


Pipa Acara sekarang mendukung beberapa sesi. Ini berarti bahwa Anda dapat mengkonsumsi acara dengan EventListener di-proc dan secara bersamaan memiliki klien pipa acara yang tidak dalam proses.


Perf Counters baru ditambahkan:


  • % Waktu dalam GC
  • Gen 0 Ukuran Tumpukan
  • Gen 1 Heap Size
  • Gen 2 Heap Size
  • Ukuran Tumpukan LOH
  • Tingkat alokasi
  • Jumlah majelis dimuat
  • Jumlah ThreadPool Threads
  • Tingkat Kontensi Kunci Monitor
  • Antrean Item Pekerjaan ThreadPool
  • Tingkat Item Pekerjaan yang Diselesaikan ThreadPool

Pasang profiler sekarang diimplementasikan menggunakan infrastruktur Pipa Acara yang sama.


Lihat Bermain dengan penghitung dari David Fowler untuk mendapatkan ide tentang apa yang dapat Anda lakukan dengan event pipe untuk melakukan investigasi kinerja Anda sendiri atau hanya memantau status aplikasi.


Lihat penghitung dotnet untuk menginstal alat penghitung dotnet.


Optimalkan aplikasi .NET Core Anda dengan gambar ReadyToRun


Anda dapat meningkatkan waktu mulai aplikasi .NET Core Anda dengan mengkompilasi rakitan aplikasi Anda sebagai format ReadyToRun (R2R). R2R adalah bentuk kompilasi di masa depan (AOT).


Binari R2R meningkatkan kinerja startup dengan mengurangi jumlah pekerjaan yang perlu dilakukan JIT saat aplikasi Anda memuat. Binari berisi kode asli yang sama dengan apa yang JIT akan hasilkan, memberikan JIT sedikit liburan ketika kinerja paling penting (saat startup). Binari R2R lebih besar karena mengandung kode bahasa perantara (IL), yang masih diperlukan untuk beberapa skenario, dan versi asli dari kode yang sama, untuk meningkatkan startup.


R2R didukung dengan .NET Core 3.0. Itu tidak dapat digunakan dengan versi .NET Core sebelumnya.


Contoh angka kinerja


Berikut ini adalah angka kinerja yang dikumpulkan menggunakan contoh aplikasi WPF . Aplikasi ini diterbitkan sebagai lengkap dan tidak menggunakan tautan tautan (dibahas nanti di pos ini).


Aplikasi IL-only:


  • Waktu mulai: 1,9 detik
  • Penggunaan memori: 69,1 MB
  • Ukuran aplikasi: 150 MB

Dengan gambar ReadyToRun:


  • Waktu mulai: 1,3 detik.
  • Penggunaan memori: 55,7 MB
  • Ukuran aplikasi: 156 MB

Gambar ReadyToRun, dijelaskan


Anda dapat R2R mengkompilasi perpustakaan dan binari aplikasi. Saat ini, perpustakaan hanya bisa dikompilasi R2R sebagai bagian dari aplikasi, bukan untuk pengiriman sebagai paket NuGet. Kami ingin umpan balik lebih lanjut tentang apakah skenario itu penting.


Kumpulan kompilasi AOT telah tersedia sebagai konsep dengan .NET untuk waktu yang lama, kembali ke .NET Framework dan NGEN . NGEN memiliki kelemahan utama, yaitu kompilasi yang harus dilakukan pada mesin klien, menggunakan alat NGEN. Tidak mungkin untuk menghasilkan gambar NGEN sebagai bagian dari pembuatan aplikasi Anda.


Masukkan .NET Core. Muncul dengan crossgen , yang menghasilkan gambar asli dalam format yang lebih baru yang disebut ReadyToRun . Nama tersebut menggambarkan proposisi nilai utamanya, yaitu bahwa gambar asli ini dapat dibangun sebagai bagian dari bangunan Anda dan "siap dijalankan" tanpa ada pekerjaan tambahan pada mesin klien. Itu peningkatan besar, dan juga kemenangan penting bagi perubahan iklim.


Dalam hal kompatibilitas, gambar ReadyToRun mirip dengan rakitan IL, dengan beberapa perbedaan utama.


  • Majelis IL hanya berisi kode IL . Mereka dapat berjalan pada setiap runtime yang mendukung kerangka target yang diberikan untuk perakitan itu. Misalnya perakitan netstandard2.0 dapat berjalan pada .NET Framework 4.6+ dan .NET Core 2.0+, pada sistem operasi apa pun yang didukung (Windows, macOS, Linux) dan arsitektur (Intel, ARM, 32-bit, 64-bit).
  • Majelis R2R berisi IL dan kode asli. Mereka dikompilasi untuk versi runtime .NET Core minimum dan lingkungan runtime (RID) minimum. Misalnya, rakitan netstandard2.0 mungkin dikompilasi R2R untuk .NET Core 3.0 dan Linux x64. Ini hanya akan dapat digunakan dalam konfigurasi yang kompatibel (seperti .NET Core 3.1 atau .NET Core 5.0, di Linux x64), karena berisi kode asli yang hanya dapat digunakan dalam lingkungan runtime tersebut.

Instruksi


Kompilasi ReadyToRun adalah fitur opt-in yang hanya mempublikasikan. Kami telah merilis versi pratinjau dengan .NET Core 3.0 Preview 5.


Untuk mengaktifkan kompilasi ReadyToRun, Anda harus:


  • Setel properti PublishReadyToRun menjadi true .
  • Publikasikan menggunakan RuntimeIdentifier eksplisit.

Catatan: Ketika kumpulan aplikasi dikompilasi, kode asli yang dihasilkan adalah platform dan arsitektur spesifik (itulah sebabnya Anda harus menentukan RuntimeIdentifier yang valid saat penerbitan).


Ini sebuah contoh:


 <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>netcoreapp3.0</TargetFramework> <PublishReadyToRun>true</PublishReadyToRun> </PropertyGroup> </Project>

Dan terbitkan dengan menggunakan perintah berikut:


 dotnet publish -r win-x64 -c Release

Catatan: RuntimeIdentifier juga dapat diatur dalam file proyek.


Catatan: ReadyToRun saat ini hanya didukung untuk aplikasi mandiri . Ini akan diaktifkan untuk aplikasi yang bergantung pada kerangka kerja di pratinjau nanti.


PublishReadyToRunEmitSymbols simbol asli dapat diaktifkan dengan menyetel properti PublishReadyToRunEmitSymbols menjadi true dalam proyek Anda. Anda tidak perlu membuat simbol asli untuk keperluan debugging. Simbol-simbol ini hanya berguna untuk keperluan pembuatan profil.


SDK saat ini mendukung cara untuk mengecualikan majelis tertentu agar tidak dikompilasi ke dalam gambar ReadyToRun. Ini bisa berguna untuk kasus-kasus ketika majelis tertentu tidak benar-benar perlu dioptimalkan untuk kinerja. Ini dapat membantu mengurangi ukuran aplikasi. Ini juga bisa menjadi solusi yang berguna untuk kasus-kasus di mana kompiler ReadyToRun gagal mengkompilasi perakitan tertentu. Pengecualian dilakukan menggunakan grup item PublishReadyToRunExclude. Contoh:


 <ItemGroup> <PublishReadyToRunExclude Include="FilenameOfAssemblyToExclude.dll" /> </ItemGroup>

Kompilasi lintas platform / arsitektur


Kompiler ReadyToRun saat ini tidak mendukung penargetan silang. Anda perlu mengkompilasi target yang diberikan. Misalnya, jika Anda ingin gambar R2R untuk Windows x64, Anda harus menjalankan perintah publish pada lingkungan itu.


Pengecualian untuk ini:


  • Windows x64 dapat digunakan untuk mengkompilasi gambar Windows ARM32, ARM64, dan x86.
  • Windows x86 dapat digunakan untuk mengkompilasi gambar Windows ARM32.
  • Linux x64 dapat digunakan untuk mengkompilasi gambar Linux ARM32 dan ARM64.

Tautan perakitan


.NET core 3.0 SDK hadir dengan alat yang dapat mengurangi ukuran aplikasi dengan menganalisis IL dan memangkas perangkat yang tidak digunakan.


Dengan .NET Core, selalu memungkinkan untuk menerbitkan aplikasi mandiri yang mencakup semua yang diperlukan untuk menjalankan kode Anda, tanpa memerlukan .NET untuk diinstal pada target penyebaran. Dalam beberapa kasus, aplikasi hanya membutuhkan sebagian kecil kerangka kerja agar berfungsi dan berpotensi menjadi lebih kecil dengan memasukkan hanya pustaka yang digunakan.


Kami menggunakan IL linker untuk memindai IL aplikasi Anda untuk mendeteksi kode mana yang sebenarnya diperlukan, dan kemudian memangkas pustaka kerangka kerja yang tidak digunakan. Ini secara signifikan dapat mengurangi ukuran beberapa aplikasi. Biasanya, aplikasi konsol seperti alat kecil paling diuntungkan karena cenderung menggunakan subset kerangka yang cukup kecil dan biasanya lebih mudah menerima pemotongan.


Untuk menggunakan alat ini, atur PublishTrimmed=true di proyek Anda dan publikasikan aplikasi mandiri:


 dotnet publish -r <rid> -c Release

Output terbitkan akan mencakup subset dari pustaka framework, tergantung pada apa yang dipanggil kode aplikasi. Untuk aplikasi helloworld, linker mengurangi ukuran dari ~ 68MB menjadi ~ 28MB.


Aplikasi atau kerangka kerja (termasuk ASP.NET Core dan WPF) yang menggunakan refleksi atau fitur dinamis terkait akan sering rusak ketika dipangkas, karena linker tidak tahu tentang perilaku dinamis ini dan biasanya tidak dapat menentukan jenis kerangka mana yang akan diperlukan untuk refleksi saat dijalankan. Untuk memangkas aplikasi semacam itu, Anda perlu memberi tahu tautan tentang jenis apa saja yang dibutuhkan oleh refleksi dalam kode Anda, dan dalam paket atau kerangka kerja apa pun yang Anda andalkan. Pastikan untuk menguji aplikasi Anda setelah pemotongan.


Untuk informasi lebih lanjut tentang IL Linker, lihat dokumentasi , atau kunjungi repo mono / linker .


Catatan: Dalam versi .NET Core sebelumnya, ILLink.Tasks dikirimkan sebagai paket NuGet eksternal dan menyediakan banyak fungsi yang sama. Ini tidak lagi didukung - perbarui ke 3.0 SDK terbaru dan coba pengalaman baru!


Menggunakan Linker dan ReadToRun Bersama


Linker dan kompiler ReadyToRun dapat digunakan untuk aplikasi yang sama. Secara umum, tautan membuat aplikasi Anda lebih kecil, dan kemudian kompiler siap-jalankan akan membuatnya sedikit lebih besar lagi, tetapi dengan kemenangan kinerja yang signifikan. Perlu pengujian dalam berbagai konfigurasi untuk memahami dampak dari setiap opsi.


Catatan: dotnet / sdk # 3257 mencegah tautan dan ReadyToRun digunakan bersama untuk aplikasi WPF dan Windows Forms. Kami sedang berupaya memperbaikinya sebagai bagian dari rilis .NET Core 3.0.


Sampel hosting asli


Tim baru-baru ini memposting sampel Hosting Asli . Ini menunjukkan pendekatan praktik terbaik untuk hosting .NET Core dalam aplikasi asli.


Sebagai bagian dari .NET Core 3.0, kami sekarang mengekspos fungsionalitas umum ke host asli .NET Core yang sebelumnya hanya tersedia untuk aplikasi yang dikelola .NET Core melalui host .NET Core yang disediakan secara resmi. Fungsionalitas ini terutama terkait dengan memuat perakitan. Fungsionalitas ini akan membuatnya lebih mudah untuk menghasilkan host asli yang dapat memanfaatkan serangkaian fitur lengkap dari .NET Core.


Dukungan HTTP / 2 di HttpClient


HTTP / 2 adalah revisi utama dari protokol HTTP. Beberapa fitur penting dari HTTP / 2 adalah dukungan untuk kompresi header dan stream multiplexing penuh melalui koneksi yang sama. Sementara HTTP / 2 mempertahankan semantik HTTP (header HTTP, metode, dll) itu adalah perubahan dari HTTP / 1.x dalam cara data dibingkai dan dikirim melalui kabel.


HttpClient sekarang menambahkan dukungan untuk membuat permintaan HTTP / 2. Sementara defaultnya tetap HTTP / 1.1, Anda dapat memilih untuk menggunakan HTTP / 2 dengan mengatur versi pada pesan permintaan HTTP Anda.


 var client = new HttpClient() { BaseAddress = new Uri("https://localhost:5001") }; // HTTP/1.1 request using (var response = await client.GetAsync("/")) { Console.WriteLine(response.Content); } // HTTP/2 request using (var request = new HttpRequestMessage(HttpMethod.Get, "/") { Version = new Version(2, 0) }) using (var response = await client.SendAsync(request)) { Console.WriteLine(response.Content); }

Atau, Anda dapat secara default mengirim permintaan HTTP / 2 dengan mengatur properti DefaultRequestVersion di HttpClient .


 var client = new HttpClient() { BaseAddress = new Uri("https://localhost:5001"), DefaultRequestVersion = new Version(2, 0) }; // Defaults to HTTP/2 using (var response = await client.GetAsync("/")) { Console.WriteLine(response.Content); }

Sebagai konsekuensi dari perubahan framing ini, server dan klien perlu menegosiasikan versi protokol yang digunakan. Application-Layer Protocol Negotiation (ALPN) adalah ekstensi TLS yang memungkinkan server dan klien menegosiasikan versi protokol yang digunakan sebagai bagian dari jabat tangan TLS mereka. Meskipun dimungkinkan untuk memiliki pengetahuan sebelumnya antara server dan klien pada protokol, sebagian besar server hanya mendukung ALPN sebagai satu-satunya cara untuk membuat koneksi HTTP / 2. Dengan demikian, HTTP / 2 dinegosiasikan oleh HttpClient hanya pada koneksi TLS.


Dalam skenario pengembangan ketika server dan klien memiliki pengetahuan apriori bahwa keduanya akan berbicara HTTP / 2 tidak terenkripsi, Anda dapat membuat koneksi HTTP / 2 melalui cleartext dengan mengatur sakelar AppContext atau variabel lingkungan ( DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP2UNENCRYPTEDSUPPORT=1 ).


 AppContext.SetSwitch("System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport", true);

Penutupan


Silakan coba fitur-fitur baru. Silakan ajukan masalah untuk bug atau pengalaman menantang yang Anda temukan. Kami ingin umpan baliknya! Anda juga dapat mengajukan permintaan fitur, tetapi kemungkinan besar mereka harus menunggu untuk diimplementasikan sampai rilis berikutnya pada saat ini.


Kami sekarang semakin dekat untuk melengkapi fitur untuk .NET Core 3.0, dan sekarang sedang mentransisikan fokus tim ke kualitas rilis. Kami memiliki beberapa bulan perbaikan bug dan kinerja bekerja di depan. Kami akan menghargai umpan balik Anda saat kami mengerjakan proses itu juga.


Pada catatan itu, kami akan segera beralih cabang master pada .NET Core repos ke rilis besar berikutnya, kemungkinan pada atau segera setelah rilis Preview 7 (Juli).


Terima kasih telah mencoba pratinjau .NET Core 3.0. Kami menghargai bantuan Anda. Pada titik ini, kami fokus untuk mendapatkan rilis final di tangan Anda.



Richard Lander
PM, Tim NET

Source: https://habr.com/ru/post/id456224/

More articles:


All Articles