Runtime: Survei: AOT Asli

Saya tidak dapat menemukan label area terbaik untuk ditambahkan ke masalah ini. Jika Anda memiliki izin menulis, bantu saya belajar dengan menambahkan tepat satu label area .

Sepertinya salah ketik - * 9. Which of these tasks are apart of your production debugging workflow? (Please select all that apply) Mungkin harus "bagian dari"?

Saya sangat senang melihat masalah ini! 😄🚀.

Pertanyaan: untuk pengembang UWP yang telah bekerja dengan .NET Native toolchain, haruskah kami menjawab survei hanya dengan mengatakan bahwa kami belum pernah menggunakan CoreRT sebelumnya, atau karena .NET Native memiliki banyak kesamaan (dan beberapa kode yang dibagikan juga?) dengan CoreRT, haruskah kami hanya menyebutkan ini di catatan dan kemudian menjawab pertanyaan CoreRT lainnya hanya sehubungan dengan pengalaman kami dengan .NET Native? 🤔.

@Sergio0694 terima kasih atas pertanyaan UWP. Saya setuju, saya pikir masuk akal untuk menyebutkan itu di catatan dan membalas penggunaan corert jika Anda telah menggunakan versi open source.

Terima kasih telah memposting survei ini!

Saya juga bingung bagaimana menjawab pertanyaan tertentu sebagai pengembang UWP yang hanya menggunakan .NET Native. Saya memiliki beberapa pendapat tentang .NET Native toolchain UWP tetapi saya tidak benar-benar melihat tempat untuk menuliskannya. Benar-benar baik jika itu di luar cakupan survei ini, tetapi mungkin perlu diklarifikasi.

Saya juga curiga "karena .NET Native adalah default untuk rilis rilis UWP dan diperlukan di Store" mungkin adalah alasan paling umum mengapa orang menggunakan AOT tetapi itu bukan salah satu jawaban yang sudah diisi sebelumnya untuk pertanyaan 5.

Terima kasih telah memasukkan Avalonia dalam opsi GUI :) Kami telah bereksperimen dengan CoreRT+Avalonia sebelumnya dan hasilnya adalah aplikasi GUI asli yang cantik: D meskipun kami belum mempertahankan kompatibilitas sejak sudah 2 tahun ...

Bagian .net yang sering terlupakan adalah pengembangan game, banyak platform yang tidak mengizinkan JIT untuk dijalankan, pikirkan Konsol atau perangkat iOS.
Sangat penting untuk masa depan pengembangan game untuk mendapatkan .net native AOT sebagai warga kelas satu dari ekosistem .net.
Beberapa mesin game menggulung AOT mereka sendiri (misalnya Unity melakukannya dengan il2cpp) tetapi ini adalah kecelakaan kereta yang mutlak.
Jadi solusi resmi akan sangat disambut. Ini bisa menjadi peristiwa yang mengubah industri.
Jangan lupa bahwa industri game menyalip industri film baik dalam keuntungan maupun omset.
Konsol adalah tempat keuntungan utama dibuat.

Opsi yang ada untuk mengoptimalkan aplikasi yang diterbitkan berfungsi dengan baik untuk sebagian besar skenario yang ditargetkan .NET hari ini.

...

AOT sebagian besar penting dalam aplikasi GUI. Di situlah perlu fokus. Saya tidak melihat aplikasi web, layanan, dll. membutuhkan itu

saya tidak setuju. Untuk UX pengguna akhir terbaik, AOT dengan tautan statis diperlukan untuk mesin game , layanan mikro tanpa server, aplikasi GUI desktop, aplikasi iOS dan Android , SPA/perpustakaan sisi klien berbasis WASM , dan alat CLI dasar (~ beberapa MB).

Saya berharap bahwa saya dapat dengan mudah mengkompilasi kode AOT saya ketika mencoba semua skenario di atas dalam C# selama beberapa tahun terakhir dan saya merasa bahwa .NET sangat ketinggalan dibandingkan dengan bahasa berbasis LLVM seperti Rust.

Alasan mengapa opsi penerbitan saat ini tampak "berfungsi dengan baik" adalah karena .NET secara historis tidak cocok untuk skenario di atas dan orang-orang hanya mengimplementasikan AOT mereka sendiri (misalnya: Unity, UWP, Mono) saat menggunakan C#. Solusi AOT parsial seperti itu sebagai gambar asli (misalnya, ReadyToRun) mungkin "membantu" dalam skenario cold start untuk aplikasi server monolitik atau aplikasi klien desktop besar tetapi ukuran binernya masih berkali-kali lebih besar daripada yang akan dihasilkan oleh runtime AOT penuh.

.NET sudah tidak "berfungsi dengan baik" untuk layanan mikro tanpa server/kontainer - ini dapat sangat diuntungkan dari kompilasi AOT, pengurangan ukuran biner, dan ketergantungan minimal .
Solusi ReadyToRun + Tiered Compilation + IL Linker saat ini telah mencapai batas ukuran file yang mengganggu penerapan mandiri, seperti yang direkomendasikan oleh AWS Lambda dalam posting blog mereka.

Masalah sebenarnya adalah bahwa saat ini ada terlalu banyak runtime/generator kode/toolchain/eksperimen yang tersedia dengan kebiasaan mereka sendiri: IL2CPP/Burst (Unity), backend AOT Mono (Xamarin/Blazor/Uno), .NET Native/CoreRT (UWP), Backend LLVM Mono, CrossGen/ReadyToRun (.NET Core), dll. dan tidak dapat diterima bahwa .NET tidak memiliki toolchain kompilasi AOT standar.

