Geekly articles weekly

.NET Core 3.0 (Pratinjau 6) Dirilis

Pekan lalu, .NET Core 3.0 (Pratinjau 6) dirilis . Ini mencakup pembaruan kompilasi perakitan untuk meningkatkan peluncuran, meningkatkan optimasi ukuran aplikasi dengan perbaikan pada tautan dan EventPipe. Kami juga merilis gambar Docker baru untuk Alpine di ARM64.





Pembaruan Formulir WPF dan Windows


Tim WPF telah menyelesaikan proses penerbitan sebagian besar kode WPF di GitHub . Bahkan, mereka hanya menerbitkan kode sumber untuk lima belas build . Bagi mereka yang terbiasa dengan WPF, nama majelis harus sangat akrab.


Dalam beberapa kasus, tes masih dalam tumpukan dan harus diterbitkan pada atau sebelum 3,0 GA. Namun, memiliki semua kode ini harus memungkinkan komunitas WPF untuk sepenuhnya berpartisipasi dalam membuat perubahan ke WPF. Setelah membaca beberapa masalah dengan GitHub, menjadi jelas bahwa komunitas memiliki tumpukan produk baru yang ingin Anda terapkan. Apa pendapat Anda tentang topik gelap?


Gambar Alpine Docker


Gambar Docker sekarang tersedia untuk .NET Core dan ASP.NET Core di ARM64. Sebelumnya, mereka hanya tersedia untuk x64.


Gambar-gambar berikut dapat digunakan di 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

Peningkatan Pipa Acara


Pipa Acara sekarang mendukung multi-profesionalitas.


Penghitung kinerja 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

Bergabung profiler sekarang diimplementasikan menggunakan infrastruktur Pipa Acara yang sama.


Baca Permainan David Fowler dengan Penghitung untuk mendapatkan ide tentang apa yang dapat Anda lakukan dengan pipa acara untuk melakukan penelitian kinerja Anda sendiri atau hanya melacak keadaan aplikasi.


Baca dotnet-counter untuk menginstal alat dotnet-counter.


Optimalkan Aplikasi .NET Core Anda dengan Gambar ReadyToRun


Anda dapat meningkatkan waktu mulai aplikasi .NET Core dengan mengkompilasi pembuatan aplikasi dalam format ReadyToRun (R2R). R2R adalah bentuk kompilasi terkemuka (AOT).


Binari R2R meningkatkan kinerja startup dengan mengurangi jumlah pekerjaan yang perlu dilakukan JIT ketika aplikasi dimuat. Binari berisi kode mesin yang mirip dengan yang dihasilkan oleh JIT, yang memberi JIT istirahat saat kinerja paling penting (saat startup). Binari dalam format R2R lebih besar karena mengandung kode bahasa perantara (IL), yang masih diperlukan untuk beberapa skenario, dan versi mesin dari kode yang sama untuk meningkatkan startup.


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


Contoh Angka Kinerja


Berikut ini adalah gambar yang menunjukkan kinerja sampel aplikasi WPF . Aplikasi ini diterbitkan sebagai standalone dan tidak menggunakan tautan tautan (dibahas nanti dalam artikel ini).


Aplikasi hanya IL:


  • 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

Baca lebih lanjut tentang gambar ReadyToRun


Anda dapat mengkompilasi R2R baik perpustakaan dan file aplikasi biner. Saat ini, perpustakaan hanya dapat dikompilasi ke dalam R2R sebagai bagian dari aplikasi, dan tidak untuk pengiriman sebagai paket NuGet. Kami ingin umpan balik lebih lanjut tentang apakah skenario ini penting.


Kompilasi majelis AOT telah lama tersedia sebagai konsep untuk .NET, kembali ke .NET Framework dan NGEN . Kelemahan utama NGEN adalah kompilasi harus dilakukan pada mesin klien menggunakan alat NGEN. Tidak mungkin menghasilkan gambar NGEN sebagai bagian dari pembuatan aplikasi Anda.