Jika semua tim ini menggabungkan upaya rekayasa mereka pada sesuatu yang umum seperti CoreRT, backend Mono LLVM atau dotnet/lilic yang sekarang ditinggalkan, maka AOT akan menjadi pengalaman yang jauh lebih baik bagi pengembang .NET.

AOT dengan tautan statis dapat diakses oleh banyak pengembang sekarang dengan CI/CD untuk massa dan ini bukan hanya gangguan untuk peningkatan kinerja yang kecil lagi.

C# endgame: Kode asli, UI asli, interop cepat dan mudah, ekspor asli, dan API berorientasi kinerja (mis., System.IO.Pipelines, System.Text.Json).

Saya tidak setuju dengan pernyataan yang mengatakan aplikasi web tidak akan mendapat manfaat dari ini. AOT akan sangat membantu dengan beban kerja tanpa server (alias Azure Functions). Belum lagi manfaat dari waktu startup untuk alat CLI.

Saya telah menjawab survei, tetapi sejujurnya saya tidak mendapatkan pertanyaan survei yang terus-menerus ini sejak .NET Core 1.0 dimulai, tanpa arah yang jelas ke mana arahnya.

.NET Native adalah apa yang seharusnya .NET selama ini, kembali ketika proyek Ext-VOS dimulai, dan ada pengalaman dari Singularity dan Midori yang pasti bisa Anda hubungkan, atau bahkan mendapatkan beberapa server internal dengan mereka berjalan.

Bahkan Java telah memutuskan untuk mengejar kemampuan AOT yang hilang, tim tidak menanyakan beban kerja apa yang kami inginkan untuk membuatnya bekerja.

Kami hampir tidak menggunakan NGEN, karena sejak rilis .NET, pembuatan kualitas kodenya tidak pernah ditingkatkan dan alur kerja penerapannya sulit dibandingkan bahasa kompilasi AOT lainnya.

Jadi jika ke depan, AOT dikeluarkan lagi dari .NET menganggap bahwa semua kompetisi dalam bahasa terkelola sekarang berfokus pada rantai alat AOT, dan mereka juga tidak menanyakan alur kerja mana yang ingin kami gunakan kompilernya.

Saya ingin melihat .NET terus berkembang dan menjadi pilihan pertama terlepas dari skenarionya, dan jika ada yang mengambil alih alur kerja di mana Microsoft masih memaksa kita untuk menggunakan C++ bersama .NET, yang bahasa kompilasi AOT lainnya tidak memiliki masalah.

Saya telah menjawab survei, tetapi sejujurnya saya tidak mendapatkan pertanyaan survei yang terus-menerus ini sejak .NET Core 1.0 dimulai, tanpa arah yang jelas ke mana arahnya.

Saya pikir itu adalah hal yang hebat bahwa MS mencoba mendengarkan komunitas, daripada hanya mendikte apa yang kita inginkan.

@jkotas Saya perhatikan bahwa dua tautan berbeda untuk survei ini menyebar, tidak apa-apa?
https://www.surveymonkey.com/r/7THQK5K
https://www.surveymonkey.com/r/SQV8JQK

@texasbruce bertanya kepada sesama pengembang yang menjawab survei serupa mengenai GUI lintas platform, dukungan perkakas WCF dan EF seberapa banyak itu telah membantu.

Jadi, meskipun menyenangkan jika mereka bertanya kepada kami, akan lebih baik ketika tindakan benar-benar terjadi. Bahkan untuk GUI lintas platform masih harus dilihat apakah MAUI akan benar-benar terjadi atau kita mendapatkan Blazor di Widget Web yang didorong sebagai solusi.

Bagi saya satu-satunya solusi AOT yang dapat diterima adalah ketika itu menghasilkan aplikasi asli yang sebenarnya tanpa JIT sama sekali dalam mode rilis (tidak ada solusi berdampingan alias siap dijalankan) dan ketika itu bekerja pada semua¹ .NET proyek pengembang sedang bekerja pada. Ini secara khusus mencakup Winforms dan WPF. Dalam kasus terbaik itu juga harus bekerja mandiri tanpa ketergantungan runtime tanpa membengkak sendiri dari 3mb ke 80mb.

Untuk alasan teknis mungkin ada kasus/apis yang tidak dapat didukung oleh AOT. Mengatakan "pada semua" berarti tidak mendukung semua API tetapi semua jenis proyek .NET Core mendukung: dll / winforms / wpf / winui / console / maui / ... Sesuatu yang mirip dengan perubahan dari .NET Framework ke .NET Core yang memungkinkan sebagian besar pengembang untuk mengambil alih aplikasi mereka yang ada adalah apa yang saya pikirkan.

_Saya juga telah menulis aplikasi di Delphi dan itu mengganggu saya untuk melihat saya baru saja mengkompilasi dan kemudian mengirimkan Delphi tunggal saya yang dapat dieksekusi di tempat lain dan itu hanya berjalan. Dan itu lebih cepat. Hal yang sama berlaku untuk aplikasi C++ ketika dikompilasi dengan cara tertentu. Dan Anda masih dapat men-debug kedua aplikasi dan kedua aplikasi masih menyediakan stacktrace/dump yang berguna saat Anda memutuskan untuk menyertakan PDB. Tetapi untuk alasan keamanan Anda juga dapat memutuskan untuk TIDAK memasukkannya yang kemudian juga berfungsi dengan baik. Itu mengganggu saya untuk bertanya pada diri sendiri mengapa kita tidak bisa memilikinya dengan C #? Ketika saya mendengar tentang rencana AOT, saya mengharapkan INI._

Saya selalu melihat masalah dengan refleksi yang banyak disebutkan, dan saya percaya bahwa sebenarnya tidak masalah jika inti ASP.net menghasilkan executable besar.

Sebagian besar tempat di mana AOT merupakan persyaratan yang sulit adalah hal-hal seperti alat CLI, game, dan aplikasi UI, mereka dapat memilih perpustakaan mana yang akan disertakan dan dapat menghindari beberapa masalah refleksi. Prioritasnya adalah mengaktifkan aplikasi "clean slate".

Saya selalu melihat masalah dengan refleksi yang banyak disebutkan, dan saya percaya bahwa sebenarnya tidak masalah jika inti ASP.net menghasilkan executable besar.

Dengan dirilisnya Blazor WebAssembly, saya pikir ukuran yang dapat dieksekusi dan juga kecepatan eksekusi akan menjadi sangat penting dan itu bisa sangat diuntungkan dari AOT. Tetapi untuk alasan apa pun itu bahkan tidak disebutkan secara khusus dalam survei.

Ya, tolong cantik! Saya sedang mempertimbangkan untuk menggunakan Rust atau CoreRT untuk menjaga keamanan memori dan mendapatkan kecepatan asli & membuat kode saya dapat dipanggil asli. Tetapi akan luar biasa untuk memiliki AOT di .NET, karena sangat kaya dan kuat dan Rust, meskipun fantastis, tidak mudah untuk ditransisikan.

@jkotas Saya perhatikan bahwa dua tautan berbeda untuk survei ini menyebar, tidak apa-apa?

Ya, kami menggunakan tautan SurveyMonkey yang berbeda untuk posting yang berbeda. Semua tautan mengarah ke survei yang sama. Hal ini memungkinkan kita untuk melihat bagaimana distribusi tanggapan bervariasi tergantung di mana orang menemukan survei.

Untuk gamedev kami membutuhkan ini, saya menangguhkan bekerja pada mesin permainan saya https://github.com/amerkoleci/alimer_sharp mendukung mesin asli menggunakan c++, saya memelihara binding untuk DirectX ans vulkan juga, kinerja diperlukan di sini

Untuk gamedev kami membutuhkan ini, saya menangguhkan bekerja pada mesin permainan saya https://github.com/amerkoleci/alimer_sharp mendukung mesin asli menggunakan c++, saya memelihara binding untuk DirectX ans vulkan juga, kinerja diperlukan di sini

Skenario identik di sini , kecuali saya tidak menangguhkannya. Saya suka AOT baik untuk waktu startup yang lebih baik tetapi juga (dan dalam kasus saya, yang lebih penting), kesempatan untuk memiliki kode yang lebih dioptimalkan - Saya baik-baik saja dengan peningkatan 50% dalam waktu pembuatan untuk percepatan 10%, yang jelas tidak t benar-benar sikap JIT

Saya baik-baik saja dengan peningkatan 50% dalam waktu pembuatan untuk percepatan 10%, yang jelas bukan sikap JIT

Ini sebenarnya salah satu alasan sekunder besar saya ingin AOT di .NET daripada beralih ke ekosistem yang berbeda. Saya benar-benar dimanjakan oleh waktu kompilasi yang cepat dari proyek .NET besar dibandingkan dengan proyek C++ atau Rust yang besar.

Saya ingin JIT untuk iterasi cepat selama pengembangan, tetapi AOT setelah saya mengirimkan sesuatu ke pelanggan saya.

Saya telah menggunakan CoreRT membuat perpustakaan asli lintas platform (dan lintas platform).

AOT dengan tautan statis sangat dibutuhkan untuk mesin game di iOS dan platform konsol yang menonaktifkan jit, dan juga menginginkan beberapa mode kompilasi aot:

1. penuh
2. hybrid aot yang mendukung jit + aot atau interpreter + aot run mode
   hybrid aot sangat penting untuk industri game, ini bisa menjadi game changer

AOT dengan tautan statis sangat dibutuhkan untuk mesin game di iOS dan platform konsol yang menonaktifkan jit, dan juga menginginkan beberapa mode kompilasi aot:

1. penuh
2. hybrid aot yang mendukung jit + aot atau interpreter + aot run mode
   hybrid aot sangat penting untuk industri game, ini bisa menjadi game changer

seperti mono di platform iOS, mode run aot+interpreter.

Aot penuh, exe tunggal, runtime independen, dan memotong kode yang tidak perlu itu pasti membuat saya kreygasm XD

Saya sudah menunggu pertanyaan ini selama 10 tahun. Sial, saya punya 5 proyek keren yang mengumpulkan debu di hard drive, karena jika saya melepaskannya, setiap anak dapat membalikkannya, menambahkan sedikit perubahan pada GUI dan menjualnya sebagai milik mereka.

Saya mengembangkan Robocraft, Cardlife dan Gamecraft dengan Unity di platform PC dan tidak pernah perlu menggunakan IL2CPP, kecuali jika diperlukan (baca Xbox one), bahkan untuk server game. Saya pribadi akan melihat campuran kompilasi JIT dan solusi seperti Burst (yang melakukan pekerjaan lebih baik daripada yang pernah saya lakukan menggunakan intrinsik eksplisit) sebagai lebih dari cukup ketika kinerja diperlukan. Namun, saya memahami bahwa AOT diperlukan untuk platform yang memerlukan kode asli sepenuhnya dan untuk platform yang membutuhkan sumber daya perangkat keras. Saya mengerti bagaimana para pengembang platform .net dapat memiliki perasaan yang campur aduk tentang AOT, tetapi saya tidak berpikir itu adalah pilihan jika kita ingin melihatnya diadopsi secara lebih luas dalam pengembangan game. Sejujurnya, saya sedikit takut bahwa Unity memonopoli teknologi seperti IL2CPP dan Burst.