Sekarang .NET Core. Muncul dengan crossgen , yang menghasilkan gambar mesin dalam format ReadyToRun yang baru. Nama tersebut menggambarkan nilai intinya, yaitu bahwa gambar-gambar mesin ini dapat dibuat sebagai bagian dari rakitan Anda dan “siap dijalankan” tanpa ada pekerjaan tambahan pada mesin klien. Ini merupakan peningkatan besar, sekaligus kemenangan penting dalam perang melawan perubahan iklim.


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


  • Majelis IL hanya berisi kode IL . Mereka dapat bekerja di lingkungan runtime yang mendukung infrastruktur target yang ditentukan untuk perakitan ini. Misalnya, netstandard2.0 build dapat berjalan di .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 minimum spesifik .NET Core runtime dan lingkungan runtime (RID). misalnya, netstandard2.0 build dapat dikompilasi R2R untuk .NET Core 3.0 dan Linux x64. Ini hanya akan digunakan dalam konfigurasi ini atau yang kompatibel (misalnya, .NET Core 3.1 atau .NET Core 5.0 di Linux x64), karena berisi kode asli yang hanya dapat digunakan dalam lingkungan runtime ini.

Instruksi


Kompilasi ReadyToRun hanya tersedia untuk publikasi. Versi pratinjau dirilis dalam .NET Core 3.0 (Pratinjau 5).


Untuk mengaktifkan kompilasi ReadyToRun, Anda perlu:


  • Setel nilai properti PublishReadyToRun menjadi true .
  • Posting menggunakan RuntimeIdentifier tepat.

Catatan Ketika build aplikasi dikompilasi, kode asli yang dihasilkan tergantung pada platform dan arsitektur (oleh karena itu, ketika menerbitkan, Anda harus menentukan RuntimeIdentifier yang valid).


Berikut ini sebuah contoh:


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

Dan penerbitan menggunakan perintah berikut:


 dotnet publish -r win-x64 -c Release

Catatan: RuntimeIdentifier dapat diatur dalam file proyek.


Catatan: ReadyToRun saat ini hanya didukung untuk aplikasi yang berdiri sendiri . Ini akan ditambahkan untuk aplikasi yang bergantung pada kerangka kerja dalam pengumuman nanti.


PublishReadyToRunEmitSymbols karakter mesin dapat diaktifkan dengan menyetel properti PublishReadyToRunEmitSymbols menjadi true . Anda tidak perlu membuat karakter mesin untuk keperluan debugging. Karakter-karakter ini hanya berguna untuk keperluan pembuatan profil.


Saat ini, SDK mendukung cara untuk mengeluarkan rakitan tertentu dari kompilasi ke dalam gambar ReadyToRun. Ini dapat berguna dalam kasus-kasus di mana majelis tidak perlu dioptimalkan untuk meningkatkan kinerja. Tidak termasuk majelis dalam hal ini dapat membantu mengurangi ukuran aplikasi. Dalam kasus ketika kompiler ReadyToRun gagal mengkompilasi rakitan tertentu, solusinya mungkin juga untuk menghilangkannya.


Pengecualian dilemparkan menggunakan grup elemen PublishReadyToRunExclude:


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

Kompilasi lintas platform / arsitektur


Kompiler ReadyToRun belum mendukung penargetan silang. Anda perlu mengkompilasi untuk tujuan yang diberikan. Misalnya, jika Anda memerlukan gambar R2R untuk Windows x64, Anda harus menjalankan perintah publish di lingkungan ini.


Pengecualian:


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

Tata letak perakitan


NET core 3.0 SDK dilengkapi dengan alat yang dapat mengurangi ukuran aplikasi dengan menganalisis IL dan menghilangkan build yang tidak digunakan.


Dengan .NET Core, Anda selalu dapat menerbitkan aplikasi mandiri yang mencakup semua yang Anda perlukan untuk menjalankan kode Anda, tanpa harus menginstal .NET pada target penyebaran. Dalam beberapa kasus, aplikasi hanya membutuhkan sebagian kecil kerangka kerja, dan bisa dibuat lebih kecil dengan memasukkan hanya perpustakaan yang digunakan.


Kami menggunakan pembangun IL untuk memindai IL aplikasi Anda untuk menentukan kode apa yang sebenarnya diperlukan, dan kemudian mengecualikan pustaka kerangka kerja yang tidak digunakan. Ini secara signifikan dapat mengurangi ukuran beberapa aplikasi. Sebagai aturan, aplikasi konsol kecil seperti alat mendapatkan manfaat terbesar, karena mereka sering menggunakan himpunan bagian kecil dari kerangka kerja dan biasanya cocok untuk tanam.


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


 dotnet publish -r <rid> -c Release

Output publikasi akan mencakup subset dari perpustakaan infrastruktur, tergantung pada kode aplikasi mana yang digunakan. Untuk aplikasi helloworld, tautan mengurangi ukuran dari ~ 68 MB hingga ~ 28 MB.