Kami mengembangkan simulator keuangan/ilmiah dengan kinerja tinggi dan skalabilitas tinggi. Simulasi kami dapat berjalan di mana saja dari beberapa menit hingga beberapa hari tergantung pada kerumitan model yang dibuat pengguna.

Karena sifat perangkat lunak simulasi kami, waktu startup hampir tidak pernah menjadi perhatian, serta ukuran perangkat lunak/biner. Dalam hal ini, waktu yang diperlukan untuk menginstal produk juga tidak. Sebagai contoh, itu akan sepenuhnya dapat diterima oleh kami, jika kompilasi adalah bagian dari instalasi, bahkan jika proses seperti itu memakan waktu lama.

Saya akan mengatakan bahwa sekitar 25% dari kode selama proses dibuat secara dinamis, jadi pendekatan hybrid akan lebih disukai; beberapa kombinasi kompilasi AOT dan JIT. Jika bit dinamis harus ditafsirkan, saya pikir banyak manfaat AOT akan berkurang, setidaknya dalam kasus penggunaan kami.

GC adalah masalah nomor satu kami yang menghalangi kami untuk mencapai skalabilitas yang lebih tinggi (misalnya setelah kami mendapatkan sekitar 44 core). Memiliki kompiler yang dapat melakukan optimasi antar-rakitan yang lebih mendalam, in-lining yang agresif, dan analisis pelarian memungkinkan objek yang lebih berumur pendek untuk dialokasikan pada tumpukan alih-alih tumpukan.

Ada banyak tempat di basis kode kami di mana kualitas kode JIT menjadi hambatan terutama dengan alokasi register dan berurusan dengan banyak struktur. Ini memaksa kita untuk menulis kode untuk memanipulasi kompiler JIT untuk melakukan hal yang benar (tarik-menarik yang rapuh, membingungkan, dan sulit untuk dipelihara) atau beralih ke kode asli (dan kita kehilangan banyak manfaat dari kurangnya inlining dan overhead dari transisi GC/PInvoke).

Terkadang peningkatan kecil pada kualitas kode dapat membuat kemenangan gila selama model yang berjalan selama berjam-jam di banyak inti. Bagi kami, JIT telah menjadi sedikit rapuh (bahkan kurang deterministik) dengan kinerja, karena basis kode kami berubah dengan pengembangan. Harapan kami adalah bahwa kompiler AOT dapat mengambil lebih banyak waktu dalam mengkompilasi dan menghasilkan kode kualitas yang jauh lebih tinggi, mengurangi beberapa fluktuasi kinerja yang tidak perlu ini, dan memungkinkan kami untuk menyimpan lebih banyak basis kode kami di C#.

Secara umum, saya ingin melihat lebih banyak investasi baik dalam teknologi JIT maupun AOT.

cc @AndyAyersMS

AOT dengan tautan statis sangat dibutuhkan untuk mesin game di iOS dan platform konsol yang menonaktifkan jit,