Aplikasi atau kerangka kerja (termasuk ASP.NET Core dan WPF) yang menggunakan refleksi atau fungsi dinamis terkait sering rusak ketika memotong karena linker tidak mengetahui perilaku dinamis ini dan biasanya tidak dapat menentukan jenis kerangka kerja apa yang akan diperlukan untuk refleksi saat runtime . Untuk memangkas aplikasi semacam itu, Anda harus memberi tahu tautan tentang jenis apa saja yang diperlukan untuk refleksi dalam kode Anda dan dalam paket atau lingkungan apa pun yang Anda andalkan. Pastikan untuk menguji aplikasi Anda setelah memotong.


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


Catatan: Dalam versi .NET Core sebelumnya, ILLink.Tasks dikirimkan sebagai paket NuGet eksternal dan menyediakan sebagian besar fungsi yang sama. Tidak lagi didukung - tingkatkan ke SDK 3.0 versi terbaru.


Linker dan ReadToRun Linker Sharing


Linker Linker dan ReadyToRun Linker dapat digunakan untuk aplikasi yang sama. Secara umum, penghubung membuat aplikasi Anda lebih kecil, dan kemudian kompiler yang siap dijalankan akan membuatnya sedikit lebih besar lagi, tetapi dengan peningkatan kinerja yang signifikan. Perlu menguji berbagai konfigurasi untuk memahami efek dari setiap opsi.


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


Sampel Hosting Asli


Baru-baru ini menerbitkan sampel Hosting Asli . Ini menunjukkan pendekatan terbaik untuk hosting .NET Core dalam aplikasi asli.


Dalam kerangka. NET Core 3.0, kami sekarang menyediakan fungsionalitas umum untuk layanan .NET Core hosting kami sendiri, yang sebelumnya hanya tersedia untuk aplikasi .NET Core yang dikelola melalui layanan hosting Core NET yang disediakan secara resmi. Fungsionalitas terutama terkait dengan memuat rakitan. Fungsionalitas ini akan membuatnya lebih mudah untuk membuat layanan hosting Anda sendiri yang dapat menggunakan berbagai fitur .NET Core.


Dukungan HTTP / 2 di HttpClient


HTTP / 2 adalah versi utama dari protokol HTTP. Beberapa fitur penting dari HTTP / 2 adalah dukungan kompresi tajuk dan aliran multipleks sepenuhnya melalui satu koneksi. Meskipun HTTP / 2 mempertahankan semantik HTTP (header HTTP, metode, dll.), Ini berbeda dari HTTP / 1.x dalam cara data dikirim.


HttpClient sekarang mendukung permintaan HTTP / 2. Secara default, semuanya juga tetap HTTP / 1.1, tetapi Anda dapat menyisih darinya demi HTTP / 2 dengan menginstal versi menggunakan permintaan HTTP.


 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 mengirim permintaan HTTP / 2 secara default dengan mengatur DefaultRequestVersion ke 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 akibat dari perubahan ini, server dan klien harus menyetujui versi protokol yang digunakan. ALPN (Application-Layer Protocol Negotiation) adalah ekstensi TLS yang memungkinkan server dan klien untuk menegosiasikan versi protokol yang digunakan sebagai bagian dari interaksi mereka. Namun, perlu diingat bahwa sebagian besar server hanya mendukung ALPN sebagai satu-satunya cara untuk membuat koneksi HTTP / 2. Dengan demikian, HTTP / 2 dinegosiasikan oleh HttpClient hanya melalui koneksi TLS.


Dalam skenario pengembangan, ketika server dan klien mengetahui apriori bahwa keduanya akan berbicara HTTP / 2 tanpa enkripsi, 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);

Penyelesaian


Kami akan sangat senang jika Anda mencoba fitur baru. Silakan laporkan masalah atau bug yang Anda temukan. Anda juga dapat mengirim permintaan untuk fitur baru, tetapi implementasinya harus menunggu hingga rilis berikutnya.


Sekarang kami hampir menyelesaikan pekerjaan pada komponen .NET Core 3.0 dan sekarang kami mengalihkan perhatian tim untuk meningkatkan kualitas rilis. Kami memiliki waktu beberapa bulan sebelum perbaikan bug dan peningkatan kinerja.


Ngomong-ngomong, untuk pembaruan besar berikutnya, kita akan mengganti cabang master di repositori .NET Core. Kemungkinan besar ini akan terjadi segera setelah Pratinjau 7 pada bulan Juli.


Terima kasih telah menguji .NET Core 3.0. Kami menghargai bantuan Anda. Saat ini, kami fokus untuk menjadikan versi final yang paling menarik dan berkualitas tinggi untuk Anda.

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

More articles:


All Articles