Saya sangat setuju di sini. Karena kami membutuhkan solusi untuk masalah ini (kode C# yang berjalan di konsol game untuk proyek non Unity), kami menggunakan rantai alat berbasis Mono-AOT. Tetapi ia memiliki beberapa batasan serius dan tidak berkinerja baik.

Oleh karena itu kami mencari untuk menjalankan CoreRT di 3 konsol game poplar (XBox One; PlayStation 4 dan Nintendo Switch). Prof konsep awal menunjukkan bahwa itu benar-benar berfungsi (masih dengan beberapa keterbatasan) tetapi sudah dengan peningkatan kinerja run time yang signifikan dibandingkan dengan solusi berbasis Mono.

Tetapi dengan situasi NDA di sekitar konsol game, dukungan resmi untuk penggunaan ini menyebabkan alasan yang tepat bahkan lebih jauh daripada mendapatkan AOT asli resmi di tempat pertama.

Bagi kami, JIT telah menjadi sedikit rapuh (bahkan kurang deterministik) dengan kinerja, karena basis kode kami berubah dengan pengembangan.

@ jpapp05 Saya ingin mendengar lebih banyak tentang aplikasi Anda, dan masalah di atas secara khusus, karena ini adalah salah satu perhatian utama saya. Jangan ragu untuk menghubungi saya secara offline (melalui email di profil) jika itu membantu.

Hai @AndyAyersMS , itu akan sangat bagus. Saya akan menghubungi Anda secara offline karena saya dapat berbicara sedikit lebih bebas, tetapi saya senang untuk memposting kembali ringkasan apa pun dari diskusi kami untuk kepentingan orang lain.

Tidak tahu apakah ini bahkan masalah tetapi hanya untuk menyebutkannya di sini.
Fitur penting bagi kami adalah kemampuan untuk memuat dan membongkar rakitan asli secara dinamis saat runtime.

@movedoa lihat NativeLibrary API https://docs.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.nativelibrary?view=netcore-3.1

Masalah terbesar saya adalah biasanya .NET dapat dengan mudah didekompilasi, kecuali dengan UWP Native, setidaknya sejauh yang saya uji (saya harap benar). Tidak dalam pola pikir perusahaan "normal", seseorang akan menaruh banyak IP dalam sebuah proyek yang dapat dengan mudah didekompilasi.
Linux memang keren, tetapi semua aplikasi desktop untuk Windows di dunia perusahaan.

Mungkin untuk mempermudah hidup, beri tanda centang yang berbunyi:
KOMPILASI NATIVE (KHUSUS UNTUK WINDOWS 10 DESKTOP!)
Man, lakukan itu dan saya tidak peduli tentang AOT lagi. Jika berfungsi untuk ASP.NET Core, keren! Jika tidak, saya benar-benar tidak peduli.

Omong-omong, terima kasih telah membuat pertanyaan dan membuat survei, Anda melakukan pekerjaan dengan baik karena Anda meminta pendapat dari orang-orang yang menggunakan teknologi dalam pekerjaan mereka. Saya pikir (sebenarnya saya yakin) Anda masih melewatkan banyak pendapat pengembang desktop yang biasanya tidak terlibat dalam hal ini di Github. Tidak semua orang ingat (atau tahu) bahwa kode .NET dapat dengan mudah didekompilasi dan saya yakin bos mereka akan gila jika mereka tahu : grin:.

Tidak semua orang ingat (atau tahu) bahwa kode .NET dapat dengan mudah didekompilasi

Ssst... Fakta bahwa Rider melakukan ini untuk Anda secara otomatis luar biasa ketika saya mencoba mencari tahu bagaimana sesuatu bekerja di balik layar dalam paket Unity atau pihak ke-3. Tidak sepenting sekarang, dengan banyak kode yang bersumber terbuka di tempat pertama, tetapi Anda mendapatkan apa yang saya maksud.

@jcbeppler Anda salah, itu adalah kesalahpahaman umum tentang bytecode vs asli, ini hanya masalah memiliki alat yang tepat.

https://www.hex-rays.com/products/decompiler/compare/compare_vs_disassembly/

Hex-Rays hanyalah solusi yang mungkin, ada yang lain untuk dipilih.

@MostHated Ya, saya mengerti. Sebenarnya sangat mudah untuk mendekompilasi perangkat lunak di .NET yang seperti open source dan banyak perusahaan tidak ingin perangkat lunak mereka menjadi open source. "Tidak ada yang namanya makan siang gratis"

@pjmlp Saya tahu perbedaan antara decompile vs disassembly. Saya tidak dapat melakukan apa pun terhadap pembongkaran perangkat lunak saya tetapi kompilasi asli dapat membuat perangkat lunak jauh lebih aman karena orang tersebut tidak dapat melakukan dekompilasi yang sangat sederhana. Perangkat lunak yang dibongkar pasti akan terlihat aneh dan kode yang dibongkar bahkan mungkin tidak berjalan dengan benar.

@jcbeppler Anda salah, itu adalah kesalahpahaman umum tentang bytecode vs asli, ini hanya masalah memiliki alat yang tepat.

Saat ini program .NET yang didekompilasi mengungkapkan seluruh kode sumber. Ini bahkan mencakup semua nama metode dan nama variabel. Ini keren untuk debugging dan memungkinkan kita untuk memiliki stacktrace yang "dapat dibaca" ketika pengecualian terjadi. Namun ini adalah kelemahan keamanan yang besar dan alasan mengapa ada pasar yang besar untuk obfuscator .NET.

Aplikasi asli dapat dibongkar. Tapi itu tidak turun untuk mengungkapkan kode sumber C++/Delphi dll. lengkapnya (ada beberapa alat yang mencoba membangun kembali kode sumber ini tetapi hasilnya mengerikan). Apa yang Anda dapatkan adalah kode assembler dan diagram alur kontrol paling banyak. Jika Anda beruntung dan dikirimkan dengan file simbol, Anda juga mendapatkan nama fungsi tetapi dalam mode rilis file simbol ini biasanya tidak disertakan, sekali lagi untuk tujuan keamanan.

Kita bisa tenggelam dalam detail berbicara tentang bagaimana kode asli adalah perlindungan nyata. Menurut pendapat saya ini bukan perlindungan dalam hal cracking (walaupun berkat metode lengkap / nama variabel dan pembuatan sumber C# lengkap, pemeriksaan lisensi dapat dihapus tanpa memerlukan pengetahuan khusus) atau debugging, tetapi perlindungan terhadap pencuri. Alat seperti dnSpy bahkan dapat mengekspor aplikasi .NET ke proyek VS lengkap dengan KLIK TUNGGAL. Tidak ada alat yang bekerja dengan cara yang sama untuk kode asli. Jadi untuk aplikasi komersial, akan menjadi kemenangan besar untuk menghasilkan kode asli, selain fakta bahwa mereka tidak lagi harus membayar ribuan dolar setahun untuk sesuatu yang hanya mengganti nama semua metode dan variabel dalam aplikasi akhir.

Saya penasaran dengan hasil survei ini. Apakah ada rencana untuk mempublikasikannya tentang bagaimana orang memilih?

@Symbai Ini bukan perlindungan terhadap apa pun, karena setiap pengembang Android yang telah mencoba menggunakan NDK sebagai sarana untuk melindungi IP mereka akan memberi tahu Anda. Aplikasi yang Anda sebutkan secara singkat, dapat melakukan hal yang sama dengan satu klik, dan meskipun mereka biasanya menganggap kode C atau C++ sebagai kode sumber asli, mereka cukup baik untuk mencuri algoritme Anda.

Saya ingin AOT, untuk skenario di mana .NET akan kalah jangka panjang melawan Rust, Go, Swift, C++, Java (GraalVM), desktop, konsol, dan aplikasi seluler/IoT di mana waktu startup sangat penting, ada kendala tinggi pada penggunaan memori dan kehilangan kecepatan karena JIT pada beban Majelis tidak dapat ditoleransi, seperti pada beberapa skenario ASP.NET, kode AOT mungkin relevan ketika seseorang menskalakan 100 instans pod K8S mereka.

Di sisi lain, saya juga menemukan relevan untuk menjaga kemampuan JIT, dan meningkatkannya juga, pada skenario di mana JIT adalah jalan yang harus ditempuh.

Ada banyak bahasa yang menawarkan kedua model kompilasi, membiarkan penggunanya memilih dan memilih tergantung pada situasinya, jadi pada dasarnya mari kita pertahankan JIT, dan tingkatkan cerita AOT ke arah .NET Native, sambil melupakan upaya malu-malu bernama NGEN.

@Symbai Ini bukan perlindungan terhadap apa pun, karena setiap pengembang Android yang telah mencoba menggunakan NDK sebagai sarana untuk melindungi IP mereka akan memberi tahu Anda. Aplikasi yang Anda sebutkan secara singkat, dapat melakukan hal yang sama dengan satu klik, dan meskipun mereka biasanya menganggap kode C atau C++ sebagai kode sumber asli, mereka cukup baik untuk mencuri algoritme Anda.

Mencuri algoritme yang dapat saya jalani, tetapi tidak seperti yang diizinkan .NET hari ini (mis. WPF), di mana seseorang memiliki aplikasi lengkap Anda dengan indah dan mudah siap untuk dijalankan sebagai proyek VS. Saya pikir UWP dengan kompilasi Asli melakukan pekerjaan dengan baik, jika seseorang ingin membongkarnya, ok, semoga berhasil! Saya akan selalu menggunakan kompilasi asli, apa pun yang terjadi. Dunia Android yang tidak dapat saya bicarakan, mencoba AOT dengan Xamarin Forms satu kali dan itu benar-benar tidak berfungsi seperti yang saya harapkan.

Saya pikir UWP dengan kompilasi Asli melakukan pekerjaan dengan baik, jika seseorang ingin membongkarnya, ok, semoga berhasil! Saya akan selalu menggunakan kompilasi asli, apa pun yang terjadi. Dunia Android yang tidak dapat saya bicarakan, mencoba AOT dengan Xamarin Forms satu kali dan itu benar-benar tidak berfungsi seperti yang saya harapkan.

Spoiler - orang-orang yang mencoba mendapatkan sumber Anda mungkin mencoba untuk meningkatkan/memperluas/berintegrasi dengan Anda, bukan menipu Anda. Jika mereka mencoba menipu Anda, maka metrik Anda benar-benar konyol.

Jika saya menulis sebuah buku, maka mintalah seseorang untuk menerjemahkannya ke dalam bahasa Jepang sebelum saya menerbitkannya - saya mungkin berpikir bahwa saya sangat pintar, karena saya tidak mengerti bahasa Jepang, begitu pula teman-teman saya. Kenyataannya adalah, ada seluruh negara di luar sana yang bisa membaca buku itu - dan saya tidak melakukan apa-apa selain membodohi diri sendiri jika saya berpura-pura sebaliknya.

Saya mengatakan ini sebagai pengembang yang tidak memiliki pengalaman dengan binari asli yang dibongkar, dan memutuskan untuk merekayasa balik enkripsi dan format data di Star Citizen.

Saya, seseorang yang tidak memiliki pengalaman sebelumnya, membutuhkan waktu dua minggu untuk berubah dari nol , hingga memiliki program yang tidak hanya dapat mendekripsi file data terenkripsi mereka, tetapi juga mengubah format data milik mereka menjadi XML/JSON.

Setelah 2 minggu itu - saya mungkin belum menyiapkan aplikasi lengkap Anda untuk dijalankan sebagai proyek VS - tetapi saya juga menyadari bahwa saya tidak perlu melakukannya. Jauh lebih mudah untuk menyuntikkan kode saya sendiri ke dalam aplikasi yang ada, dan tidak harus berurusan dengan semua kode mereka.

untuk memiliki program yang tidak hanya dapat mendekripsi file data terenkripsi mereka

Enkripsi adalah sesuatu yang sama sekali berbeda. Mendekompilasi GAME VIDEO untuk membuat mod adalah sesuatu yang sama sekali berbeda. Sebagian besar pengembang game tidak keberatan jika penggemar mereka membuat mod, itu lebih menunjukkan semangat dan kecintaan mereka terhadap game. Dan mungkin "enkripsi" sama sekali bukan enkripsi tetapi file hanya dikemas untuk ukuran yang lebih kecil? Karena tidak harus menyimpan ribuan file tunggal di disk. Kinerja juga bisa menjadi alasan... membaca banyak file kecil dari disk lebih lambat daripada membaca satu file besar. Dan setelah 2 minggu Anda dapat membongkar gambar yang dikemas. Anda dapat mengubah teks dalam beberapa file data. Ini bagus tapi bukan alasan mengapa orang seperti saya ingin menyingkirkan JIT.

Masalah yang kita miliki saat ini adalah bahwa kode JIT dapat sepenuhnya didekompilasi untuk menyelesaikan kode sumber, Java memiliki masalah yang sama serta bahasa JIT lainnya. Kode asli dapat dibongkar (ini akan mengubah kode mesin menjadi kode perakitan), aplikasi asli dapat dipecahkan dengan cukup mampu, semua ini benar tetapi kode asli tidak dapat dikompilasi untuk melengkapi kode sumber. Pernahkah Anda melihat alat seperti dnSpy untuk kode C++? Kode Delphi? saya belum. Itu karena tidak mungkin untuk mendapatkan nama variabel dan metode, mereka tidak ada lagi saat dikompilasi dengan benar. Tidak mungkin mengubah pembongkaran menjadi C++ dan menghasilkan proyek yang berfungsi penuh yang dapat Anda kompilasi. Ini pasti terdengar seperti sesuatu yang tidak begitu penting bagi Anda, tetapi ini adalah hal yang besar untuk aplikasi komersial. Kami hanya ingin menghilangkan fakta bahwa aplikasi .NET adalah buku terbuka yang dapat dibaca oleh semua orang tanpa pengetahuan sama sekali. Ketika kami menghabiskan ribuan dolar untuk penelitian, kami tidak ingin semua orang melihatnya dan menyalinnya dalam beberapa detik. Kami ingin menyingkirkan membayar ribuan dolar untuk obfuscator yang hanya bertujuan untuk mengubah nama semua variabel dan nama metode, sehingga orang tidak dapat lagi membuka aplikasi dan mencari "lisensi" untuk segera mendapatkannya. Bukan hanya (tetapi sebagian besar) biaya obfuscator tetapi juga obfuscator menciptakan masalah tambahan. Saya sendiri cukup sering mengalami ini terutama dengan frekuensi rilis .NET Core. Kami harus menunggu beberapa minggu hanya untuk patch yang membuat obfuscator bekerja dengan versi .NET Core terbaru.

Dan sementara Anda menghadapi semua masalah ini sebagai pengembang, Anda juga harus menjelaskannya kepada manajer bisnis Anda. Pada titik tertentu dia mungkin bertanya kepada Anda apakah tidak lebih baik memilih bahasa pemrograman yang berbeda saja.

Dengan C++ dan Delphi Anda tidak memiliki masalah ini . Saya tahu bahwa ini bukan masalah bagi semua orang. Pengembang open source akan menemukan JIT lebih menarik dan berguna. Sulit untuk menjelaskan kepada mereka mengapa seseorang menginginkan kode sumbernya menjadi buku tertutup, ketika mereka percaya buku terbuka lebih baik. Jadi idealnya, kami tidak perlu saling menjelaskan pandangan kami yang sangat berbeda dan AOT hanya akan menjadi sakelar yang dapat Anda aktifkan dalam mode rilis jika Anda mau. Dan jika Anda tidak mau, lanjutkan dengan JIT.

Saya sangat berterima kasih kepada tim .NET yang mengizinkan kami memilih "perlindungan" sebagai alasan mengapa kami menginginkan AOT ❤. Ini menunjukkan bahwa mereka sadar akan kebutuhan beberapa orang. Dan jika jajak pendapat mengungkapkan bahwa orang itu memilihnya, kita mungkin akhirnya memiliki peluang implementasi AOT akan menangani ini dengan cara yang sama seperti kompiler C++. FYI: Saya memasukkannya ke dalam tanda kutip untuk menghindari diskusi lebih lanjut tentang seberapa besar perlindungan AOT sebenarnya, sudut pandangnya sangat luas untuk yang satu ini, seperti yang mungkin sudah kita perhatikan.

Keamanan tidak semua atau tidak sama sekali. Menghapus IL tidak mencegah penyerang yang gigih untuk membalikkan aplikasi. Tapi itu menciptakan rintangan yang relevan dalam arti praktis. Ini adalah pertahanan yang mendalam. Inilah sebabnya mengapa produk obfuscation IL bisa rasional untuk digunakan.

Seorang teman saya telah memecahkan produk .NET dengan mendekompilasi IL ke C# dan membuat modifikasi yang agak sepele. Dia tidak mampu memecahkan aplikasi asli. Ini jauh lebih sulit. Dia juga harus menyerah di hadapan obfuscators IL karena alat decompiler jatuh pada binari tersebut. Sekali lagi, produk tersebut dilindungi dalam arti praktis. Itu berhasil.

@Symbai

Have you ever seen a tool like dnSpy for C++ code? Delphi code?

Hex-Rays melakukan pekerjaan yang baik untuk C, dan memiliki makro untuk membantu proses keputusan.

Memiliki sumber C itu adalah permainan anak-anak untuk mengubahnya menjadi C++ atau Delphi.

Ditambah sekarang kami memiliki AI untuk membantu mereka yang tidak cukup terampil.

Rekayasa Neural Reverse dari Stripped Binaries

Hex-Rays melakukan pekerjaan yang baik untuk C, dan memiliki makro untuk membantu proses keputusan.

Apakah Anda bekerja untuk Hex-Rays atau untuk perusahaan yang menjual perangkat lunak kebingungan? Sepertinya.

Bagaimanapun, bahkan jika Anda mengonversinya ke C, kodenya akan jauh dari arsitektur C# yang bagus. Bahkan jika Anda mendapatkan potongan kode, Anda harus berusaha keras untuk mengubah, meningkatkan, dll....
Jika bagi Anda kompilasi asli tidak relevan, ok. Tetapi bagi banyak orang itu relevan.

BTW: Anda terlihat sangat tertarik dengan kompilasi JIT dan juga Anda tampaknya memiliki banyak pengalaman dalam membongkar perangkat lunak. Saya bertanya-tanya mengapa dan di mana Anda harus menggunakannya?!

Terlepas dari bagaimana perasaan Anda tentang kemudahan dekompilasi IL vs kode mesin, itu tidak mengubah fakta bahwa itu adalah persyaratan nyata di bisnis nyata. (Dan kita bisa berdebat tentang seberapa valid atau tidak validnya persyaratan itu sampai sapi pulang.)

Majikan saya sebelumnya secara eksplisit melarang pengiriman alat .NET atau JVM secara eksternal karena alasan ini. Tepat sebelum saya meninggalkan satu tim meyakinkan petinggi untuk membiarkan mereka mengirimkan alat dengan kebingungan berat yang diterapkan, tetapi sebaliknya kami menulis alat eksternal dalam C++ untuk memenuhi kebijakan perusahaan.

Diskusi ini sudah keluar jalur. Jika Anda semua ingin berdebat tentang apakah AOT relevan untuk perlindungan IP, silakan lakukan di tempat lain.

Hex-Rays melakukan pekerjaan yang baik untuk C, dan memiliki makro untuk membantu proses keputusan.

Apakah Anda bekerja untuk Hex-Rays atau untuk perusahaan yang menjual perangkat lunak kebingungan? Sepertinya.

Bagaimanapun, bahkan jika Anda mengonversinya ke C, kodenya akan jauh dari arsitektur C# yang bagus. Bahkan jika Anda mendapatkan potongan kode, Anda harus berusaha keras untuk mengubah, meningkatkan, dll....
Jika bagi Anda kompilasi asli tidak relevan, ok. Tetapi bagi banyak orang itu relevan.

BTW: Anda terlihat sangat tertarik dengan kompilasi JIT dan juga Anda tampaknya memiliki banyak pengalaman dalam membongkar perangkat lunak. Saya bertanya-tanya mengapa dan di mana Anda harus menggunakannya?!

Sebaliknya, saya memiliki keterampilan untuk merekayasa balik kode asli ke kode sumber yang dapat digunakan lebih lanjut oleh pihak ketiga, jadi saya sepenuhnya menyadari bahwa kompilasi ke kode asli hanyalah rintangan untuk skrip kiddies, yang tampaknya merupakan pemahaman yang hilang. di sini.

EDIT: Juga menghentikan komentar saya. Hanya ingin membalas serangan pribadi.

Cloud Native dan WPF Harus AOT.
Klien Windows tidak ada runtime! tidak ada JIT

Hasil survei telah diposting - https://github.com/dotnet/runtime/issues/41522. Kami sekarang sedang dalam proses menindaklanjuti dengan orang-orang yang memberikan informasi kontak mereka dan memiliki beberapa pertanyaan tindak lanjut tambahan.

AOT dengan tautan statis sangat dibutuhkan untuk mesin game di iOS dan platform konsol yang menonaktifkan jit,

Saya sangat setuju di sini. Karena kami membutuhkan solusi untuk masalah ini (kode C# yang berjalan di konsol game untuk proyek non Unity), kami menggunakan rantai alat berbasis Mono-AOT. Tetapi ia memiliki beberapa batasan serius dan tidak berkinerja baik.

Oleh karena itu kami mencari untuk menjalankan CoreRT di 3 konsol game poplar (XBox One; PlayStation 4 dan Nintendo Switch). Prof konsep awal menunjukkan bahwa itu benar-benar berfungsi (masih dengan beberapa keterbatasan) tetapi sudah dengan peningkatan kinerja run time yang signifikan dibandingkan dengan solusi berbasis Mono.

Tetapi dengan situasi NDA di sekitar konsol game, dukungan resmi untuk penggunaan ini menyebabkan alasan yang tepat bahkan lebih jauh daripada mendapatkan AOT asli resmi di tempat pertama.

@RalfKornmannEnvision Apakah Anda menggunakan port Xamarin Xbox One/PS4 Mono dengan codegen LLVM?

@RalfKornmannEnvision Apakah Anda menggunakan port Xamarin Xbox One/PS4 Mono dengan codegen LLVM?

@lateralusX Karena integrasi dilakukan oleh orang lain, saya tidak tahu detailnya. Tapi sejauh yang saya tahu mereka menggunakan port mono yang disediakan untuk Xbox One/PS4 dan membuat port sederhana untuk Switch. sendiri.

@RalfKornmannEnvision Akan sangat menyenangkan untuk menghubungi dan mendiskusikan pengalaman yang terkait dengan ini. Codegen LLVM memiliki (tergantung pada proyek) efek kinerja yang sangat positif pada kode yang dihasilkan jadi jika itu tidak digunakan (perlu diaktifkan) biasanya ada banyak keuntungan hanya dengan mengaktifkannya. Apakah Anda berada di server perselisihan DotNetEvolution, jika demikian mungkin kita bisa berdiskusi secara offline di sana terkait dengan ini?

@lateralusX Saya cukup yakin anggota tim yang mengerjakan ini telah mengaktifkan codegen LLVM dan mencoba hal-hal lain. Pernyataan terakhir mereka sebelum pindah ke proyek lain adalah bahwa ini adalah yang terbaik yang bisa mereka lakukan.

Sebagai bagian dari penyelidikan saya, saya membuat benchmark dengan komponen inti menggunakan Xamarin Android dan menjalankannya pada perangkat berbasis Tegra X1 untuk melihat apakah kami kehilangan kinerja karena masalah dengan port Switch kustom Mono kami. Sayangnya kinerja proyek Xamarin tidak jauh berbeda dari apa yang kita lihat di Switch.

Saya minta maaf saya tidak berada di server perselisihan ini dan sejujurnya mereka tidak banyak yang saya tahu tentang integrasi MONO saat ini. Dari sudut pandang saya, ini adalah jalan buntu untuk proyek ini. Prototipe CoreRT saat ini (walaupun memiliki lebih sedikit dukungan resmi) sudah jauh lebih unggul dalam hal kinerja dan kegunaan.

@RalfKornmannEnvision Oke, terima kasih atas informasi dan umpan balik Anda, semuanya sangat berharga.