Runtime: Mendukung distribusi file tunggal

Karena minat, bagaimana inisiatif ini dibandingkan dengan CoreRT? Mereka tampak seperti upaya serupa ?

Apakah ini terkait dengan ' kemungkinan kode pengguna asli ', yaitu apakah ini masih memungkinkan kode untuk dikompilasi JIT, bukan hanya AOT?

Juga, saya berasumsi bahwa komponen runtime (' Kode asli (runtime, Host, bagian asli dari kerangka kerja.. ') akan menjadi yang dari repo CoreCLR?

Anda mengajukan pertanyaan yang bagus, tetapi karena ini masih dalam tahap desain awal, saya belum memiliki jawaban yang bagus.

Karena minat, bagaimana inisiatif ini dibandingkan dengan CoreRT? Mereka tampak seperti upaya serupa?

Kemungkinan akan ada hasil yang agak mirip (satu file), tetapi desainnya mungkin memiliki karakteristik kinerja yang berbeda atau fitur yang berfungsi/tidak berfungsi. Misalnya, desain yang memungkinkan adalah menggabungkan semua file dalam aplikasi mandiri .NET Core ke dalam satu file. Itu 10-an MB dan mungkin mulai lebih lambat, tetapi di sisi lain, itu akan memungkinkan kemampuan penuh CoreCLR, termasuk memuat plugin, pancaran refleksi, dan diagnostik tingkat lanjut. CoreRT dapat dianggap sebagai ujung lain dari spektrum -- ini adalah MB satu digit dan memiliki waktu mulai yang sangat cepat, tetapi dengan tidak memiliki JIT, ia tidak dapat memuat plugin atau menggunakan pancaran refleksi dan waktu pembuatan lebih lambat daripada kebanyakan . Pengembang .NET terbiasa. Saat ini memiliki beberapa batasan lain yang bisa menjadi lebih baik dari waktu ke waktu, tetapi mungkin tidak lebih baik dengan .NET Core 3.0 (mungkin memerlukan anotasi untuk refleksi, kehilangan beberapa skenario interop, diagnostik terbatas di Linux). Ada juga ide di suatu tempat di antara keduanya. Jika orang-orang memiliki pengorbanan yang ingin mereka lakukan/hindari, kami akan penasaran untuk mendengarnya.

Apakah ini terkait dengan 'kemungkinan kode pengguna asli', yaitu apakah ini masih memungkinkan kode untuk dikompilasi JIT, bukan hanya AOT?

Dengan "kode pengguna asli", maksud saya bahwa aplikasi Anda mungkin memiliki beberapa kode asli C++ (baik yang ditulis oleh Anda atau komponen pihak ketiga). Mungkin ada batasan pada apa yang dapat kita lakukan dengan kode itu -- jika dikompilasi menjadi .dll, satu-satunya cara untuk menjalankannya adalah dari disk; jika itu .lib, mungkin saja untuk menautkannya, tetapi itu membawa komplikasi lain.

Juga, saya berasumsi bahwa komponen runtime ('Kode asli (runtime, Host, bagian asli dari kerangka kerja..') akan menjadi yang dari repo CoreCLR?

Berdasarkan semua hal di atas, kami akan mencari tahu repo mana yang terlibat. "Bagian asli dari kerangka kerja" akan menyertakan file asli CoreFX seperti ClrCompression dan Unix PAL.

Distribusi file tunggal dengan cara ini, meskipun memiliki waktu startup yang sedikit lebih lambat, dapat sangat berharga untuk kemudahan penerapan. Saya lebih suka memiliki kemampuan untuk memiliki kekuatan penuh daripada dipaksa untuk menyerahkan sebagian dari itu.

Beberapa skenario yang menarik bagi kami. Bagaimana ini bekerja dalam hal lintas platform?
Saya berasumsi kita akan memiliki "file" terpisah per platform?

Berkenaan dengan kode asli, bagaimana saya dapat memilih komponen asli yang berbeda berdasarkan platform?

Beberapa skenario yang menarik bagi kami. Bagaimana ini bekerja dalam hal lintas platform?
Saya berasumsi kita akan memiliki "file" terpisah per platform?
Berkenaan dengan kode asli, bagaimana saya dapat memilih komponen asli yang berbeda berdasarkan platform?

@ayende , saya kutip dari komentar @morganbr :

desain yang mungkin pada dasarnya adalah menggabungkan semua file dalam aplikasi mandiri .NET Core ke dalam satu file.

Kisah lintas platform saat ini untuk aplikasi mandiri adalah membuat paket penerapan per platform yang ingin Anda targetkan, karena Anda mengirimkan aplikasi dengan runtime, yang merupakan platform khusus.

@morganbr Saya menghargai Anda meluangkan waktu untuk memberikan jawaban yang begitu rinci

Saya akan tertarik untuk melihat ke mana arah desainnya, ini adalah inisiatif yang sangat menarik

Saya punya beberapa pertanyaan untuk orang-orang yang ingin menggunakan file tunggal. Jawaban Anda akan membantu kami mempersempit pilihan kami:

1. Jenis aplikasi apa yang kemungkinan besar akan Anda gunakan? (mis. WPF di Windows? ASP.NET dalam wadah Linux Docker? Sesuatu yang lain?)
2. Apakah aplikasi Anda menyertakan (non-.NET) C++/kode asli?
3. Apakah aplikasi Anda akan memuat plugin atau dll eksternal lainnya yang awalnya tidak Anda sertakan dalam pembuatan aplikasi?
4. Apakah Anda bersedia membangun kembali dan mendistribusikan ulang aplikasi Anda untuk memasukkan perbaikan keamanan?
5. Apakah Anda akan menggunakannya jika aplikasi Anda mulai 200-500 md lebih lambat? Bagaimana dengan 5 detik?
6. Berapa ukuran terbesar yang Anda anggap dapat diterima untuk aplikasi Anda? 5MB? 10? 20? 50? 75? 100?
7. Apakah Anda akan menerima waktu pembuatan rilis yang lebih lama untuk mengoptimalkan ukuran dan/atau waktu mulai? Apa yang paling lama Anda terima? 15 detik? 30 detik? 1 menit? 5 menit?
8. Apakah Anda bersedia melakukan pekerjaan ekstra jika itu akan memotong ukuran aplikasi Anda menjadi dua?

1. Aplikasi konsol/UI di semua platform.
2. Mungkin sebagai komponen pihak ketiga.
3. Mungkin ya.
4. Ya, apalagi jika ada sistem sederhana seperti ClickOnce.
5. Beberapa perlambatan awal dapat ditoleransi. Bisakah poin 3 membantu?
6. Tergantung aset. Halo dunia harus memiliki ukuran di urutan MB.
7. Tidak masalah jika itu hanya produksi.
8. Suka memasukkan hal-hal refleksi ke daftar putih? Ya.

@morganbr , menurut Anda apakah pertanyaan-pertanyaan ini lebih baik ditanyakan kepada audiens yang lebih luas; yaitu, lebih luas orang yang tahu tentang masalah GitHub ini?

Misalnya, desain yang memungkinkan adalah menggabungkan semua file dalam aplikasi mandiri .NET Core ke dalam satu file.

Melihat mengompresnya; atau menggunakan sistem file terkompresi dalam file?

@tpetrina , terima kasih! Poin 3 mencakup beberapa sudut desain:

1. Pengocokan pohon tidak berjalan dengan baik dengan memuat plugin yang belum pernah dilihat oleh pengocok pohon karena dapat menghilangkan kode yang diandalkan plugin.
2. CoreRT saat ini tidak memiliki cara untuk memuat plugin
   Poin 5 lebih lanjut tentang apakah kami akan mengoptimalkan ukuran atau waktu mulai (dan berapa banyak)
   Poin 8, ya saya kebanyakan memikirkan hal-hal refleksi

@TheBlueSky , kami telah menghubungi orang lain juga, tetapi ini membantu untuk mendapatkan masukan dari orang-orang yang bersemangat di komunitas GitHub.

@benaadams , kompresi ada di atas meja, tapi saat ini saya menganggapnya ortogonal dengan desain keseluruhan. Eksperimen ringan menyarankan zip mungkin mendapatkan pengurangan ukuran sekitar 50% dengan biaya beberapa detik waktu startup (dan waktu build). Bagi saya, itu adalah pertukaran yang cukup radikal sehingga jika kita melakukannya, itu harus opsional.

@morganbr beberapa detik waktu startup saat menggunakan kompresi? Saya merasa sulit untuk percaya ketika mempertimbangkan bahwa UPX mengklaim kecepatan dekompresi

~10 MB/dtk pada Pentium 133 kuno, ~200 MB/dtk pada Athlon XP 2000+.

@morganbr , bagi saya jawabannya adalah:

1) Layanan (aplikasi konsol yang menjalankan Kestrel, pada dasarnya). Berjalan sebagai Layanan Windows / Linux Daemon atau di buruh pelabuhan.
2) Ya
3) Ya, biasanya rakitan yang dikelola menggunakan AssemblyContext.LoadFrom . Ini disediakan oleh pengguna akhir.
4) Ya, itulah yang diharapkan. Faktanya, kami sudah menggabungkan seluruh kerangka kerja, jadi tidak ada perubahan dari perspektif itu.
5) Sebagai layanan, kami tidak terlalu peduli dengan waktu startup. 5 detik akan masuk akal.
6) 75MB mungkin batasnya. Banyak tergantung pada ukuran terkompresi yang sebenarnya, karena semua paket dikirimkan terkompresi.
7) Untuk build rilis, waktu build yang lebih lama (bahkan lebih lama) dapat diterima.
8) Ya, tentu saja. Ukuran tidak terlalu penting, tetapi lebih kecil lebih baik.

Sesuatu yang saya tidak melihat disebutkan dan sangat penting adalah kemampuan debugg dari ini.
Saya harap ini tidak akan merusak jejak tumpukan, dan kami ingin dapat menyertakan file pdb atau semacam simbol debug.

Tentang kompresi, pertimbangkan fakta bahwa di hampir semua kasus, mekanisme pengiriman yang sebenarnya sudah dikompresi.
Misalnya, paket nuget.
Pengguna juga cukup berpengalaman dalam membuka ritsleting, jadi itu bukan masalah besar.
Saya pikir Anda dapat melakukan kompresi di samping.

Terima kasih, @ayende! Anda benar bahwa saya seharusnya memanggil debuggability. Saya pikir hanya ada beberapa cara kecil yang dapat memengaruhi debugging:

1. Mungkin tidak mungkin menggunakan Edit dan Lanjutkan pada satu file (karena membutuhkan cara untuk membangun kembali dan memuat ulang Majelis asli)
2. Pembuatan file tunggal mungkin menghasilkan PDB atau beberapa file lain yang diperlukan untuk debugging di luar yang disertakan dengan rakitan Anda.
3. Jika CoreRT digunakan, mungkin ada beberapa fitur debug yang terisi dari waktu ke waktu (terutama di Linux/Mac).

Ketika Anda mengatakan "sertakan file pdb", apakah Anda ingin _di dalam_ file tunggal itu atau hanya kemampuan untuk membuatnya dan menyimpannya jika Anda perlu men-debug pembuatan file tunggal?

1) Bukan masalah bagi kami. E&C tidak relevan di sini karena ini kemungkinan hanya digunakan untuk penerapan yang sebenarnya, bukan hari ke hari.
2) Idealnya, kami memiliki satu file untuk semuanya, termasuk PDB, bukan satu file dan satu set pdbs di samping. Sudah ada opsi PDB yang disematkan, jika itu berhasil, itu akan sangat bagus.
3) Ketika berbicara tentang debug, saya berbicara lebih banyak tentang waktu produksi daripada melampirkan debugger secara langsung. Lebih khusus, tumpukan informasi jejak termasuk file & nomor baris, mampu menyelesaikan simbol saat membaca dump, dll.

1. Terutama layanan tetapi beberapa UI
2. Beberapa melakukannya, tetapi ini tidak mendesak
3. Ya
4. Ya
5. Beberapa detik tidak apa-apa
6. Tidak masalah bagi kami. Jumlah ukuran dll baik-baik saja
7. Idealnya tidak
8. Ukuran bukanlah hal utama bagi kami

Pertanyaan lain bagi kami adalah apakah Anda juga dapat melakukan ini untuk masing-masing komponen (bahkan mungkin dipentaskan)? Misalnya kami memiliki perpustakaan dll yang menggunakan banyak dependensi. Jika kita dapat mengemasnya, itu akan menghemat banyak kesulitan dari manajemen versi, dll. Jika ini pada gilirannya dapat dikemas menjadi exe yang akan lebih bagus?

1. Layanan dan beberapa UI.
2. Tidak saat ini.
3. Ya. Idealnya plugin yang dapat dimuat dari folder dan dimuat ulang saat runtime.
4. Ya
5. Tidak masalah selama kita tidak mendorong 10-15+.
6. Jumlah ukuran DLL, atau serupa.
7. Ya. Untuk waktu pembuatan produksi sebenarnya bukan masalah selama debug/pengujian build cukup cepat.
8. Tergantung, tetapi opsi ini akan berguna.

1. Layanan dan UI.
2. Kadang-kadang.
3. Ya, biasanya.
4. Ya.
5. Yang terbaik adalah kurang dari 5 detik.
6. UI kurang dari 5 detik, Layanan tidak masalah.
7. Waktu pembuatan tidak penting, dan efek pengoptimalan adalah yang paling penting.
8. Ya.

@tpetrina @ayende @bencyoung @Kosyne @expcat Anda menjawab ya untuk pertanyaan 3 ("Apakah aplikasi Anda akan memuat plugin atau dll eksternal lainnya yang awalnya tidak Anda sertakan dalam pembuatan aplikasi Anda?") - dapatkah Anda memberi tahu kami lebih banyak tentang penggunaan Anda kasus?

Nilai jual utama dari distribusi file tunggal adalah hanya ada satu file untuk didistribusikan. Jika aplikasi Anda memiliki plugin dalam file terpisah, nilai apa yang akan Anda dapatkan dari distribusi file tunggal yang memiliki banyak file? Mengapa "app.exe+plugin1.dll+plugin2.dll" lebih baik daripada "app.exe+coreclr.dll+clrjit.dll+...+plugin1.dll+plugin2.dll"?

app.exe + 300+ dll - yang merupakan keadaan saat ini benar-benar canggung.
app.exe + 1-5 dll yang biasanya ditentukan oleh pengguna sendiri jauh lebih mudah.

Skenario kami adalah kami mengizinkan ekstensi tertentu oleh pengguna, jadi kami biasanya hanya menerapkan satu exe dan pengguna dapat menambahkan fungsionalitas tambahan sesuai kebutuhan.

Kami tidak _merencanakan_ untuk melakukan itu, tetapi kami ingin _mampu_ melakukannya jika diperlukan.

@ayende Setuju, sama dengan kami.

Juga, jika kami dapat melakukannya di tingkat dll maka kami dapat mengemas dependensi di dalam rakitan kami sehingga tidak bertentangan dengan rakitan klien. Yaitu dengan memilih versi NewtonSoft.Json Anda saat ini mendefinisikannya untuk semua program, plugin, dan rakitan pihak ketiga dalam folder yang sama, tetapi jika Anda dapat menyematkannya maka pihak ketiga memiliki fleksibilitas dan meningkatkan kompatibilitas versi

Setuju dengan @ayende .

Terimakasih semuanya untuk jawaban Anda! Berdasarkan jumlah orang yang akan menggunakan kode asli atau perlu memuat plugin, kami pikir pendekatan paling kompatibel yang dapat kami kelola adalah tempat yang tepat untuk memulai. Untuk melakukan itu, kita akan menggunakan pendekatan "kemas dan ekstrak".

Ini akan menjadi alat yang pada dasarnya menyematkan semua aplikasi dan file .NET sebagai sumber daya ke dalam ekstraktor yang dapat dieksekusi. Ketika executable berjalan, itu akan mengekstrak semua file tersebut ke dalam direktori sementara dan kemudian berjalan seolah-olah aplikasi diterbitkan sebagai aplikasi file non-tunggal. Itu tidak akan dimulai dengan kompresi, tetapi kami berpotensi menambahkannya di masa mendatang jika diperlukan.

Detail tersulit dari rencana ini adalah tempat untuk mengekstrak file. Kita perlu memperhitungkan beberapa skenario:

• Peluncuran pertama -- aplikasi hanya perlu mengekstrak ke suatu tempat di disk
• Peluncuran berikutnya -- untuk menghindari membayar biaya ekstraksi (mungkin beberapa detik) pada setiap peluncuran, akan lebih baik jika lokasi ekstraksi bersifat deterministik dan memungkinkan peluncuran kedua menggunakan file yang diekstraksi oleh peluncuran pertama.
• Upgrade -- Jika versi baru aplikasi diluncurkan, seharusnya tidak menggunakan file yang diekstrak oleh versi lama. (Kebalikannya juga benar; orang mungkin ingin menjalankan beberapa versi secara berdampingan). Itu menunjukkan bahwa jalur deterministik harus didasarkan pada konten aplikasi.
• Copot pemasangan -- Pengguna harus dapat menemukan direktori yang diekstrak untuk menghapusnya jika diinginkan.
• Toleransi kesalahan -- Jika peluncuran pertama gagal setelah mengekstrak sebagian isinya, peluncuran kedua harus mengulang ekstraksi
• Berjalan lebih tinggi -- Proses yang dijalankan sebagai admin hanya boleh dijalankan dari lokasi yang dapat ditulis oleh admin untuk mencegah proses dengan integritas rendah merusaknya.
• Menjalankan non-elevasi -- Proses yang berjalan tanpa hak admin harus dijalankan dari lokasi yang dapat ditulis pengguna

Saya pikir kita dapat menjelaskan semua itu dengan membangun jalur yang menggabungkan:

1. Direktori dasar yang terkenal (misalnya %LOCALAPPDATA%\dotnetApps di Windows dan lokasi profil pengguna di OS lain)
2. Subdirektori terpisah untuk ditinggikan
3. Identitas aplikasi (mungkin hanya nama exe)
4. Pengidentifikasi versi. Versi nomor mungkin berguna, tetapi tidak cukup karena juga perlu memasukkan versi ketergantungan yang tepat. Panduan atau hash per-build mungkin sesuai.

Bersama-sama, itu mungkin terlihat seperti c:\users\username\AppData\Local\dotnetApps\elevated\MyCoolApp\1.0.0.0_abc123\MyCoolApp.dll
(Di mana aplikasi tersebut bernama MyCoolApp, nomor versinya adalah 1.0.0.0 dan hash/guid-nya adalah abc123 dan diluncurkan lebih tinggi).

Juga akan ada pekerjaan yang diperlukan untuk menyematkan file ke dalam ekstraktor. Di Windows, kami cukup menggunakan sumber daya asli, tetapi Linux dan Mac mungkin memerlukan pekerjaan khusus.

Terakhir, ini mungkin juga memerlukan penyesuaian di host (untuk menemukan file yang diekstrak) dan diagnostik (untuk menemukan DAC atau file lainnya).

CC @swaroop-sridhar @jeffschwMSFT @vitek-karas

Saya merasa obat ini lebih buruk daripada penyakitnya. Jika kita harus berurusan dengan direktori eksternal (berbeda di seluruh OS), memperbarui, mencopot pemasangan, dan sejenisnya, itu bertentangan dengan alasan saya untuk menginginkan fitur ini sejak awal (menjaga semuanya tetap sederhana, portabel, mandiri, dan bersih).

Jika benar-benar harus seperti ini, untuk proyek saya, saya lebih suka satu file utama yang dapat dieksekusi dan file yang belum dibongkar untuk tinggal di direktori di samping file yang dapat dieksekusi itu, atau mungkin kemampuan untuk memutuskan ke mana direktori itu pergi.

Itu hanya saya, saya juga ingin mendengar dari orang lain.

Saya harus setuju di sini, menggunakan direktori yang berbeda dapat memiliki banyak masalah menarik - misalnya Anda menempatkan file konfigurasi di samping exe dan exe ini tidak diambil karena direktori "asli" ada di tempat lain.
Ruang disk bisa menjadi masalah, juga kunci file acak karena kebijakan akses, dll. pp.
Saya ingin menggunakan fitur ini, tetapi tidak jika itu menambahkan sejumlah mode kegagalan yang tidak mungkin dideteksi sebelumnya.

Setuju dengan @Kosyne - Solusi awal yang diusulkan tampaknya hanya mengotomatiskan semacam "pemasang". Jika itu adalah batas dari masalah yang kami coba selesaikan dengan satu eksekutif, maka saya pikir kami semua akan melakukan otomatisasi itu sendiri.

Tujuan utama dari proposal eksekutif tunggal harus dapat menjalankan executable pada sistem yang tidak dikelola. Siapa yang tahu jika ia bahkan memiliki akses tulis ke direktori "instal" tujuan yang dipilih? Seharusnya tidak meninggalkan artefak itu sendiri setelah diluncurkan (tidak secara default).

Sebagai modifikasi kecil pada proposal yang ada untuk memenuhi hal di atas: Bisakah kita tidak membongkar ke dalam memori dan menjalankan dari sana?

Setuju dengan sisa komentar. Membuka ritsleting ke lokasi lain adalah sesuatu yang _sudah_ tersedia.
Kita dapat memiliki zip yang mengekstraksi sendiri yang akan menjalankan nilai yang diekstraksi dengan cukup mudah. Itu tidak menjawab banyak kekhawatiran bahwa ini dimaksudkan untuk menjawab dan hanyalah nama lain untuk instalasi.

Lokasi file itu penting. Misalnya, dalam kasus kami, itu berarti:

• Menemukan file konfigurasi (yang kami buat dengan cepat jika tidak ada dan biarkan pengguna menyesuaikan)
• Menemukan / membuat file data, yang biasanya relatif terhadap exe sumber.
• PID / nama proses harus cocok, untuk memastikan pemantauan / dukungan yang tepat.

Salah satu pengguna kami perlu menjalankan perangkat lunak kami dari DVD, bagaimana cara kerjanya, pada sistem yang mungkin sebenarnya tidak _memiliki_ HD untuk dijalankan.

Saya setuju bahwa akan lebih baik untuk melakukan segala sesuatu dalam memori. Dan kekhawatiran tentang waktu startup tidak terlalu besar, saya akan baik-baik saja membayar ini untuk setiap restart, atau secara manual melakukan langkah untuk meringankannya jika diperlukan.

Masalah lain di sini adalah ukuran sebenarnya. Jika ini hanya (secara efektif) penginstal, itu berarti kita berbicara tentang ukuran file untuk aplikasi yang masuk akal dalam 100-an MB, bukan?

Tampaknya membangun solusi yang diusulkan tidak memerlukan (banyak jika ada) perubahan CLR. Pengguna sudah dapat membangun solusi seperti itu. Tidak ada gunanya menambahkan ini ke CoreCLR. Terutama, karena use case untuk ini cukup sempit dan spesifik.

@GSPP Ini pada dasarnya seperti sesuatu yang dapat saya lakukan hari ini dengan 7z-Extra , saya setuju bahwa jika ini masalahnya, akan lebih baik untuk _not_ memilikinya sama sekali.

Maaf saya terlambat ke pesta ini, saya sampai di sini setelah mengikuti tautan yang diposting di tiket duplikat yang saya lacak.
Setelah membaca komentar terbaru di sini, saya menyesal melihat Anda mempertimbangkan untuk mengemas dan mengekstrak. Ini sepertinya berlebihan, mengapa tidak mulai dengan kemampuan untuk menerapkan SFA untuk aplikasi konsol dasar? Bagi saya tampaknya mungkin untuk membuat aplikasi konsol yang belum sempurna dengan beberapa jaringan, IO, dan beberapa dependensi eksternal (nuget, dll) yang berada dalam satu file.
Saya kira apa yang saya coba katakan adalah bahwa alih-alih mengumpulkan persyaratan semua orang, kumpulkan persyaratan siapa pun dan alih-alih mulai dari yang kecil dengan iterasi pertama yang masuk akal untuk semua orang dan menghasilkan hasil dengan cepat.

Sepertinya ini pada dasarnya sesuatu yang bisa saya lakukan hari ini dengan 7z-Extra

Anda benar bahwa sejumlah solusi agnostik lingkungan pemrograman untuk mengatasi masalah ini ada saat ini. Contoh lain dari banyak: https://www.boxedapp.com/exe_bundle.html

Nilai tambah di sini adalah integrasi ke dotnet tooling sehingga bahkan pengguna non-ahli dapat melakukannya dengan mudah. Pengguna ahli dapat melakukannya hari ini dengan menggabungkan alat yang ada seperti yang telah Anda tunjukkan.

Secara pribadi, saya setuju dengan Anda bahwa tidak jelas apakah kita membuat pilihan yang tepat di sini. Kami memiliki banyak diskusi tentang ini di dalam tim inti.

Menempatkan magang di dalamnya dan keluar dengan alat global (yang direkomendasikan, tetapi tidak didukung) akan berhasil dengan baik, dan dapat cukup mudah untuk dipasang juga.

Secara efektif, kita berbicara tentang dotnet publish-single-file dan itu akan melakukan semua yang diperlukan di belakang layar.

Saya tidak melihat apa pun yang sebenarnya diperlukan oleh kerangka kerja atau runtime untuk mendukung skenario ini, dan dengan menjadikan ini sesuatu yang secara eksplisit di luar kerangka kerja, Anda akan memberi pengguna lebih banyak kebebasan tentang cara memodifikasi ini.
Tidak "perlu" untuk mendapatkan PR (dengan semua upacara terkait, kekompakan mundur, keamanan, dll) yang akan Anda dapatkan jika Anda ingin membuat perubahan pada kerangka kerja.
Anda hanya membayar proyek sampingan umum dan menggunakannya.

Perhatikan bahwa sebanyak saya menginginkan fitur ini, saya lebih suka tidak memiliki sesuatu (yang berarti _selalu_ akan ada) yang dapat dilakukan dengan baik dari luar.

Saya ingin mengajukan pertanyaan tingkat yang lebih tinggi: Apa motivasi utama bagi pelanggan yang menginginkan distribusi file tunggal?
Apakah itu terutama:

1. Kemasan? Jika demikian, terlepas dari apakah solusinya adalah kotak masuk atau alat pihak ketiga, karakteristik apa yang paling penting?
   a) Waktu mulai (di luar run pertama)
   b) Kemampuan untuk berjalan di lingkungan yang tidak dapat ditulis
   c) Tidak meninggalkan file setelah dijalankan
   d) Tidak harus menjalankan penginstal
   2) Kinerja?
   a) Kecepatan (penautan statis kode asli, menghindari banyak pustaka, optimasi lintas-modul, dll.)
   b) Ukuran kode (hanya perlu satu sertifikat, goyangan pohon, dll)
   3) Ada yang lain?

Saya agak khawatir bahwa fitur ini dibaca oleh beberapa orang sebagai tidak begitu penting, atau setidaknya mungkin bukan tujuan yang baik untuk disertakan dalam kumpulan fitur inti di sini. Saya hanya ingin menegaskan kembali bahwa saya pikir itu akan sangat kuat untuk aplikasi apa pun yang bertindak sebagai layanan atau sub-modul dari aplikasi yang lebih besar. Salah satu yang Anda, penulisnya, bahkan mungkin bukan pengembangnya. Saya tidak ingin harus meneruskan persyaratan ketergantungan yang hanya dapat diselesaikan dengan instalasi (otomatis atau lainnya), atau artefak pasca-eksekusi pada disk yang mungkin memerlukan peningkatan keamanan tambahan oleh pengguna, dll.
Saat ini, .NET bukanlah pilihan yang baik untuk masalah khusus ini. Tapi bisa jadi (Dan seharusnya IMO).

Eksekusi yang dikompilasi harus:

• Kemas semua dependensi yang relevan
• Tidak memiliki artefak eksekusi (Tidak ada penulisan disk)

Re @swaroop-sridhar Saya berani mengatakan setiap aplikasi akan memiliki urutan kebutuhan kinerja yang unik dan jadi saya membayangkan pendekatan terbaik setelah menangani solusi inti adalah dengan memilih buah yang menggantung rendah dan pergi dari sana.

@swaroop-sridhar Bagi saya, ini tentang pengemasan dan kemudahan penggunaan bagi pengguna akhir.
Tidak perlu berurusan dengan instalasi hal-hal di seluruh sistem, cukup klik dan jalankan.

Ini penting karena kami mengizinkan perangkat lunak kami untuk disematkan, dan satu file tambahan jauh lebih mudah untuk dikelola.

@strich Intinya tentang penyematan itu bagus. Kami biasanya digunakan sebagai komponen dalam arsitektur layanan mikro, dan mengurangi overhead penerapan akan membuatnya lebih mudah.

Masalahnya bukan apa atau tidak ini adalah fitur penting. Masalahnya adalah apa pun solusi yang diusulkan (pada dasarnya zip hal-hal, pada titik ini) diperlukan untuk menjadi _in the core_.
Hal-hal yang ada di inti memiliki standar perubahan yang jauh lebih tinggi. Memiliki ini sebagai alat eksternal akan lebih baik, karena lebih mudah untuk dimodifikasi dan diperluas.

Sejujurnya, saya lebih suka melihat opsi yang lebih baik sama sekali. Misalnya, dimungkinkan untuk memuat dll dari memori, alih-alih file (memerlukan beberapa pekerjaan, tetapi mungkin).
Jika itu terjadi, Anda dapat menjalankan _seluruh_ hal murni dari memori, dengan membongkar yang dilakukan ke memori murni dan tidak ada hits disk.

Itu adalah sesuatu yang harus masuk ke inti, karena kemungkinan besar akan memerlukan modifikasi pada runtime untuk mengaktifkannya.
Dan itu akan berharga di dalam dan di luar dirinya sendiri. Dan bukan sesuatu yang bisa kita lakukan saat ini.

Jadi contoh yang baik adalah dengan melihat pengalaman alat Go seperti Konsul Hashicorp. Satu file exe yang dapat Anda jatuhkan ke mesin mana pun saat dijalankan. Tanpa penginstal, tanpa menyalin folder, tanpa berburu file konfigurasi dalam daftar ratusan file, hanya pengalaman pengguna akhir yang sangat menyenangkan.

Bagi kami, saya tidak yakin pendekatan dalam memori akan berfungsi karena kami juga ingin ini berfungsi untuk plugin dll (jadi menjatuhkan plugin juga akan menjadi satu file daripada semua dependensinya), tetapi setiap kemajuan akan menjadi baik. Kami telah melihat Fody.Costur dan itu berfungsi dengan baik untuk beberapa hal, tetapi kami memiliki masalah dengan .NET Core untuk itu.

Jadi contoh yang baik adalah dengan melihat pengalaman alat Go seperti Konsul Hashicorp

Eh, untuk alat seperti konsul solusi idealnya adalah corert, bukan improvisasi self-extract ini.

@mikedn Kenapa begitu? Saya tidak melihat apa yang harus dilakukan kompilasi AOT atau JIT dengan metode penerapan?

Saya ingin mendukung kata-kata @strich , penyebaran file tunggal akan menjadi angin segar untuk penerapan arsitektur layanan mikro, serta untuk aplikasi konsol apa pun yang — atau setidaknya memulai kehidupannya sebagai — alat kecil dengan baris perintah saklar.

Mengapa itu? Saya tidak melihat apa yang harus dilakukan kompilasi AOT atau JIT dengan metode penerapan?

Karena itu memberi Anda apa yang Anda inginkan - satu file exe yang dapat Anda letakkan di mesin apa pun (yah, mesin apa pun yang memiliki OS yang sesuai, bagaimanapun juga, ini adalah file asli) dan jalankan. Itu juga cenderung menggunakan lebih sedikit sumber daya, yang untuk agen seperti konsul adalah hal yang baik. Ini hampir setara dengan apa yang Go berikan kepada Anda, lebih dari solusi ekstrak sendiri.

@mikedn kurasa, tapi

1) Belum benar-benar ada dalam bentuk produksi (sejauh yang saya tahu)!
2) Kami menggunakan banyak fitur dinamis (generasi IL, refleksi sewenang-wenang)
3) Kami masih ingin dapat menambahkan plugin (sekali lagi idealnya dipadatkan)

Lihat karena masalah ini tentang menanyakan orang apa yang mereka inginkan, kami hanya memberikan pendapat kami! Kami tidak benar-benar ingin harus beralih ke model runtime yang berbeda hanya untuk mendapatkan manfaat ini. Bagi saya itu masalah ortogonal

Saya tidak melihat apa yang harus dilakukan kompilasi AOT atau JIT dengan metode penerapan?

Tanpa JIT, lebih mudah untuk mendapatkan hal-hal seperti cerita debug dengan cukup baik. Bagian JIT membuat masalah menjadi lebih sulit, itulah sebabnya Anda tidak akan menemukannya di Go. Ini adalah rekayasa, jadi Anda dapat melemparkan lebih banyak insinyur pada masalah yang lebih sulit dan hidup dengan kompleksitas baru, atau membatasinya di tempat lain. Self-extractor adalah tentang melingkupinya karena jumlah insinyur dengan keterampilan yang diperlukan terbatas.

Orang dengan proyek yang lebih mirip proyek Go (tidak ada persyaratan JIT) mungkin cukup senang dengan CoreRT, jika mereka setuju dengan label "eksperimental" di atasnya. Sangat mudah untuk mencoba hari ini. Ini menggunakan pengumpul sampah yang sama, pembuat kode, CoreFX, dan sebagian besar CoreLib sebagai CoreCLR penuh, dan menghasilkan executable kecil (satu digit megabyte) yang mandiri.

Itu belum benar-benar ada dalam bentuk produksi (sejauh yang saya tahu)!

Ya, komentar saya kebanyakan ditujukan pada orang-orang MS : nyengir:. Mereka memiliki semua proyek/gagasan paralel, terkait, yang sedang berjalan (corert, illinker) dan sekarang mereka menambahkan satu lagi, hal yang diekstraksi sendiri ini, seperti yang telah ditunjukkan oleh banyak orang, ini sedikit "meh, kita bisa melakukannya diri kita sendiri" semacam itu. Dan itu datang dengan kerugian juga, seperti mengekstrak file ke direktori "tersembunyi".

Kami menggunakan banyak fitur dinamis (generasi IL, refleksi sewenang-wenang)

Itu adalah sesuatu yang mungkin ingin dipikirkan kembali oleh komunitas secara keseluruhan. Tentu berguna untuk dapat melakukan itu tetapi itu agak bertentangan dengan keinginan lain seperti penyebaran file tunggal. Anda masih bisa mendapatkan penyebaran file tunggal tetapi itu cenderung dikenakan biaya - file yang agak besar. Jika Anda baik-baik saja dengan itu maka itu baik-baik saja. Tetapi dalam pengalaman saya, semakin besar file, semakin tidak berguna aspek "file tunggal".

@MichalStrehovsky yakin, ada opsi berbeda. Namun bagi kami, kami tidak dapat menggunakan eksperimental (meyakinkan sudah waktunya untuk pindah ke .NET Core cukup sulit) dan saya rasa mengekstraksi ke folder temp juga tidak akan berhasil dalam kasus kami. Namun kasus terburuknya adalah kami tetap berjalan apa adanya dan tidak menggunakan fitur ini.

Itu adalah sesuatu yang kita inginkan jika berjalan seperti yang kita inginkan :)

@mikedn saya setuju. Beberapa solusi paralel bahkan lebih membingungkan. Saya pikir solusi ideal kami akan menjadi semacam pendekatan super ILLinker/weaver tapi saya senang membiarkan ini bermain dan melihat di mana kita berakhir.

Saya sangat senang dengan pendaratan fungsi ini, tetapi saya juga tidak senang dengan proposal awal yang Anda posting di @morganbr. Jawaban saya untuk daftar pertanyaan yang Anda ajukan mirip dengan apa yang diposting orang lain (jadi saya pikir ada serangkaian kemampuan yang diinginkan), tetapi IMHO solusi 'membongkar ke disk' yang diusulkan sama sekali tidak seperti yang saya harapkan diimplementasikan dan seperti yang dikatakan orang lain hampir lebih buruk daripada 'penyakit'. @jkotas

Saya setuju dengan @strich dan @ayende
Eksekusi yang dikompilasi harus:
Kemas semua dependensi yang relevan
Tidak memiliki artefak eksekusi (Tidak ada penulisan disk)

Memuat .dlls dari memori alih-alih disk mungkin tidak mudah, tetapi itulah jenis kemampuan yang IMO akan bernilai keahlian mendalam dari pengembang tingkat rendah MSFT (dan kemudian memanfaatkan CoreClr) vs proposal di atas yang hanya dapat diimplementasikan sebagai alat eksternal (dan sudah ada, lihat https://github.com/dgiagio/warp). Jika ini tercapai, saya bertanya-tanya berapa banyak perbedaan waktu antara putaran pertama dan berikutnya? Untuk inspirasi/contoh, saya pikir Linux 3.17+ memiliki memfd_create yang dapat digunakan oleh dlopen.

Pada topik lain, saya bertanya-tanya apakah persyaratan untuk mendukung plugin terlalu mengindeks proposal desain? Apakah layak untuk membuat fungsi ini ikut serta, sehingga hanya orang-orang yang membutuhkan kemampuan ini yang terkena potensi hukuman (kurangnya pohon gemetar, dll.) dan semua orang (mayoritas yang signifikan?) akan mendapatkan pengurangan ukuran yang dapat digunakan, manfaat perf(?)

Melangkah mundur @swaroop-sridhar @MichalStrehovsky , saya dapat melihat dua kasus penggunaan luas yang mungkin memiliki tujuan/keinginan yang cukup berbeda untuk membuatnya sulit untuk mengakomodasi semua orang dengan satu solusi:

• Perkakas CLI idealnya ingin berjalan cepat setiap saat, dapat didistribusikan kecil; mungkin lebih cocok untuk CoreRT?
• microservice mungkin dapat mentolerir first-run yang lebih lama (idealnya <1s), dapat didistribusikan lebih besar, sebagai ganti fungsionalitas yang lebih kaya seperti JIT dan fitur kode dinamis.

Saya harap braindump ini masuk akal, saya tidak mencoba menjadi brengsek, tetapi hanya memberikan umpan balik karena saya sangat tertarik dengan topik ini. Terima kasih atas semua kerja keras Anda, dan meminta masukan dari komunitas! :)

Tentang plugin.
Pada dasarnya, satu-satunya hal yang saya inginkan adalah _tidak_ diblokir pada panggilan Assembly.LoadFrom atau LoadLibrary .
Saya tidak perlu apa-apa lagi dan bisa melakukan sisanya sendiri.

@ayende Bisakah Anda menjelaskan sedikit lebih detail apa yang Anda maksud dengan "diblokir di LoadFrom dan semacamnya"?

Sebagai contoh, beberapa saran untuk ini termasuk CoreRT, yang berarti bahwa kami (mungkin) tidak dapat hanya memuat dll yang dikelola.
Tetapi selama saya dapat memberikan jalur ke dll yang dikelola dan mendapatkan Majelis atau memanggil LoadLibrary pada dll asli, saya baik-baik saja dengan ini menjadi mekanisme plugin.

Saya mengatakan ini untuk memperjelas bahwa skenario plugin bukanlah sesuatu yang harus _dipertimbangkan_, melainkan sesuatu yang tidak boleh _diblokir_.

Saya menghabiskan beberapa waktu untuk menggali kode dan pada pandangan pertama, sepertinya seharusnya _mungkin_ untuk (berbicara tentang Windows hanya untuk mempermudah):

• Kemas seluruh CoreCLR ke dalam sebuah exec (misalkan itu sebagai sumber daya yang disematkan atau semacamnya).
• Hitung dll asli, panggil sesuatu seperti MemoryModule (https://github.com/fancycode/MemoryModule) untuk memuatnya ke dalam memori
• Panggil runtime dan muat perakitan dari memori.

Saya akan berasumsi bahwa ini _tidak_ sesederhana itu. Misalnya, ICLRRuntimeHost2::ExecuteAssembly tidak menyediakan cara apa pun untuk memberikan buffer, hanya file di disk.
Itu menjadikannya yang pertama (dari apa yang saya yakin akan banyak) menunjukkan stopper untuk benar-benar membuatnya bekerja.

Saya cukup yakin bahwa ada banyak kode yang mungkin merujuk pada hal-hal terkait sebagai file yang mungkin gagal, tetapi ini adalah hal-hal yang saya maksud ketika saya mengatakan bahwa saya menginginkan satu file exec dan mengapa semacam itu solusi perlu dilakukan di CoreCLR dan bukan secara eksternal (seperti pada contoh Zip).

panggil sesuatu seperti MemoryModule

Binari yang dimuat menggunakan MemoryModule tidak dapat didiagnosis (misalnya tidak ada debugger biasa, profiler, dll. yang akan bekerja pada mereka), dan MemoryModule melewatkan semua tindakan keamanan OS bawaan (misalnya antivirus, dll.). Ini bukan sesuatu yang bisa kami kirimkan sebagai solusi yang didukung.

Saya akan berasumsi bahwa ini tidak sesederhana itu.

Benar, akan ada API baru yang diperlukan (baik yang dikelola maupun tidak) untuk mendukung eksekusi dari bundel file tunggal yang tidak diperluas. Program dan perpustakaan yang ada tidak akan "berfungsi begitu saja".

Mungkinkah permintaan yang masuk akal untuk antarmuka pemindaian anti malware menjadi
diimplementasikan oleh insinyur Windows di MemoryModule seperti baru-baru ini untuk
semua rakitan .net termasuk yang dimuat dari mem?

https://twitter.com/WDSecurity/status/1047380732031762432?s=19

EDIT: Hmm MemoryModule terdengar seperti sesuatu yang dibangun ke dalam OS untuk memuat modul asli tetapi ternyata tidak, itu mungkin alasan yang cukup untuk mengabaikan saran saya di atas

Pada Rabu, 5 Desember 2018, 01:46 Jan Kotas [email protected] menulis:

panggil sesuatu seperti MemoryModule

Binari yang dimuat menggunakan MemoryModule tidak dapat didiagnosis (mis
debugger biasa, profiler, dll.) akan bekerja pada mereka, dan MemoryModule
melewatkan semua langkah keamanan OS bawaan (misalnya antivirus, dll.). Bukan itu
sesuatu yang bisa kami kirimkan sebagai solusi yang didukung.

Saya akan berasumsi bahwa ini tidak sesederhana itu.

Benar, akan ada API baru yang dibutuhkan (baik terkelola maupun tidak terkelola) untuk
mendukung eksekusi dari bundel file tunggal yang tidak diperluas. yang ada
program dan perpustakaan tidak akan "berfungsi begitu saja".

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/dotnet/coreclr/issues/20287#issuecomment-444314969 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AEBfudvVHxpbeKa-L_vTQjbnNZZsn6Meks5u1xdlgaJpZM4XK-X_
.

Terima kasih untuk semua umpan balik.
Kami akan segera memposting rencana terbaru untuk mendukung distribusi file tunggal.

@NinoFloris lihat dotnet/coreclr#21370

Saya menyadari saya terlambat untuk diskusi ini jadi saya minta maaf jika ini tidak membantu.

Untuk mengulangi apa yang dikatakan @mikedn , memiliki semua solusi paralel ini dapat membingungkan, dan itu menimbulkan pertanyaan di mana fokus MS akan berada di masa depan. Fakta bahwa pekerjaan brilian yang dilakukan pada CoreRT masih diberi label eksperimental tanpa peta jalan resmi dan dengan fungsionalitas serupa yang diterapkan di CoreCLR (CPAOT, sekarang penerbitan file tunggal) membuat sulit untuk membuat keputusan bisnis berdasarkan teknologi. Saya tidak ingin memilih kuda yang salah lagi (Silverlight...).

Mengapa tidak tetap menggunakan runtime yang brilian di CoreRT dan memfokuskan pekerjaan pada penggabungan JIT (dan memperluas pekerjaan juru bahasa hingga siap) ke dalam CoreRT bagi mereka yang menginginkan kemampuan kerangka kerja penuh sambil tetap memiliki kode asli yang dibuat untuk mereka? Tidakkah mungkin, jika menginginkan kemampuan JIT, untuk menyimpan metadata dan JIT di dalam CoreRT yang dapat dieksekusi yang dikompilasi secara asli?
Bukankah ini yang terbaik dari semua dunia? Misalnya. Anda akan memiliki executable terkecil, waktu startup tercepat, batasan kode AOT di CoreRT dapat diperluas dengan memiliki JIT, dan menjaga metadata dan kode IL bagi mereka yang ingin mempertahankan fungsionalitas kerangka kerja penuh.
IMO fokusnya harus pada solusi 'terbaik' alih-alih pada fungsionalitas jangka pendek yang mungkin mengalihkan perhatian dari tujuan jangka panjang.

Mungkin saya salah, tetapi saya pikir memiliki satu file yang diterbitkan sebagai bagian dari CoreCLR akan semakin mengalihkan perhatian pelanggan dari CoreRT yang dalam banyak kasus akan menjadi solusi yang berpotensi lebih baik bagi mereka. Misalnya. jika ini dicap sebagai "sekarang Anda dapat mempublikasikan kode .NET Anda sebagai satu file" namun itu membuat file besar, akan menderita dalam kinerja startup, dll. Kemudian saya dapat melihat orang-orang mulai mengeluh tentang "runtime .NET yang membengkak" ini lagi . Sementara .NET sebenarnya sudah memiliki solusi brilian untuk hal itu di CoreRT, sementara tidak ada dukungan resmi/komitmen produk resmi untuk semuanya.

Mungkin kekhawatiran saya sebagian besar adalah bahwa saya ingin melihat lebih sedikit produk paralel (sekali lagi mengutip @mikedn) dan lebih menekankan pada komitmen yang mendalam, memperluas dan mendukung produk yang ada di sini (termasuk berbagi peta jalan).

produk yang kurang paralel

Kami hanya memiliki satu produk: .NET Core. CoreRT bukanlah produk yang terpisah dan tidak akan pernah. Ini tentang menambahkan opsi ke produk yang satu ini. Berikut adalah beberapa contoh opsi yang kami miliki saat ini: GC workstation dan GC server; publikasi aplikasi mandiri vs. publikasi aplikasi yang bergantung pada kerangka kerja.

@jkotas Saya mengerti, dan saya sepenuhnya setuju menambahkan opsi biasanya bagus. Jika Anda mengganti penggunaan kata "produk" saya dengan "opsi/solusi" meskipun saya masih berdiri dengan kekhawatiran saya tidak sepenuhnya mengetahui apakah komitmen produk kami untuk CoreRT sebagai opsi/solusi di dalam produk .NET Core secara keseluruhan adalah sesuatu yang kami dapat dengan aman bertaruh untuk didukung di tahun-tahun mendatang. Bayangkan bagaimana jadinya jika API membuat perubahan yang tidak terduga dari waktu ke waktu dan tiba-tiba tidak digunakan lagi tanpa Anda mengetahui apakah Anda dapat mempercayai API untuk tetap berada di sana atau tidak. Untuk entitas non-MS, alat/opsi yang merupakan bagian dari produk merasakan hal yang sama. Kami bergantung pada beberapa kemampuan CoreRT yang tidak dapat kami lakukan (setidaknya saat ini) dengan CoreCLR (salah satunya kemampuan untuk melindungi executable kami dengan PACE dan menghapus banyak dan banyak metadata, IL, dll., penautan statis yang mudah, pemahaman yang lebih mudah tentang platform yang mendasarinya, prospek membangun kebingungan langsung ke dalam kompiler, dll.). Pada dasarnya saya merasa pekerjaan Anda dan Michal dan orang lain di CoreRT harus diprioritaskan karena IMO adalah salah satu hal terbaik yang telah terjadi di ekosistem .NET sejak pertama kali dirancang. Setiap kali ada pembicaraan tentang alat/opsi baru yang kemudian secara internal dapat dilihat sebagai persaingan dengan CoreRT alih-alih opsi CoreRT untuk diselesaikan dan diperluas kepada saya terasa seperti alokasi sumber daya yang salah. Maaf tidak bermaksud menyeret diskusi, hanya ingin memastikan Anda memahami betapa dihargainya pekerjaan CoreRT dan bahwa sebagian dari kita di sini percaya bahwa itu harus menjadi masa depan platform.
Saya akan menahan diri untuk tidak mencemari diskusi ini lebih lanjut. Berharap yang terbaik untuk tim dan menantikan apa pun yang Anda buat, saya yakin itu akan menjadi luar biasa.

@christianscheuer Umpan balik Anda tentang masalah ini dan masalah terkait CoreRT lainnya sangat berharga. Anda tidak mengotori diskusi ini sama sekali.

ada pembicaraan tentang alat/opsi baru yang kemudian secara internal dapat dilihat sebagai kompetisi dengan CoreRT

Di antara tim inti, kami berbicara tentang sejumlah pilihan yang berbeda, ambisius atau lebih gila. Saya tidak menganggap "unzip ke disk" sebagai pesaing signifikan dengan CoreRT full AOT. Masing-masing menargetkan segmen pengguna/aplikasi .NET yang berbeda.

Tim manajemen produk kami yang mengumpulkan data dari berbagai saluran (termasuk masalah github atau percakapan pelanggan tatap muka) menyarankan bahwa keuntungan terbesar adalah solusi seperti yang diusulkan di sini. Kami masih memvalidasi bahwa kami memiliki semua data di kanan ini dan itu akan memiliki hasil yang diinginkan.

Saya tidak dapat menjanjikan Anda kapan teknologi CoreRT akan dikirimkan sebagai bagian dari produk .NET Core yang didukung saat ini. Saya tahu bahwa ia memiliki kekuatan yang unik dan saya yakin kami akan mengirimkan solusi yang didukung seperti itu untuk segmen pengguna .NET penting yang pada akhirnya mendapat manfaat darinya.

Distribusi file tunggal masuk akal jika:

• Itu tidak memengaruhi waktu startup (Jika tidak, hanya aplikasi terkecil yang dapat menggunakannya)
• Bertindak sebagai VFS (Virtual File System) Memungkinkan Anda untuk mengakses rakitan dan sumber daya seolah-olah berasal dari disk, dari folder aplikasi).
• Tidak mempengaruhi "patchability" aplikasi. IE: Microsoft harus dapat menambal rakitan kritis bahkan jika rakitan tersebut disematkan dengan memberikan penggantian di tempat lain, di tingkat sistem.

Rakitan sebagai sumber daya yang disematkan, diekstraksi dan disalin ke folder temp bukanlah solusi yang diperlukan dari Microsoft. Hal ini dapat dengan mudah diimplementasikan oleh setiap pelanggan yang membutuhkannya.

Solusi file tunggal yang "benar" diperlukan dan akan memberikan banyak nilai.

@jkotas komentar Anda benar bagi saya. Saya akan kesulitan meyakinkan .NET devs (LOB/backoffice/integrasi) perusahaan saya untuk beralih ke CoreRT karena itu akan terlalu banyak lompatan bagi mereka (terutama diberi label Eksperimental), tetapi mereka dapat melihat nilainya dalam solusi yang relatif sederhana (untuk digunakan) untuk Core seperti yang sedang dibahas oleh utas ini. Terima kasih

@ popcatalin81 Saya sebenarnya sangat tidak setuju dengan poin Anda di sini.

Waktu startup tidak berarti untuk banyak aplikasi. Saya dengan senang hati akan menukar 50% - 100% peningkatan waktu startup dari layanan yang berjalan lama dengan tujuan untuk mengurangi kerumitan operasional penerapannya.

Bahkan jika kita menambahkan 30 detik ke waktu startup layanan, itu tidak terlalu berarti dalam jangka panjang untuk layanan.
Untuk aplikasi yang dihadapi pengguna, itu kemungkinan akan menjadi pembunuh, tetapi hingga 3.0 keluar, hampir semua aplikasi CoreCLR adalah konsol atau layanan.

Bukan berarti CoreCLR sudah memiliki mode di mana Anda dapat menggabungkan kerangka kerja dengan aplikasi Anda (penyebaran mandiri).
Dalam kasus kami (RavenDB), kami _mengandalkannya untuk beberapa tujuan. Pertama, kemampuan untuk memilih kerangka kerja kami sendiri terlepas dari apa pun yang digunakan pengguna kami. Ini adalah _major_ manfaat bagi kami, karena itu berarti bahwa kami tidak perlu menggunakan kerangka kerja yang diinstal secara global dan dengan demikian tidak terikat pada apa pun yang diputuskan oleh admin sebagai kerangka kerja (kami biasanya memperhitungkan bahwa kami akan menjalankan .NET 4.0 kadang-kadang, bahkan bertahun-tahun setelah 4.5 keluar, misalnya, dan itu menyebalkan).
Aspek penting lainnya adalah bahwa kita dapat menjalankan dengan garpu _sendiri_ dari kerangka kerja. Ini sangat berguna jika kita mengalami hal-hal yang harus kita ubah.

Sebagai bagian dari itu, kami mengambil kepemilikan atas siklus tambalan dan tidak ingin orang lain mengacaukannya.

Saya tidak _mind_ VFS, tetapi menurut saya ini tidak diperlukan. Dan saya baik-baik saja dengan harus melalui API khusus/melompat melalui beberapa rintangan untuk sampai ke rakitan/dll/sumber daya asli yang digabungkan dengan cara ini.

Saya diarahkan ke masalah ini oleh @briacht selama dua hari, jadi saya BENAR-BENAR terlambat dalam diskusi.
Hanya ingin menambahkan 2 sen saya!

Pertama jawaban saya atas pertanyaan @morganbr :

1. Aplikasi Windows, menggabungkan WPF dan WinForms.
2. Saat ini, tidak
3. Ya, menggunakan Majelis. Muat dalam berbagai variasi
4. Ya
5. Itu tergantung apakah ini adalah penalti yang ada di setiap startup. Ya jika beberapa milidetik, tetapi 5 detik: tidak. Jika sekali, 5 detik tidak masalah.
6. 50MB sudah cukup besar dibandingkan dengan <2MB... tapi jika ini berarti runtime dotnet disertakan... OK. Mungkin saya bisa memberikan unduhan dengan dan tanpa.
7. Waktu rilis tidak secara langsung menjadi masalah, tetapi seharusnya tidak mengganggu penyedia CI dengan menggunakan banyak CPU untuk jangka waktu yang lama.
8. YA!

Aplikasi yang saya bicarakan Greenshot, versi yang dirilis saat ini cukup banyak masih menargetkan .NET Framework 2.0 (ya benar-benar) tetapi berfungsi tanpa masalah pada versi terbaru (kompatibilitas mundur yang baik)! Unduhan Zhe, termasuk penginstal tetapi tanpa .NET Framework, sekitar 1,7MB. Direktori dari mana ini dimulai berisi 1 .exe dan 4 .dlls, ada juga 11 add-on di sub-direktori.

Saya membaca komentar sebelumnya, dan banyak dari mereka terdengar seperti Anda menginginkan sesuatu dengan fungsionalitas yang saya gunakan untuk penginstal. Ini agak masuk akal, karena saat ini tidak ada solusi platform independen.

Saya sedang mendiskusikan topik saat ini dengan beberapa orang di Microsoft pada bulan Agustus, fokus utama saya berbicara tentang menghubungkan semuanya bersama-sama untuk mengurangi ukuran dan kompleksitas aplikasi untuk penyebaran dan juga mengurangi pemuatan perakitan yang membutuhkan BANYAK waktu selama startup dari aplikasi saya.

Dengan versi Greenshot berikutnya, yang menargetkan .NET Framework 4.7.1 dan dotnet core 3.0 secara berdampingan, hasil unduhan untuk dotnet core 3.0 saat ini memiliki sekitar 103 dll (!!!), satu exe dan 15 add-on . Ukuran totalnya sekitar 37MB dan file terbesar adalah MahApps.Metro.IconPacks.dll (12MB!!) yang berisi sebagian besar ikon yang kami gunakan, yang mungkin sekitar 4% dari file. Sama dengan banyak dll lainnya, saya akan berasumsi bahwa secara umum 50% dari penggunaan kode banyak!

Jika pengguna tidak ingin menginstal aplikasi, cukup unduh .zip dan temukan file yang dapat dieksekusi di antara sekitar 118 file... bukan pengalaman yang menyenangkan! Ukurannya sekitar 35MB (17x) lebih besar, lalu apa manfaatnya bagi pengguna?

Pada bulan-bulan sebelum dotnet core 3.0 menjadi sesuatu, saya menggunakan Fody.Cosura untuk melakukan hampir semua hal yang dijelaskan di sini. Pengepakan selama pembuatan dan pembongkaran saat startup! Itu bahkan membuat satu executable tanpa mengekstraksi file mungkin dengan meretas but. Tetapi itu juga menyebabkan cukup banyak masalah, jadi ini bukan solusi pilihan saya.

Saya mengharapkan solusi standar yang kurang lebih yang dapat saya katakan: ini hanya berfungsi ™
Mungkin masuk akal untuk mendefinisikan struktur folder standar, sehingga kami dapat menempatkan file yang dapat dieksekusi, readme, lisensi dll di root dan memiliki direktori "dikenal" yang berbeda untuk file yang berbeda (dotnet core, dependensi, dll). Ini mungkin memudahkan alat untuk digunakan, dan menawarkan fungsionalitas di mana setiap orang dapat memutuskan apa yang ingin digunakan dan apa yang tidak. Kadang-kadang bahkan hanya menjalankan Zip pada direktori memecahkan beberapa masalah.

Memiliki solusi yang mirip dengan Fody.Costury kadang-kadang saya dapat menggunakan pencitraan untuk menyederhanakan penerapan Greenshot, tetapi tidak secara langsung mengurangi ukuran dan waktu pemuatan. Jadi saya berharap akan ada beberapa waktu yang dihabiskan di sini juga!

@ayende Tolong izinkan saya untuk tidak setuju dengan Anda juga :)

Meskipun layanan sebenarnya, aplikasi web dan secara umum aplikasi yang berjalan lama berbasis server tidak terpengaruh oleh biaya startup satu kali, pada saat yang sama aplikasi ini bukan yang paling banyak mendapatkan manfaat dari model distribusi file tunggal. (Gagak adalah pengecualian, bukan norma ;))

Dalam pandangan saya, distribusi file tunggal terutama ditargetkan pada aplikasi dan utilitas yang ditargetkan pada pengguna. Pengguna yang akan mengunduh, menyalin, menjalankan aplikasi tersebut. Dan dalam waktu dekat ketika.Net Core 3.0 akan menawarkan dukungan untuk perpustakaan UI, model distribusi ini akan menjadi sangat umum. Namun, saya harus menekankan, model ini tidak akan cocok untuk aplikasi apa pun. Aplikasi utama masih akan menggunakan penginstal.

Sekarang pertanyaannya adalah, model rakitan tertanam ini disalin ke folder temp, apakah akan berfungsi dengan baik jika menjadi sangat populer?

Dalam pandangan saya, ini adalah beberapa masalah potensial untuk model saat ini:

• Lusinan aplikasi membuat ribuan file sementara dengan rakitan duplikat. Ada potensi untuk membuat kekacauan di sini. (Tidak diperhatikan oleh pengguna, tetapi masih berantakan)
• Tidak ada kompresi, tidak ada linker. Ini mungkin membuat kerugian untuk aplikasi utilitas kecil dibandingkan dengan FDD atau zip acara.
• Ini mungkin sebenarnya menghambat penerapan server alih-alih membuatnya lebih mudah, alasannya adalah: konfigurasi pasca penerapan dengan penggantian token. (Di mana Anda pergi untuk menemukan folder temp untuk menimpa file konfigurasi? Apakah Anda memberikan layanan akses tulis ke foldernya sendiri untuk membuat file konfigurasi di sana? Itu keamanan tidak-tidak)

Saya di sini bukan untuk mengatakan model ini kurang optimal untuk semua jenis aplikasi. Saya telah berhasil menerapkannya dan menggunakannya sendiri di masa lalu untuk Full.Net Framework, dan ini cocok untuk aplikasi tertentu.

Saya hanya berpikir implementasi optimal adalah versi di mana tautan menggabungkan semua rakitan menjadi satu file.

@popcatalin81 Dunia dengan satu sudut pandang adalah dunia yang buruk. Dan saya tidak cukup arogan untuk berpikir bahwa model penerapan saya adalah satu-satunya di luar sana.

Kasus yang ada dalam pikiran saya adalah skenario unduhan dan klik dua kali.
Saat ini, kita harus membuka zip dan mengklik skrip shell untuk menjalankannya, karena masuk ke direktori dengan 100-an file dan menemukan yang tepat adalah tugas yang sulit.

Tentang konfigurasi di file temp. Saya akan sangat menentang itu. File konfigurasi adalah hal-hal lain yang terlihat oleh pengguna _harus_ berada tepat di sebelah file aktual yang sedang digunakan, tidak disembunyikan di suatu tempat.
Kami telah melihat betapa buruknya itu dengan file IsolatedStorage ketika pengguna membutuhkannya.

Di versi RavenDB sebelumnya, kami menggabungkan banyak hal untuk memiliki tata letak direktori yang lebih sederhana dan mengurangi jumlah file yang terlihat, dan itu berdampak serius pada seberapa berguna perangkat lunak kami.

Apakah fitur ini akan menggunakan ILmerge? Jika tidak, mengapa tidak? Saya ingin mendidik diri saya sendiri jika ada jebakan.

Saya tidak suka pendekatan "paket dan ekstrak" yang diusulkan, terutama bagian di mana jika akan mengekstrak file pada disk. Ini sederhana, tetapi memiliki terlalu banyak masalah. Itu semua harus bekerja dari "dalam memori" tanpa mengekstrak ke disk.

Saya pikir itu harus seperti kompiler asli corert atau Costura.Fody .

Opsional itu juga harus mencoba untuk mengurangi ukuran biner (hapus referensi yang tidak digunakan, IL mati).

ulang

Pada bulan-bulan sebelum dotnet core 3.0 menjadi sesuatu, saya menggunakan Fody.Cosura untuk melakukan hampir semua hal yang dijelaskan di sini. Pengepakan selama pembuatan dan pembongkaran saat startup!

perhatikan bahwa costura tidak (secara default) "membongkar ke disk". itu mengekstrak (dalam memori) rakitan yang disematkan dari sumber daya dan memuatnya melalui byte

Terima kasih atas konteksnya @SimonCropp , kami sedang menjajaki kedua opsi untuk membongkar ke disk dan memuat dari aliran. Menutupi pemuatan dari aliran untuk IL murni dimungkinkan dalam iterasi pertama kami.

@jeffschwMSFT btw, kumpulan fitur yang menggabungkan rakitan dengan mulus (dan pengocokan pohon opsional) adalah sesuatu yang ingin saya lihat sebagai warga negara kelas satu. costura adalah salah satu proyek saya yang lebih populer, tetapi juga proyek yang membutuhkan banyak waktu untuk mendukungnya. jadi jika/ketika MS keluar dengan alternatif (bahkan sebagai beta), beri tahu saya dan saya akan meluangkan waktu untuk meninjaunya dan menambahkan beberapa "ada alternatif MS" ke deskripsi costura readme dan nuget

sementara tidak mungkin, jika Anda membutuhkan saya untuk melepaskan salah satu kode di costura di bawah lisensi diff, beri tahu saya.

Terima kasih @SimonCropp saat kami mulai mengintegrasikan mono/illinker ke dalam rantai alat .NET Core, kami akan menerima tawaran Anda untuk meninjau.

perhatikan bahwa costura tidak (secara default) "membongkar ke disk". itu mengekstrak (dalam memori) rakitan yang disematkan dari sumber daya dan memuatnya melalui byte

Bahkan lebih baik, saya percaya itu memuat sesuai permintaan menggunakan acara AppDomain.AssemblyResolve , jadi startup tidak boleh terlalu terpengaruh karena hanya akan memuat rakitan (ke dalam memori) kapan pun diperlukan.

Terlambat untuk percakapan di sini. Mohon maaf jika ini sudah pernah dibahas.

Bisakah kita berasumsi artefak di sini akan deterministik? Oleh karena itu build yang sama akan selalu menghasilkan biner yang sama? Byte-untuk-byte. Mampu mendistribusikan biner dengan kanonik, checksum yang menyertainya juga akan membantu.

@morganbr Ada banyak bacaan yang diperlukan di sini. Apakah mungkin untuk mencatat keputusan yang dibuat sejauh ini?

@edblackburn kami menyusun desain yang diperbarui berdasarkan umpan balik. @swaroop-sridhar mengemudikan desain sekarang.

Apakah fitur ini akan menggunakan ILmerge? Jika tidak, mengapa tidak? Saya ingin mendidik diri saya sendiri jika ada jebakan.

@simplejackcoder ILMerge menggabungkan IL dari banyak rakitan menjadi satu, tetapi dalam prosesnya, kehilangan identitas asli dari rakitan yang digabungkan. Jadi, hal-hal seperti menggunakan refleksi berdasarkan nama Majelis asli akan gagal.

Tujuan dari upaya ini bukan untuk menggabungkan rakitan, tetapi untuk mengemasnya bersama sambil mempertahankan identitas rakitan. Selanjutnya, kita perlu mengemas tidak hanya rakitan, tetapi juga binari asli, file konfigurasi, mungkin waktu proses, dan dependensi lain apa pun yang diperlukan oleh aplikasi.

Menggabungkan IL adalah fitur yang berguna untuk aplikasi yang dapat beradaptasi dengannya -- ini hanya fitur yang berbeda dari masalah ini.

Ulasan desain diposting di https://github.com/dotnet/designs/pull/52
Mari kita lanjutkan pembahasan tentang PR selanjutnya.

Saya punya beberapa pertanyaan untuk orang-orang yang ingin menggunakan file tunggal. Jawaban Anda akan membantu kami mempersempit pilihan kami:

1. Jenis aplikasi apa yang kemungkinan besar akan Anda gunakan? (mis. WPF di Windows? ASP.NET dalam wadah Linux Docker? Sesuatu yang lain?)
2. Apakah aplikasi Anda menyertakan (non-.NET) C++/kode asli?
3. Apakah aplikasi Anda akan memuat plugin atau dll eksternal lainnya yang awalnya tidak Anda sertakan dalam pembuatan aplikasi?
4. Apakah Anda bersedia membangun kembali dan mendistribusikan ulang aplikasi Anda untuk memasukkan perbaikan keamanan?
5. Apakah Anda akan menggunakannya jika aplikasi Anda mulai 200-500 md lebih lambat? Bagaimana dengan 5 detik?
6. Berapa ukuran terbesar yang Anda anggap dapat diterima untuk aplikasi Anda? 5MB? 10? 20? 50? 75? 100?
7. Apakah Anda akan menerima waktu pembuatan rilis yang lebih lama untuk mengoptimalkan ukuran dan/atau waktu mulai? Apa yang paling lama Anda terima? 15 detik? 30 detik? 1 menit? 5 menit?
8. Apakah Anda bersedia melakukan pekerjaan ekstra jika itu akan memotong ukuran aplikasi Anda menjadi dua?

1. Kasus penggunaan dotnet/coreclr#1 kami sejauh ini adalah aplikasi konsol yang merupakan utilitas. Kami ingin melakukan publikasi untuk windows atau linux dan menentukan --single-file untuk mendapatkan satu yang dapat dieksekusi. Untuk windows, kami berharap ini diakhiri dengan .exe , untuk linux, ini akan menjadi biner yang dapat dieksekusi.
2. Tidak biasanya, tetapi bisa melalui paket NuGet tanpa sepengetahuan kami
3. Bukan awalnya, tapi itu akan menjadi fitur masa depan yang hebat
4. Ya
5. Ya
6. Apapun yang berhasil
7. Ya, jika dioptimalkan ukuran yang dihasilkan dari executable. Idealnya, mungkin flag untuk mengatur level pengoptimalan menggunakan --optimizing-level=5
8. Ya, sampai titik tertentu

Terima kasih @BlitzkriegSoftware.
Saya pikir desain yang diusulkan di sini mencakup kasus penggunaan Anda. Silakan lihat desainnya -- kami menerima masukan Anda.

Saya punya beberapa pertanyaan untuk orang-orang yang ingin menggunakan file tunggal. Jawaban Anda akan membantu kami mempersempit pilihan kami:

1. Jenis aplikasi apa yang kemungkinan besar akan Anda gunakan? (mis. WPF di Windows? ASP.NET dalam wadah Linux Docker? Sesuatu yang lain?)
2. Apakah aplikasi Anda menyertakan (non-.NET) C++/kode asli?
3. Apakah aplikasi Anda akan memuat plugin atau dll eksternal lainnya yang awalnya tidak Anda sertakan dalam pembuatan aplikasi?
4. Apakah Anda bersedia membangun kembali dan mendistribusikan ulang aplikasi Anda untuk memasukkan perbaikan keamanan?
5. Apakah Anda akan menggunakannya jika aplikasi Anda mulai 200-500 md lebih lambat? Bagaimana dengan 5 detik?
6. Berapa ukuran terbesar yang Anda anggap dapat diterima untuk aplikasi Anda? 5MB? 10? 20? 50? 75? 100?
7. Apakah Anda akan menerima waktu pembuatan rilis yang lebih lama untuk mengoptimalkan ukuran dan/atau waktu mulai? Apa yang paling lama Anda terima? 15 detik? 30 detik? 1 menit? 5 menit?
8. Apakah Anda bersedia melakukan pekerjaan ekstra jika itu akan memotong ukuran aplikasi Anda menjadi dua?

1. Aplikasi WPF .Core 3.0
2. Mungkin dalam paket nuget
3. Tidak
4. Ya
5. Ya untuk maksimum 200-500ms
6. Tidak penting segera setelah tidak 2 atau 3 kali lebih besar dari ukuran folder publish asli
7. Ini untuk produksi jadi tidak terlalu penting
8. Ya tetapi memiliki kemungkinan untuk tidak melakukan itu mungkin berguna jika pekerjaan itu menyangkut perpustakaan pihak ketiga

Umpan balik yang Anda terima sebagian besar untuk pengembangan sebelum 2019, yang biasanya berupa layanan web, aplikasi konsol, dan layanan lain yang diluncurkan di latar belakang. Tapi sekarang dengan .net core 3.0, kami membutuhkan solusi untuk aplikasi WPF dan UI. .Net Framework 4.8 tidak akan mendukung .Net Standard 2.1 dan kami membutuhkan solusi untuk menggantikan ILMerge yang kami gunakan sampai sekarang untuk aplikasi WPF karena kami harus memutakhirkan aplikasi kami dari .net framework (dead framework) ke .net core.

Paket self-extracting jelas bukan solusi yang baik seperti yang dijelaskan dalam komentar lain sebelumnya untuk program semacam ini.

1. Sebagian besar aplikasi CLI. Layanan Windows kecil dan aplikasi WPF sesekali juga menarik. Untuk hal-hal web, distribusi file tunggal tampaknya pada dasarnya tidak relevan. Untuk alasan ini, sisanya sebagian besar berorientasi Windows; minat Inti Linux .NET kami adalah seputar hal-hal web.
2. Kadang-kadang. Ketika ya, hampir selalu untuk perpustakaan kompresi. Jika barang-barang asli tidak dikemas, itu bukan akhir dunia. Solusi yang baik untuk hal-hal yang dikelola murni yang memerlukan penyebaran ketergantungan asli sebagai dll yang terpisah masih akan memiliki nilai.
3. Tidak, tidak dalam kasus di mana kami peduli dengan satu file.
4. Ya.
5. 200ms kira-kira batas sebelum hal-hal menjadi mengganggu untuk memulai CLI. > 1 detik dan kami hampir pasti akan tetap menggunakan .NET Framework (ILMerge + ngen) atau melihat bahasa lain yang dikompilasi ke biner asli dengan runtime yang diperlukan yang terhubung secara statis. Dalam banyak kasus, kami berbicara tentang hal-hal yang diimplementasikan dalam C# karena aplikasi C# yang terintegrasi dan ngen-ed sebenarnya dimulai dengan cukup cepat. Beberapa dari hal ini, dari segi kompleksitas, masuk akal untuk diterapkan dalam bahasa skrip, tetapi itu cenderung memiliki biaya awal yang signifikan, terutama jika Anda perlu menarik banyak modul.
6. Bergantung. Lebih dari 10MB untuk hello world akan menjadi penjualan yang sulit. Besar juga executable cenderung memiliki biaya startup non-sepele. Bahkan jika OS secara teoritis mampu memulai eksekusi tanpa membaca semuanya, setidaknya di Windows, hampir selalu ada sesuatu yang ingin mendapatkan hash untuk tujuan keamanan terlebih dahulu. Omong-omong, un-pack sekelompok binari ke hal temp akan mendorong AV (Defender benar-benar termasuk) kacang, dalam hal pemanfaatan sumber daya dengan panik memindai jika tidak ada yang lain.
7. Tentu. Saya akan dengan senang hati menambahkan satu menit atau lebih ke build rilis jika itu berarti mendapatkan sesuatu yang berukuran wajar dan memulai eksekusi dengan cepat.
8. Pastinya.

Membaca proposal, itu tidak membahas skenario apa pun yang kami miliki dan kami tidak akan menggunakannya. Mungkin ada seseorang yang memecahkan masalah, tapi itu bukan kita.

Sepertinya ada banyak hal yang relevan untuk skenario seperti skenario yang sedang kami kerjakan yang belum menyatu menjadi rantai alat yang sebenarnya dapat digunakan/kemungkinan akan terus berfungsi. Mungkin ini hanya ketidaktahuan saya, tetapi saya mencoba memperhatikan dan itu tidak jelas bagi saya. Antara ILLink, Microsoft.Packaging.Tools.Trimming, CoreRT, .NET Native dan apa pun yang terjadi dalam masalah ini, sepertinya harus ada beberapa cara untuk mendapatkan satu pohon yang diguncang, mulai cepat (mungkin AoT?), biner berukuran wajar dari .NET Core (dan bukan untuk UWP).

1. Distribusi file tunggal akan sangat berguna untuk aplikasi https://github.com/AvaloniaUI/Avalonia (Windows, Linux, MacOS) dan WPF (Windows). Memiliki satu exe membuat pembaruan otomatis menjadi mudah misalnya, dan secara umum lebih nyaman untuk memiliki satu file dibandingkan dengan ratusan dll.
2. Ya (dalam arti bahwa ini merujuk pada lib asli prebuild seperti sqlite dan skia)
3. Tidak
4. Ya
5. 200ms mungkin baik-baik saja. Memiliki waktu startup 5 detik untuk aplikasi GUI tidak baik.
6. Tidak terlalu penting
7. Tidak masalah. Kami dapat membuat satu file hanya untuk skenario produksi.
8. Ya

Tolong jangan pergi dengan pendekatan paket & ekstrak. Kita sudah bisa mencapai ini dengan menggunakan alat arsip.

Tolong jangan pergi dengan pendekatan paket & ekstrak. Kita sudah bisa mencapai ini dengan menggunakan alat arsip.

Saya sangat setuju. Sudah ada beberapa alat yang tersedia yang melakukan ini.

Terima kasih atas umpan baliknya @Safirion , @mattpwhite , @x2bool , @thegreatco.
Dari sini, saya melihat berbagai skenario penggunaan (aplikasi konsol, WPF, aplikasi GUI, dll), tetapi persyaratan keseluruhannya tampak serupa:

• Fokus pada waktu eksekusi/startup daripada waktu build.
• Kemampuan untuk membangun kembali aplikasi untuk rilis/tambalan lebih lanjut
• Kemampuan untuk menjalankan langsung dari bundel (terutama untuk komponen yang dikelola murni).

Saya yakin ini adalah persyaratan yang kami coba atasi dalam dokumen desain .

Tolong jangan pergi dengan pendekatan paket & ekstrak

Ya, seperti yang dijelaskan dalam dokumen pementasan ini, tujuannya adalah untuk semakin meminimalkan ketergantungan pada ekstraksi file.

Membaca proposal, itu tidak membahas skenario apa pun yang kami miliki dan kami tidak akan menggunakannya.

@mattpwhite , ingin mengklarifikasi apakah menurut Anda solusi ini tidak berfungsi untuk Anda berdasarkan:

• Pendekatan berbasis ekstraksi diri yang diusulkan sebelumnya dalam item kerja ini, atau
• Desain yang dicatat dalam dokumen ini
  Saya yakin dokumen selanjutnya mencoba membahas skenario yang telah Anda detailkan. Terima kasih.

Sepertinya ada banyak hal yang relevan untuk skenario seperti skenario yang sedang kami kerjakan yang belum menyatu menjadi rantai alat yang sebenarnya dapat digunakan/kemungkinan akan terus berfungsi.

@mattpwhite , ada pekerjaan yang sedang berlangsung untuk mengintegrasikan ILLink (tree-shaking), crossgen (menghasilkan kode asli yang siap dijalankan), dan aspek bundling file tunggal ke dalam msbuild/dotnet CLI secara efisien untuk .net core 3. Sekali ini dilakukan, menggunakan alat ini dapat dilakukan dengan mudah (mis: mengatur properti msbuild tertentu).

Semua alat ini, datang dengan pengorbanan. Misalnya, crossgen menghasilkan kode asli sebelumnya sehingga membantu startup, tetapi cenderung meningkatkan ukuran binari. Menggunakan opsi file tunggal, aplikasi dapat dipublikasikan ke file tunggal, tetapi ini dapat memperlambat startup, karena binari asli tumpah ke disk, dll.

@swaroop-sridhar, terima kasih telah meluangkan waktu untuk menanggapi.

ingin mengklarifikasi apakah menurut Anda solusi ini tidak bekerja untuk Anda berdasarkan

Sepertinya ekstraksi masih dalam gambar untuk apa pun yang mandiri, dan status crossgen (atau apa pun untuk mengurangi waktu JIT saat diluncurkan) tidak jelas bagi saya. Membaca dokumen pementasan yang ditautkan ke desain saat ini tampak seperti hal-hal yang akan membuat ini lebih menarik bagi kami lebih jauh. Mengingat hal itu, pemikiran saya adalah bahwa kami akan terus menggunakan .NET Framework untuk ceruk ini untuk beberapa waktu mendatang. Saya mungkin salah paham.

Semua alat ini, datang dengan pengorbanan. Misalnya, crossgen menghasilkan kode asli sebelumnya sehingga membantu startup, tetapi cenderung meningkatkan ukuran binari.

Yap, mengerti bahwa beberapa di antaranya adalah pedang bermata dua. Dengan cara kerja JIT secara tradisional, ngen selalu menjadi pemenang untuk aplikasi CLI/GUI. Ada kemungkinan bahwa beberapa kombinasi kompilasi berjenjang dan fakta bahwa memuat runtime itu sendiri belum tentu diamortisasi oleh banyak proses .NET Framework lainnya yang berjalan pada kotak yang sama membuat pemotongan yang kurang jelas pada Core.

@swaroop-sridhar kekhawatiran besar yang saya miliki dengan proposal yang saat ini diterima adalah langkah ini

Sisa 216 file akan diekstraksi ke disk saat startup.

Selain fakta bahwa "Hello World" tampaknya memerlukan 216 file untuk dijalankan, mengekstraknya ke disk di beberapa lokasi membuat penghapusan aplikasi baris perintah sederhana menjadi sulit. Ketika orang menghapus alat yang tidak datang melalui penginstal, mereka tidak perlu mencari file lain untuk menghapusnya sepenuhnya.

IMHO, kita harus menargetkan pengalaman publikasi yang mirip dengan golang. Meskipun akan membutuhkan crossgen berada di tempat untuk sepenuhnya mencocokkan pengalaman golang (dan orang dapat berargumen bahwa pertandingan 1:1 bukanlah hal yang _baik_, karena kita kalah dalam kompilasi JIT dan berjenjang), a porsi yang baik dapat dicapai tanpa itu. Saya telah menggunakan banyak alat selama bertahun-tahun untuk mencapai pengalaman serupa, dan yang paling efektif adalah sumber daya yang disematkan dengan pengait pada pemuat perakitan (ILMerge rewel dan Costura.Fody belum ada). Apa yang dijelaskan dalam proposal bahkan tidak sepenuhnya mereplikasi fungsi itu. .NET Core memiliki masa depan yang sangat kuat, tetapi penggunaannya untuk mengembangkan alat baris perintah terbatas selama kita perlu membawa sekitar 100-an dependensi atau mengeluarkannya di suatu tempat di disk dengan beberapa kode bootstrap yang bergelombang.

Kasus penggunaan dotnet/coreclr#1 saya adalah utilitas baris perintah, satu file, tidak ada ekstraksi yang menjadi preferensi saya. Tapi saya akan menunjukkan bahwa memberikan pilihan sebagai bagian dari perintah switch untuk all-in-one vs all-in-one-self-extracting. Dalam kasus self-extracting itu harus menyertakan undo yang membersihkan file yang belum dibongkar. Dalam kasus pertama, menghapus utilitas berarti menghapus satu file yang membuatnya cocok untuk berada di folder utilitas umum, sedangkan-seperti dalam kasus ke-2, penginstalan harus memiliki foldernya sendiri untuk memudahkan pembersihan, dan menghindari skenario di mana uninstall menghapus file bersama. Hanya beberapa pemikiran. Seperti yang saya katakan, utilitas satu file (tidak perlu menginstal), adalah kasus penggunaan utama saya karena saya sering membuat utilitas untuk proyek (sebagai tukang alat). Tapi saya bisa melihat kasus penggunaan untuk kedua skenario. Tapi mereka berbeda .

Saya punya beberapa pertanyaan untuk orang-orang yang ingin menggunakan file tunggal. Jawaban Anda akan membantu kami mempersempit pilihan kami:

1. Jenis aplikasi apa yang kemungkinan besar akan Anda gunakan? (mis. WPF di Windows? ASP.NET dalam wadah Linux Docker? Sesuatu yang lain?)
2. Apakah aplikasi Anda menyertakan (non-.NET) C++/kode asli?
3. Apakah aplikasi Anda akan memuat plugin atau dll eksternal lainnya yang awalnya tidak Anda sertakan dalam pembuatan aplikasi?
4. Apakah Anda bersedia membangun kembali dan mendistribusikan ulang aplikasi Anda untuk memasukkan perbaikan keamanan?
5. Apakah Anda akan menggunakannya jika aplikasi Anda mulai 200-500 md lebih lambat? Bagaimana dengan 5 detik?
6. Berapa ukuran terbesar yang Anda anggap dapat diterima untuk aplikasi Anda? 5MB? 10? 20? 50? 75? 100?
7. Apakah Anda akan menerima waktu pembuatan rilis yang lebih lama untuk mengoptimalkan ukuran dan/atau waktu mulai? Apa yang paling lama Anda terima? 15 detik? 30 detik? 1 menit? 5 menit?
8. Apakah Anda bersedia melakukan pekerjaan ekstra jika itu akan memotong ukuran aplikasi Anda menjadi dua?

1. CLI (Windows, Linux, MacOS), WPF dan WinForms.
2. Kadang-kadang.
3. Ya, berkali-kali dan saya pikir skenario bahwa plugin dapat menggunakan kembali perpustakaan bersama dari aplikasi utama harus ditangani!
4. Ya.
5. 200-500ms ok!
6. Untuk aplikasi CLI sederhana tanpa banyak ketergantungan, 10MB sudah cukup (dikompresi)!
7. Ya pasti! Waktu build (terutama untuk build rilis!) tidak masalah! Ukuran kompresi dan/atau beralih ke penerbitan satu file harus opsional!
8. Ya, misalnya CoreRT!

IMHO, kita harus menargetkan pengalaman publikasi yang mirip dengan golang.

@thegreatco : Ya, kompilasi lengkap ke kode asli adalah pilihan yang baik untuk membangun aplikasi file tunggal. Bahasa seperti GO dibuat dengan kompilasi sebelumnya (AOT) sebagai model utamanya -- yang hadir dengan batasan tertentu pada fitur bahasa dinamis yang dicapai melalui kompilasi JIT.

CoreRT adalah solusi .Net Core untuk aplikasi yang dikompilasi AOT. Namun, hingga CoreRT tersedia, kami mencoba mencapai aplikasi file tunggal melalui cara lain dalam masalah ini.

Selain fakta bahwa "Hello World" tampaknya memerlukan 216 file untuk dijalankan,

Ada beberapa opsi yang tersedia untuk mengurangi jumlah file yang diperlukan untuk HelloWorld"

• Bangun aplikasi yang bergantung pada kerangka kerja, yang hanya membutuhkan 3-4 file
• Jika kita perlu membangun aplikasi mandiri, gunakan ILLinker untuk mengurangi jumlah dependensi file

mengekstraknya ke disk di beberapa lokasi membuat penghapusan aplikasi baris perintah sederhana menjadi sulit.

• Saat pengembangan fitur file tunggal bergerak ke tahap lebih lanjut , jumlah file yang tumpah ke disk akan berkurang, dan idealnya nol untuk sebagian besar aplikasi. Tetapi pada tahap awal, beberapa file (yang berisi kode asli) harus ditumpahkan.
• Lokasi file yang tumpah ke disk selalu deterministik dan dapat dikonfigurasi. Jadi, file yang tumpah dapat dibersihkan dengan skrip langsung. Tapi saya setuju bahwa ini tidak ideal.

Terima kasih atas klarifikasinya @mattpwhite.

Ya, hingga tahap pengembangan fitur selanjutnya, aplikasi mandiri akan melihat file yang diekstraksi ke disk. Anda mungkin dapat menggunakan beberapa teknik yang saya tulis di komentar di atas untuk memperbaiki situasi aplikasi Anda.

Terima kasih atas tanggapan Anda @BlitzkriegSoftware.

Tapi saya akan menunjukkan bahwa memberikan pilihan sebagai bagian dari perintah switch untuk all-in-one vs all-in-one-self-extracting

Apakah aplikasi yang diterbitkan sebagai file tunggal memerlukan ekstraksi bergantung pada konten aplikasi (mis: apakah aplikasi tersebut berisi file asli). Desain bundler menyediakan beberapa konfigurasi untuk memutuskan apakah semua file harus diekstraksi. Kita dapat menambahkan properti untuk mengatakan bahwa aplikasi tidak boleh menggunakan ekstraksi ke file saat dijalankan.

<propertygroup>
    <SingleFileExtract> Never | Always | AsNeeded </SingleFileExtract>
</propertygroup>

Pengertian di sini adalah: saat mengkompilasi SingleFileExtract=Tidak pernah, jika aplikasi berisi file yang hanya dapat ditangani melalui ekstraksi (binari asli), maka penerbitan ke satu file akan gagal.

Dalam kasus self-extracting itu harus menyertakan undo yang membersihkan file yang belum dibongkar.

Kedengarannya masuk akal. Lokasi ekstraksi yang tepat (jika ada) bersifat deterministik dan dapat dikonfigurasi. Jadi, kita dapat memiliki skrip untuk menghapus aplikasi dan semua dependensi yang diekstraksi.

Terima kasih atas tanggapan Anda @DoCode. Skenario Anda menarik karena menggunakan plugin.
Jika Plugin itu sendiri memiliki beberapa dependensi (yang tidak dibagikan dengan aplikasi utama), apakah Anda perlu/lebih memilih untuk menerbitkan plugin sebagai file tunggal juga (dengan dependensi yang disematkan)? Terima kasih.

Ya @swaroop-sridhar, itu tujuannya. Kami berpikir bahwa dalam hal ini plugin harus disematkan dependensinya. Hanya dependensi bersama yang seharusnya tetap berada di luar dari aplikasi utama file tunggal.

Hari ini, @madskristensen membagikan klarifikasi yang bagus dengan Visual Studio dan paket Newtonsoft.Json NuGet yang populer.

Kami situasi yang sama dalam situasi yang sama kadang-kadang!

Terima kasih @DoCode. Kami merencanakan alamat fitur plugin file tunggal, setelah aplikasi file tunggal diimplementasikan dan stabil. Dokumen desain berbicara tentang plugin di sini .

Terima kasih atas keterlibatan berkelanjutan pada fitur ini @swaroop-sridhar, sangat dihargai. Memiliki perintah undo akan sangat bagus untuk tahap asli khususnya.

1. Jenis aplikasi apa yang kemungkinan besar akan Anda gunakan? (mis. WPF di Windows? ASP.NET dalam wadah Linux Docker? Sesuatu yang lain?)
   -- Utilitas baris perintah (aplikasi konsol)
2. Apakah aplikasi Anda menyertakan (non-.NET) C++/kode asli?
   -- Tidak
3. Apakah aplikasi Anda akan memuat plugin atau dll eksternal lainnya yang awalnya tidak Anda sertakan dalam pembuatan aplikasi?
   -- Tidak biasanya
4. Apakah Anda bersedia membangun kembali dan mendistribusikan ulang aplikasi Anda untuk memasukkan perbaikan keamanan?
   -- Iya
5. Apakah Anda akan menggunakannya jika aplikasi Anda mulai 200-500 md lebih lambat? Bagaimana dengan 5 detik?
   -- <1 Detik akan menjadi preferensi saya
6. Berapa ukuran terbesar yang Anda anggap dapat diterima untuk aplikasi Anda? 5MB? 10? 20? 50? 75? 100?
   -- Ukuran tidak penting
7. Apakah Anda akan menerima waktu pembuatan rilis yang lebih lama untuk mengoptimalkan ukuran dan/atau waktu mulai? Apa yang paling lama Anda terima? 15 detik? 30 detik? 1 menit? 5 menit?
   -- 30 detik
8. Apakah Anda bersedia melakukan pekerjaan ekstra jika itu akan memotong ukuran aplikasi Anda menjadi dua?
   -- Tentu jika itu dapat ditulis atau dikonfigurasi

1 - Jenis aplikasi apa yang kemungkinan besar akan Anda gunakan? (mis. WPF di Windows? ASP.NET dalam wadah Linux Docker? Sesuatu yang lain?)

• permainan
• Alat baris perintah

2 - Apakah aplikasi Anda menyertakan (non-.NET) C++/kode asli?

Ya

3 - Apakah aplikasi Anda akan memuat plugin atau dll eksternal lainnya yang awalnya tidak Anda sertakan dalam pembuatan aplikasi?

Ya, tetapi dengan simbol yang sudah diketahui, saya tidak mengandalkan refleksi karena lambat

4 - Apakah Anda bersedia membangun kembali dan mendistribusikan ulang aplikasi Anda untuk memasukkan perbaikan keamanan?

Ya

5 - Apakah Anda akan menggunakannya jika aplikasi Anda mulai 200-500 mdtk lebih lambat? Bagaimana dengan 5 detik?

Tidak, ini sudah agak lambat

6 - Berapa ukuran terbesar yang Anda anggap dapat diterima untuk aplikasi Anda? 5MB? 10? 20? 50? 75? 100?

Tergantung pada proyeknya, tetapi untuk alat baris perintah sederhana, saya tidak berharap itu lebih besar dari satu digit mbs

7 - Apakah Anda akan menerima waktu pembuatan rilis yang lebih lama untuk mengoptimalkan ukuran dan/atau waktu mulai? Apa yang paling lama Anda terima? 15 detik? 30 detik? 1 menit? 5 menit?

Selama itu tidak memengaruhi waktu pengembangan/iterasi, saya baik-baik saja dengan waktu pembuatan rilis yang lebih lama
Tapi ingat, aplikasi inti .net sudah dibuat lebih lama daripada aplikasi kerangka kerja .net tradisional

Kecenderungan perangkat lunak yang lebih lambat setiap tahun TIDAK dapat diterima, kami memiliki perangkat keras yang lebih baik, tidak ada alasan untuk kelambatan itu

8 - Apakah Anda bersedia melakukan pekerjaan ekstra jika itu akan memotong ukuran aplikasi Anda menjadi dua?

YA!

Saya sangat berharap kompilasi AOT dengan CoreRT berfungsi suatu hari nanti sehingga kami dapat mengkompilasi aplikasi secara native seperti golang dan rust dan bahasa kompilasi AOT lainnya. Demikian pula dengan bagaimana Unity3D melakukannya dengan IL2CPP.

@morganbr Berikut adalah beberapa masukan dari saya dan orang-orang yang bekerja dengan saya. Saya menggunakan banyak bahasa, tetapi terutama C#, Go, dan Python.

Jenis aplikasi apa yang kemungkinan besar akan Anda gunakan? (mis. WPF di Windows? ASP.NET dalam wadah Linux Docker? Sesuatu yang lain?)

Program Inti dan Konsol ASP.NET, sebagian besar di Linux, berpotensi beberapa beban kerja Windows, tergantung pada apakah ML.NET memenuhi kebutuhan kita.

Apakah aplikasi Anda menyertakan (non-.NET) C++/kode asli?

Tidak mungkin pada saat ini.

Apakah aplikasi Anda akan memuat plugin atau dll eksternal lainnya yang awalnya tidak Anda sertakan dalam pembuatan aplikasi?

Tergantung. Saat ini kami dapat menarik semua dependensi kami sebagai paket, tetapi saya dapat melihat situasi di mana kami membayar untuk perpustakaan komersial, yang mungkin berarti menggunakan DLL eksternal.

Apakah Anda bersedia membangun kembali dan mendistribusikan ulang aplikasi Anda untuk memasukkan perbaikan keamanan?

Sangat. Ini adalah prioritas utama bagi kami.

Apakah Anda akan menggunakannya jika aplikasi Anda mulai 200-500 md lebih lambat? Bagaimana dengan 5 detik?

Saya akan mengatakan bahwa apa pun yang kurang dari 10 detik lebih dari baik bagi saya. Waktu mulai umumnya tidak masalah selama itu idempoten dan dapat diprediksi - yaitu perpustakaan dimuat dalam urutan yang sama, variabel diinisialisasi dalam urutan yang sama, dll.

Berapa ukuran terbesar yang Anda anggap dapat diterima untuk aplikasi Anda? 5MB? 10? 20? 50? 75? 100?

Lebih kecil lebih baik, sebagian besar untuk tujuan distribusi. Distribusi dapat berupa binari yang diunduh pengguna, gambar kontainer dengan biner, dll.

Apakah Anda akan menerima waktu pembuatan rilis yang lebih lama untuk mengoptimalkan ukuran dan/atau waktu mulai?

Tentu, selama lebih cepat dari C/C++ dan Java, itu harus menyenangkan.

Apa yang paling lama Anda terima? 15 detik? 30 detik? 1 menit? 5 menit?

Kemungkinan 30-90 detik akan ideal, tetapi apa pun di bawah 3 menit kemungkinan akan menyenangkan. Lebih dari 3 menit untuk proyek kecil/menengah (1k-500k LOC) akan sedikit banyak. 5 menit untuk proyek yang sangat besar (1M LOC) dapat diterima.

Apakah Anda bersedia melakukan pekerjaan ekstra jika itu akan memotong ukuran aplikasi Anda menjadi dua?

Tergantung. Jika pekerjaan ekstra adalah menambahkan kode boilerplate yang dapat ditemplat, itu mungkin baik-baik saja. Jika tidak jelas, tidak langsung bekerja, berpotensi tidak.

Terima kasih atas tanggapannya @mxplusb , @dark2201 , @RUSshy , @BlitzkriegSoftware

Saya percaya desain saat ini membahas skenario Anda sebaik mungkin tanpa adanya kompilasi AOT murni. Jika Anda memiliki masalah dengan desain, jangan ragu untuk menyampaikannya.

Sehubungan dengan waktu startup dan waktu kompilasi yang lebih rendah:
Aplikasi yang bergantung pada kerangka kerja akan memiliki waktu startup yang jauh lebih rendah (setidaknya pada tahap awal kemunculan fitur). Waktu kompilasi juga lebih kecil (karena lebih sedikit file yang perlu disematkan).
Saya akan menghubungi Anda kembali dengan waktu startup, throughput kompilasi, dan pengukuran ukuran file segera setelah iterasi pertama pengembangan fitur selesai.

@swaroop-sridhar Apa timeline untuk itu?

@ayende Iterasi pertama sedang dalam pengembangan aktif, saya pikir kami akan mendapatkan hasilnya dalam beberapa minggu.

@swaroop-sridhar

Saya percaya desain saat ini membahas skenario Anda sebaik mungkin tanpa adanya kompilasi AOT murni. Jika Anda memiliki masalah dengan desain, jangan ragu untuk menyampaikannya.

Jalankan: HelloWorld.exe

Aplikasi yang dibundel dan file konfigurasi diproses langsung dari bundel.
Sisa 216 file akan diekstraksi ke disk saat startup.

Bagaimana jika saya perlu menjalankan dari read only fs, ini umum untuk IoT, atau jika exe berjalan di dalam wadah ro? mengapa tidak ada opsi untuk menjalankannya langsung dari exe juga?

@etherealjoy Contoh yang ditampilkan di bagian ini adalah keluaran yang diharapkan untuk HelloWorld mandiri pada Tahap 2 pengembangan fitur ini (seperti yang disebutkan di bagian ini ). Pada tahap ini, satu-satunya aplikasi yang dapat berjalan langsung dari EXE adalah aplikasi yang dikelola murni yang bergantung pada kerangka kerja.

Jika kita berada di Tahap 4 atau Tahap 5 , aplikasi mandiri di atas dapat dijalankan langsung dari bundel.

Jenis aplikasi apa yang kemungkinan besar akan Anda gunakan? (mis. WPF di Windows? ASP.NET dalam wadah Linux Docker? Sesuatu yang lain?)

Pada dasarnya semua di atas. Utilitas konsol, WPF, asp.net, game

Apakah aplikasi Anda menyertakan (non-.NET) C++/kode asli?

Ya. Sqlite adalah contoh yang bagus.

Apakah aplikasi Anda akan memuat plugin atau dll eksternal lainnya yang awalnya tidak Anda sertakan dalam pembuatan aplikasi?

Mungkin tidak.

Apakah Anda bersedia membangun kembali dan mendistribusikan ulang aplikasi Anda untuk memasukkan perbaikan keamanan?

Ya.

Apakah Anda akan menggunakannya jika aplikasi Anda mulai 200-500 md lebih lambat? Bagaimana dengan 5 detik?

net.core sudah agak terlalu lambat. Tetapi peningkatan beberapa detik dapat diterima. 5 detik -- pasti tidak.

Berapa ukuran terbesar yang Anda anggap dapat diterima untuk aplikasi Anda? 5MB? 10? 20? 50? 75? 100?

Tidak masalah saat ini

Apakah Anda akan menerima waktu pembuatan rilis yang lebih lama untuk mengoptimalkan ukuran dan/atau waktu mulai? Apa yang paling lama Anda terima? 15 detik? 30 detik? 1 menit? 5 menit?

Hingga 5 menit terasa dapat diterima. Pembuatan rilis 15-20 menit untuk UWP membuat semua orang marah.

Apakah Anda bersedia melakukan pekerjaan ekstra jika itu akan memotong ukuran aplikasi Anda menjadi dua?

Tentu.

Terima kasih @mjr27

Implementasi tahap 1 sekarang telah selesai, dan tersedia mulai 3.0.100-preview5-011568 .

Aplikasi dapat dipublikasikan ke satu file dengan menyetel properti PublishSingleFile menjadi true seperti yang dijelaskan di sini .

Dalam versi ini, semua file yang disematkan diekstraksi ke disk saat pertama kali dijalankan, dan digunakan kembali di proses berikutnya, seperti yang dijelaskan di sini .

Throughput kompilasi
Tidak ada perbedaan waktu yang signifikan apakah file ditulis ke direktori publish sebagai file individual atau sebagai file tunggal.

Ukuran File dan Startup
Tabel berikut menunjukkan kinerja untuk beberapa aplikasi yang dibuat sebagai file tunggal.

• Konsol: Aplikasi halo dunia. Waktu yang dilaporkan adalah waktu untuk menjalankan aplikasi, diukur melalui clock ticks.
• Aplikasi WPF: aplikasi msix-catalog . Waktu yang dilaporkan adalah waktu untuk memulai ke layar awal, diukur melalui stopwatch.
• Fw: Build yang bergantung pada kerangka kerja
• Self: Bangunan mandiri.
  Semua proses dihitung saat pemeriksaan Anti-virus dimatikan untuk meminimalkan dampak faktor eksternal.

Pengukuran | Konsol Fw | Diri Konsol | WPF Fw | WPF Diri
-- | -- | -- | -- | --
Ukuran File (MB) | 0,32 | 66,5 | 20.69 | 118.9
Lari Normal (dtk) | 0,123 | 0,127 | 3.32 | 3.24
Jalankan pertama exe tunggal (dtk) | 0,127 | 0,565 | 3.67 | 4.14
Single-exe berikutnya berjalan (dtk) | 0,124 | 0,128 | 3.30 | 3.29

Saya akan terus memperbarui angkanya saat implementasi berlanjut ke tahap pengembangan selanjutnya .

Berita bagus. Terima kasih

Apakah semua tahapan yang disebutkan dalam dokumen pementasan selesai untuk 3.0 RTM? Atau kita harus menunggu post 3.0 untuk implementasinya?

Seperti yang disebutkan di sini , .net core 3.0 diharapkan dapat mengimplementasikan Tahap 2 sehingga aplikasi msil murni yang bergantung pada kerangka kerja dapat berjalan langsung dari bundel. Tahap yang tersisa akan dipertimbangkan untuk rilis lebih lanjut.

Seperti yang disebutkan di sini , .net core 3.0 diharapkan dapat mengimplementasikan Tahap 2 sehingga aplikasi msil murni yang bergantung pada kerangka kerja dapat berjalan langsung dari bundel. Tahap yang tersisa akan dipertimbangkan untuk rilis lebih lanjut.

:( berharap bisa sampai ke RTM.

@cup Saya pikir Anda bisa melakukannya dengan dotnet publish -o out /p:PublishSingleFile=true /p:RuntimeIdentifier=win-x64 . Saya baru saja menguji dengan membuat aplikasi konsol vanilla dan menjalankan perintah itu. Ini berhasil.

Anda dapat melangkah lebih jauh dengan menggabungkan file .pdb dengan dotnet publish -o out /p:PublishSingleFile=true /p:RuntimeIdentifier=win-x64 /p:IncludeSymbolsInSingleFile=true

Terima kasih @seesharprun untuk catatan detailnya. Ya @cup , metode yang disarankan untuk penerbitan file tunggal baris perintah adalah dengan menyetel properti PublishSingleFile dari baris perintah.

@etherealjoy coreclr runtime repo sebagian besar akan dikunci fitur wrt bekerja dalam satu bulan atau lebih. Saya tidak berpikir ada cukup waktu untuk semua tahapan. Saya berharap bahwa tahap selanjutnya akan datang di rilis berikutnya.

Saya berhasil hari ini tetapi tampaknya mengubah direktori basis ekstraksi tidak berfungsi. Menurut bagian ini. Saya harus dapat menambahkan sakelar aplikasi di runtimeconfig yang disebut ExtractBaseDir untuk mengubah lokasi tempat aplikasi diekstraksi.

Saya memiliki runtimeconfig.template.json yang terlihat seperti ini

{
    "configProperties" : {
        "ExtractBaseDir": "C:\\"
    },
    "ExtractBaseDir": "C:\\"   
}

app.runtimeconfig.json yang dihasilkan terlihat seperti ini:

{
  "runtimeOptions": {
    "configProperties": {
      "ExtractBaseDir": "C:\\"
    },
    "ExtractBaseDir": "C:\\"
  }
}

Saat dijalankan meskipun exe yang dihasilkan masih extacts ke folder tmp.

Saya berasumsi fitur ini belum siap di Preview5 tetapi saya ingin memastikan karena tidak jelas ke mana "ExtractBaseDir" seharusnya masuk runtimeconfig.json dan tidak ada contoh.

@igloo15 Terima kasih telah mengemukakan ini.

Dalam pratinjau saat ini, hanya variabel lingkungan DOTNET_BUNDLE_EXTRACT_BASE_DIR yang diaktifkan. Ini karena pada tahap implementasi saat ini semua file -- termasuk runtimeconfig.json -- diekstraksi ke disk sebelum diproses.

Saya sedang berupaya menambahkan dukungan untuk ExtractBaseDir di pratinjau berikutnya.

Apakah ada panduan tentang cara membuat ini berfungsi dengan proyek ASP.NET Core? Apakah pendekatan yang disarankan adalah menggunakan refleksi untuk menemukan dari mana tipe Sistem saya memuat dan mengatur IHostingEnvironment ContentRootPath dan WebRootPath saya relatif terhadap direktori itu?

@keithwill Anda dapat menggunakan AppContext.BaseDirectory untuk mendapatkan lokasi di mana app.dll dan semua file lainnya diekstraksi ke disk. Jadi, Anda dapat menggunakan ini sebagai ContentRootPath .

@igloo15 : Saya ingin tahu apakah Anda bisa membagikan apa skenario Anda untuk menggunakan opsi ini.

• Apakah Anda mencoba menggunakannya untuk skenario debugging atau penyebaran produksi?
• Apakah variabel lingkungan cukup dalam kasus ini, atau apakah Anda memerlukan pengaturan runtimeconfig.json ?

Saya juga ingin mendengar dari pengembang lain, jika ada kasus penggunaan khusus untuk pengaturan ini.

@swaroop-sridhar

Saya memiliki situasi yang agak aneh. Perangkat lunak saya disimpan di jaringan berbagi dan kemudian berbagi jaringan ditautkan ke windows vm acak dan dijalankan langsung dari jaringan berbagi. Windows vm yang diputar untuk menjalankan perangkat lunak dari berbagi jaringan tidak dapat dimodifikasi atau diubah apa pun. Log, file Config, dll semua harus dibuat di jaringan berbagi.

Anehnya, pengaturan ini memungkinkan sistem secara keseluruhan untuk mengatur beberapa bagian perangkat lunak dalam folder dan kemudian mengkloning struktur folder itu untuk konfigurasi/versi yang berbeda. Kemudian ketika versi tertentu harus dijalankan, perangkat lunak pengelola akan memutar vms dan memetakan drive pada vms ke jaringan versi tertentu dan menjalankan perangkat lunak.

1.) Ini adalah skenario penyebaran produksi
2.) Variabel lingkungan akan sulit karena komputer yang menjalankan perangkat lunak selalu berbeda dan dihancurkan/dibuat ulang

@cup Saya sangat tidak setuju topik ini tentang penerapan dokumen desain dan dokumen desain secara khusus mengatakan ExtractBaseDir harus bekerja untuk fitur ini.

Jika masalah ini bukan tentang penerapan dokumen desain ini, lalu tentang apa masalah ini?

Terima kasih atas penjelasannya @igloo15.

Saya bertanya tentang opsi konfigurasi, karena ada biaya untuk mengurai file konfigurasi di awal kode AppHost. Saat ini AppHost tidak terhubung dengan kode untuk menguraikan file json (sebagai gantinya digunakan oleh hostfxr/hostpolicy). Menambahkan fitur ini saat ini akan membuat AppHost sedikit lebih besar/kompleks. Namun begitu implementasi berlanjut ke tahap lebih lanjut (di mana semua hosting dan kode runtime ditautkan bersama), ini tidak lagi menjadi masalah.

@igloo15 dokumen desain adalah bagian penting darinya, tetapi inti dari masalah ini adalah fitur itu sendiri. ExtractBaseDir adalah parameter opsional dan saya lebih suka melihat fitur inti diteruskan ke rilis "saat ini" daripada terjebak dengan parameter opsional.

@cup , saya mengajukan pertanyaan di sini, karena saya mendapat perhatian dari pengembang yang tertarik di utas ini.
Meskipun saya tidak berpikir pertanyaannya di luar topik, saya mengerti kekhawatiran Anda tentang panjangnya utas ini. Saya akan membuat masalah terkait waktu berikutnya. Terima kasih.

@cup @swaroop-sridhar

Beberapa hal yang akan saya katakan pertama adalah bahwa fitur ini hanya penting untuk tahap 1 dari dokumen tahap . Semua tahap 2 - 5 lainnya adalah tentang menjalankan dll dari dalam bundel dan tidak mengekstraksi. Jadi pengaturan untuk menentukan lokasi dir basis ekstrak tidak terlalu berguna untuk tahap 2-5. Karena NetCore 3.0 bermaksud untuk mengembangkan tahap 1, saya berharap fitur ini ada di sana karena hanya itu yang akan berguna.

Kedua adalah bagaimana kita membedakan metode ini dari metode lain seperti dotnet-wrap. Bagi saya keuntungan utama dari metode ini adalah bahwa kita sedang membangun proses ini ke dalam rantai pembangunan yang lebih dekat dengan ketika kode sedang dikompilasi. Selain itu ini adalah fitur yang ditujukan untuk .NET dan dengan demikian memahami nuansa aplikasi .NET Core seperti konfigurasinya, proses pembuatan, dll. Karena itu saya berharap kami fokus pada fitur yang membedakan alat ini dari alat lain yang tidak diarahkan khusus untuk inti bersih. Ini akan menjadi fitur seperti mengonfigurasi lokasi ekstraksi yang tidak dapat dilakukan oleh dotnet-wrap.

Sejauh bagaimana penerapannya, saya tidak yakin tetapi saya akan berpikir bahwa daripada membaca ExtractBaseDir dari konfigurasi saat runtime, tidak bisakah kita memasukkannya ke dalam bundel exe pada waktu pembuatan? Saya belum melihat kode yang membuat proses bundel ini berfungsi tetapi dalam pikiran saya ini menghasilkan/membangun exe asli dengan semua dll dll di dalamnya. Tidak bisakah kita selama pembuatan/pembuatan exe membaca file runtimeconfig aplikasi yang dibundel mengeluarkan ExtractBaseDir dan menetapkannya sebagai properti pada exe bundel asli.

Maka itu tidak membaca runtimeconfig yang disematkan saat runtime tetapi malah memanfaatkan properti secara internal untuk menentukan lokasi ekstraksi. Itu berpotensi menjadi jauh lebih cepat.

@igloo15 : Mengekstrak konten bundel ke disk mungkin berguna untuk aplikasi tertentu di luar Tahap 2.
Misalnya, jika aplikasi memiliki binari asli khusus dalam bundel, maka mereka harus diekstraksi hingga Tahap 5. Aplikasi mungkin ingin menggabungkan file konten dari jenis yang tidak diketahui untuk diekstraksi ke file saat runtime.

Saya setuju bahwa utilitas pengaturan ini berkurang saat kita beralih ke tahap pengembangan lebih lanjut. Namun, setelah kami menambahkan opsi, kami mungkin harus menyimpannya di semua versi berikutnya untuk kompatibilitas. Oleh karena itu, perlu pertimbangan yang matang sekarang.

Saya setuju bahwa menjadikan lokasi ekstraksi sebagai pengaturan waktu pembuatan (mis: msbuild-property) daripada opsi runtimeconfig adalah implementasi wrt yang lebih mudah dan lebih efisien. Terima kasih.

Halo, Saya punya beberapa pertanyaan tentang topik ini:

Saya ingin menggunakan fitur Distribusi File Tunggal untuk mengemas aplikasi .NET Framework 4.7.2 (misalnya) ke dalam satu executable. Apakah itu maksud dari fitur ini atau hanya untuk mendukung aplikasi .NET Core?

Pertanyaan kedua saya terkait dengan bagaimana pengemasan dilakukan. Ketika executable dibuat, apakah runtime kerangka kerja target akan digabungkan ke dalam executable? Atau harus diinstal sebelumnya pada mesin target yang akan menjalankan aplikasi?

@gaviriar Saya tidak berpikir itu mendukung aplikasi .NET Framework. Dan ya itu dapat menggabungkan runtime .NET Core menjadi executable (disebut "self-contained" publish).

@tomrus88 terima kasih atas tanggapannya. Itu benar-benar memalukan mengenai aplikasi .NET Framework. Apakah ada metode yang Anda rekomendasikan yang dapat digunakan untuk menggabungkan runtime .NET Framework menjadi executable?

Saya melihat daftar alat di bagian kerja terkait dokumen. Apakah ada hal khusus yang dapat direkomendasikan untuk kasus penggunaan saya yang diusulkan di atas?

@gaviriar .NET Framework adalah bagian dari OS Windows. Tidak ada cara yang didukung untuk menggabungkannya menjadi executable.

@gaviriar Kebutuhan untuk menggabungkan runtime adalah salah satu alasan utama untuk beralih ke .NET Core.

@jnm2 dan @jkotas terima kasih atas klarifikasinya, noob di sini ke dunia .NET. Saya setuju saya akan senang untuk beralih ke .NET Core. Namun, saya menghadapi kasus di mana saya harus berinteraksi dengan perpustakaan lama yang menargetkan .NET Framework. Dalam kasus seperti itu, pemahaman saya bahwa saya tidak dapat mengalihkan aplikasi saya ke .NET Core jika saya perlu berinteraksi dengan perpustakaan ini. Atau adakah pendekatan alternatif sehingga aplikasi saya adalah .NET Core tetapi masih dapat berinteraksi dengan pustaka .NET Framework lama?

Itu tergantung pada perpustakaan. Banyak perpustakaan yang menargetkan .NET Framework juga berfungsi dengan baik di .NET Core. Sudahkah Anda mencoba menggunakan perpustakaan di .NET Core? Jika Anda telah memverifikasi bahwa itu tidak berfungsi, Anda tidak dapat beralih sampai Anda memiliki solusi untuk itu.

Saya memang sudah mencobanya, tetapi ini tidak berhasil karena kita berbicara tentang perpustakaan yang khusus untuk windows. Saya kira saya tidak punya pilihan lain selain tetap dengan penargetan .NET Framework dan kehilangan kesenangan .NET Core seperti yang Anda katakan:/

@gaviriar Ini di luar topik tetapi apakah Anda sudah mencoba Paket NuGet Kompatibilitas Windows yang menyediakan windows apis untuk .NET Core untuk tujuan persis yang Anda gambarkan Microsoft.Windows.Compatibility

@gaviriar : Beberapa klarifikasi lagi:

Ketika executable dibuat, apakah runtime kerangka kerja target akan digabungkan ke dalam executable? Atau harus diinstal sebelumnya pada mesin target yang akan menjalankan aplikasi?

Hal ini tergantung pada membangun. Baik aplikasi yang bergantung pada kerangka kerja (waktu proses diinstal pada target), dan aplikasi mandiri (waktu proses dikemas dengan aplikasi) dapat dipublikasikan sebagai file tunggal -- tetapi hanya aplikasi .net core 3.0.

Saya melihat daftar alat di bagian kerja terkait dokumen. Apakah ada hal khusus yang dapat direkomendasikan untuk kasus penggunaan saya yang diusulkan di atas?

Untuk .net framework, solusi terbaik yang bisa saya sarankan adalah aplikasi menangani ekstraksi file untuk dirinya sendiri. Misalnya: sematkan dependensi sebagai sumber daya terkelola dalam biner aplikasi, lalu ekstrak sumber daya secara eksplisit saat startup. Anda juga dapat menggunakan perpustakaan bundel untuk bundling dan ekstraksi (karena perpustakaan dibangun standar bersih), tetapi menggunakan sumber daya yang dikelola adalah solusi yang lebih baik.

@igloo15 dan @swaroop-sridhar Saya menghargai masukan ini mengingat mereka di luar topik. Meskipun saya berharap orang lain menemukan diskusi ini berguna ketika membaca suatu hari nanti.

Saya akan mengevaluasi opsi yang telah Anda bagikan dengan saya dan memberi tahu Anda apa yang ternyata menjadi pendekatan terbaik untuk kasus penggunaan saya.

Terima kasih!

Pembaruan cepat!

Saya telah menguji aplikasi Hello World sederhana ini. Saya berhasil membuat satu file yang dapat dieksekusi. Namun seperti yang Anda lihat dari konfigurasi proyek, itu dimaksudkan untuk mandiri. Tetapi ketika saya mencoba menjalankan executable ini pada instalasi Windows 7 yang baru tanpa .NET core runtime yang diinstal, saya melihat kesalahan berikut:

Failed to load the DLL from [C:\Users\vagrant\AppData\Local\Temp\.net\HelloWorld
\muasjfkf.kyn\hostfxr.dll], HRESULT: 0x80070057
The library hostfxr.dll was found, but loading it from C:\Users\vagrant\AppData\
Local\Temp\.net\HelloWorld\muasjfkf.kyn\hostfxr.dll failed
  - Installing .NET Core prerequisites might help resolve this problem.
     https://go.microsoft.com/fwlink/?linkid=798306

Apa yang dapat saya lihat adalah bahwa membangun penerbitan aplikasi sebagai dotnet publish /p:PublishSingleFile=true atau /p:PublishSingleFile=false tidak mengubah ukuran executable. Apakah ini perilaku yang diharapkan?

Langkah-langkah untuk Reproduksi

1. Publikasikan proyek untuk menghasilkan HelloWorld.exe

2. Salin executable ke instalasi Windows 7 tanpa runtime .NET Core diinstal

3. Jalankan HelloWorld.exe

@gaviriar Saya mencoba contoh yang telah Anda terbitkan, dan itu berfungsi dengan baik untuk saya.
Artinya, ia membangun exe tunggal mandiri untuk HelloWorld yang berjalan dengan baik.

Apa yang dapat saya lihat adalah bahwa membangun penerbitan aplikasi sebagai dotnet publish /p:PublishSingleFile=true atau /p:PublishSingleFile=false tidak mengubah ukuran file yang dapat dieksekusi. Apakah ini perilaku yang diharapkan?

Ini pasti tidak diharapkan. Aplikasi file tunggal harus sekitar 70MB (untuk build debug yang ditunjukkan pada halaman gitlab Anda). Jika tidak, itu adalah apphost normal, yang diharapkan gagal persis seperti yang Anda sebutkan di atas. Apakah Anda menerbitkan dari direktori yang bersih?

Satu catatan lain tentang file proyek Anda -- Anda memiliki salah satu properti yang salah ditulis sebagai IncludeSymbolsInFile alih-alih IncludeSymbolsInSingleFile . Tapi ini tidak ada hubungannya dengan masalah yang Anda laporkan.

@gaviriar apa pengidentifikasi runtime target Anda. Jika Anda tidak mengaturnya dengan benar, itu tidak akan menggabungkan hostfxr.dll yang benar. Kemungkinan hostfxr.dll memerlukan vc++ khusus yang dapat didistribusikan ulang yang tidak ada pada mesin windows 7 Anda. Anda dapat memeriksa apakah dll di jalur yang diberikan ada dan jika itu mencoba memuatnya di alat bantu walker ketergantungan untuk melihat apakah dll itu tergantung ada.

Menggabungkan IL: Alat seperti ILMerge menggabungkan IL dari banyak rakitan menjadi satu, tetapi kehilangan identitas rakitan dalam prosesnya. Ini bukan tujuan untuk fitur file tunggal.

kehilangan identitas perakitan

ini bukan masalah.
saya selalu menentang penggunaan zip/unzip atau solusi bundel lain untuk fitur mandiri exe tunggal.
karena ini akan menyebabkan masalah berikutnya.
Bagaimana cara mengecilkan ukuran file Single exe!?? atau mengapa file exe sangat besar tetapi hanya hello world!??

Masalah selalu ada, dan perlu diatasi, kenapa tidak dilakukan secara menyeluruh.
Padahal, dari awal sebaiknya menggunakan IL-Merge dengan cara serupa.

Faktanya, orang tidak terlalu terobsesi dengan satu EXE.
exe(1)+dll(1-2) juga OK, tapi tidak 400 mount dll .
ppl tidak suka membawa kode yang tidak pernah dieksekusi ke disk server dan menjalankannya mengambil memori server.
orang Hanya ingin mengurangi biaya penerapan. (Disk, Memori, Bandwidth, dll...)

Saya menghapus pencapaian 3.0, sehingga masalah ini melacak implementasi fitur file tunggal melalui tahapan yang dijelaskan dalam dokumen ini , yang berada di luar cakupan rilis 3.0.

@sgf , saya setuju bahwa ada pekerjaan yang diperlukan untuk mengurangi ukuran file. Peluang pengurangan ukuran ada dua bentuk, mereka tidak secara khusus terkait dengan single-exe:
1) Kurangi jumlah konten yang perlu dipublikasikan. Sebagai contoh:
* Gunakan ILLinker seperti alat untuk memangkas binari yang tidak perlu, bagian dari rakitan, dll.
Pekerjaan ini dilacak secara terpisah oleh masalah seperti dotnet/coreclr#24092 dan mono/linker#607
* Kami dapat mempertimbangkan tindakan lain seperti memiliki mode "kemampuan yang dikurangi" di mana JITting tidak didukung untuk mengurangi
2) Tambahkan fitur kompresi ke penerbitan file tunggal.

Fitur di atas dapat bekerja sama untuk mengurangi ukuran aplikasi file tunggal (dan bukan file tunggal):
Misalnya, untuk aplikasi konsol HelloWorld,
Ukuran publikasi normal = 67,4 MB
Ukuran yang dipangkas = 27 MB
Dipangkas, File tunggal, dikompresi (melalui prototipe) = 12MB

@swaroop-sridhar Apakah ada cara untuk mendapatkan jalur exe file tunggal Anda di dalam aplikasi Anda?
Menggunakan Assembly.GetExecutingAssembly().Location akan menampilkan dir ekstraksi di \AppData\Local\Temp.net.

@chris3713 Cara terbaik untuk mengakses lokasi exe saat ini adalah dengan mengaktifkan PIN ke API asli. Contoh: GetModuleFileNameW (Null, <buffer>, <len>)

@chris3713 Cara terbaik untuk mengakses lokasi exe saat ini adalah dengan mengaktifkan PIN ke API asli. Contoh: GetModuleFileNameW (Null, <buffer>, <len>)

Terima kasih, saya akhirnya menggunakan Process.GetCurrentProcess().MainModule.FileName .

Bekerja dengan baik dengan asp .net core worker/web api karena Layanan Windows diterbitkan dengan PublishSingleFile=true.

Ketika saya mendaftarkan layanan dan menjalankannya melalui sc create testwk binPath="[...]/MyAspNetCoreWorker.exe" lalu sc start testwk Saya mendapat pesan sukses ini:

[...]\bin\publish\x64>sc start testwk

SERVICE_NAME: testwk
        TYPE               : 10  WIN32_OWN_PROCESS
        STATE              : 2  START_PENDING
                                (NOT_STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x7d0
        PID                : 5060
        FLAGS              :

[...]\bin\publish\x64>sc stop testwk

SERVICE_NAME: testwk
        TYPE               : 10  WIN32_OWN_PROCESS
        STATE              : 3  STOP_PENDING
                                (STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

Saya tidak sabar untuk melihat Tahap 2 dengan runing in bundle😀
Omong-omong, apakah Tahap 2 masih direncanakan untuk menjadi bagian dari .Net Core 3.0 ?

Terima kasih atas kerja Anda, layanan penerbitan di .net core sekarang sangat sederhana 👍

CoreRT: ( 2.5mb )

Tidak ada zip hack , tidak ada biaya tersembunyi , mesin hanya berisi apa yang dibutuhkan, dan fitur yang tidak digunakan dinonaktifkan menggunakan konfigurasi csproj (refleksi)

Inilah yang dotnet butuhkan, bersaing dengan GO dan bahkan melampauinya baik dari segi ukuran maupun kinerja

Bagi yang berminat, cek repo:

https://github.com/dotnet/corert

Ada sampel untuk MonoGame:

https://github.com/dotnet/corert/tree/master/samples/MonoGame

Tidak ada solusi yang diusulkan yang dapat mencapai hasil ini, CoreRT benar-benar yang terbaik, MS membuat kesalahan besar dengan tidak fokus padanya

Saya telah menguji fitur ini di macOS dengan dotnet-sdk-3.0.100-preview8-013656-osx-x64.tar.gz . Jika kita mengganti konfigurasi, dari Debug ke Rilis atau sebaliknya dan membangun lagi, itu menambahkan 10MB ke ukuran yang dapat dieksekusi. Kompilasi ulang dengan konfigurasi lama tidak memulihkan peningkatan ukuran ini kecuali jika kita menghapus direktori bin .

mkdir /tmp/dotnet-preview8
curl -s https://download.visualstudio.microsoft.com/download/pr/a974d0a6-d03a-41c1-9dfd-f5884655fd33/cf9d659401cca08c3c55374b3cb8b629/dotnet-sdk-3.0.100-preview8-013656-osx-x64.tar.gz | tar -xvz -C /tmp/dotnet-preview8
export PATH=/tmp/dotnet-preview8:$PATH

dotnet new console -o /tmp/myApp
pushd /tmp/myApp

# publish with Debug
dotnet publish /p:PublishSingleFile=true,RuntimeIdentifier=osx-x64,Configuration=Debug -o bin/a/b/c/d

bin/a/b/c/d/myApp
# outputs: Hello World!

du -sh bin/a/b/c/d
# outputs  70M  bin/a/b/c/d

# publish with Release
dotnet publish /p:PublishSingleFile=true,RuntimeIdentifier=osx-x64,Configuration=Release -o bin/a/b/c/d

du -sh bin/a/b/c/d
# outputs:  80M bin/a/b/c/d

# publish with Debug again
dotnet publish /p:PublishSingleFile=true,RuntimeIdentifier=osx-x64,Configuration=Debug -o bin/a/b/c/d
# still outputs:  80M   bin/a/b/c/d

Bahkan tanpa mengubah konfigurasi build, jika kita memanggil Rebuild target selanjutnya ( /t:Rebuild ) setelah build awal, ukuran output meningkat.

Terima kasih @ am11 untuk melihat. Publikasikan dengan mempertahankan binari lama adalah masalah yang diketahui (cc @nguerrera).

Sejak .Net Core 3 pratinjau 8, saya tidak dapat meluncurkan aplikasi file tunggal saya yang diterbitkan.
Di penampil acara saya memiliki kesalahan ini:

Saya menggunakan Windows Server 2019

Sunting: Kesalahan ini terjadi setelah memperbarui .Net Core SDK Preview 7 ke .Net Core SDK Preview 8. Setelah me-reboot server, saya dapat meluncurkan aplikasi saya dengan benar lagi.

@Safirion kami membuat perubahan pada format internal yang mendasari di sekitar pratinjau ini. Ada kemungkinan bahwa Anda mengangkangi output dari satu pratinjau dan dibuat dengan yang lain. Tidak ada jeda antara Pratinjau 8 dan 9.

Di linux jalur ekstraksi default tampaknya adalah /var/tmp/.net . Di AWS lambda jalur /var tidak dapat ditulis, jadi membuat folder itu gagal. Untuk keluar dari kotak runability tanpa mengatur DOTNET_BUNDLE_EXTRACT_BASE_DIR saya mengusulkan untuk mengubah ini ke /tmp/.net . Atau mungkin harus ada beberapa upaya di lokasi umum (/ var/tmp, /tmp, direktori yang sama dengan biner, dll)

@stevemk14ebr terima kasih telah melaporkan masalah itu. Bisakah Anda mengajukan masalah baru untuk melacak pekerjaan itu? https://github.com/dotnet/core-setup

@jeffschwMSFT https://github.com/dotnet/core-setup/issues/7940

@jeffschwMSFT Kesalahan yang sama terjadi dengan bagian dari .Net Core P9 ke RC1.

Description: A .NET Core application failed.
Application: Setup.exe
Path: C:\Users\Administrateur\Desktop\Setup.exe
Message: Failure processing application bundle.
Failed to determine location for extracting embedded files
A fatal error was encountered. Could not extract contents of the bundle

@Safirion terima kasih telah melaporkan masalah ini. Bisakah Anda membuat masalah terpisah untuk mengulangi ini? https://github.com/dotnet/core-setup
cc @swaroop-sridhar

@Safirion, bisakah Anda mengirim instruksi repro? Apakah kegagalan ini deterministik?
Silakan ajukan masalah di repo pengaturan inti, seperti yang disarankan @jeffschwMSFT di atas.

Saya melihat ini dan ini hanya akan terjadi jika aplikasi berjalan di lingkungan di mana direktori sementara tidak dapat diakses. Misalnya jika saya melakukan ini:

set "TMP=wrong_path"
myapp.exe

Gagal dengan

Failure processing application bundle.
Failed to determine location for extracting embedded files
A fatal error was encountered. Could not extract contents of the bundle

Perhatikan bahwa bundel mencari direktori sementara menggunakan GetTempPath win32 API. Yang menggunakan env. variabel TMP , diikuti oleh TEMP dan seterusnya. Jika yang pertama dengan nilai berisi jalur yang tidak valid, itu akan gagal seperti ini.

Anda dapat memperbaikinya dengan memastikan bahwa jalur temp disetel dengan benar, atau Anda dapat secara eksplisit menyetel DOTNET_BUNDLE_EXTRACT_BASE_DIR ke lokasi yang Anda inginkan untuk melakukan ekstraksi.

@Safirion, bisakah Anda mengirim instruksi repro? Apakah kegagalan ini deterministik?
Silakan ajukan masalah di repo pengaturan inti, seperti yang disarankan @jeffschwMSFT di atas.

Saya tidak dapat mereproduksi masalah ini setelah memperbarui .Net Core ke RC1 dan memulai ulang server saya. (Saya telah mencoba untuk menghapus RC1 dan menginstal Pratinjau 9 lagi untuk meningkatkan lagi ke RC1 tetapi aplikasi saya diluncurkan dengan baik kali ini)

Kesalahan ini terjadi dengan peralihan dari SDK 3.0 P7 ke SDK 3.0 P8 dan SDK 3.0 P9 ke SDK 3.0 RC1.
Dan dalam dua kasus, restart sederhana dari server memperbaiki masalah.

Saya menggunakan .Net Core Windows Service (Pekerja menggunakan folder C:\Windows\Temp\.net untuk mengekstrak sejak diluncurkan oleh sistem) dan aplikasi .Net Core WPF (diluncurkan oleh skrip sesi startup pengguna) ketika saya telah memutakhirkan ke RC1. Mungkin kesalahan ini disebabkan oleh pekerja inti .Net yang berjalan selama pemasangan .Net Core SDK, saya tidak tahu ...

Perhatikan bahwa saya menginstal SDK dan bukan runtime karena saya harus menggunakan runtime 3 .Core (asp.net core, desktop .net core dan core) secara bersamaan dan https://dot.net tidak memberi kami "Full Runtime installer" (Saya bahkan tidak menemukan installer Desktop Runtime jadi, tidak ada pilihan)...

Perbarui: tidak apa-apa, temukan dokumentasi .

Hai, terima kasih atas kerja kerasmu!

Bagaimana file konfigurasi (App.config misalnya) seharusnya didistribusikan? Saya baru saja membuat aplikasi konsol di RHEL 7.6 dengan urutan perintah yang tepat:

dotnet restore -r win-x64 --configfile Nuget.config
dotnet build Solution.sln --no-restore -c Release -r win-x64
dotnet publish --no-build --self-contained -c Release -r win-x64 /p:PublishSingleFile=true -o ./publish ./SomeDir/SomeProj.csproj

di mana SomeProj.csproj mengaktifkan <PublishTrimmed>true</PublishTrimmed> , dan mendapatkan 2 file sebagai hasilnya: SomeProj.exe dan SomeProj.pdb , tetapi tidak SomeProj.config

@catlion memiliki perilaku default untuk file *.config, mereka harus dikeluarkan dari bundel. Secara default semua file non pdb disertakan dalam bundel.
Berikut ini akan mengecualikan konfigurasi dari file tunggal:

<ItemGroup>
    <Content Update="*.config">
      <CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory>
      <ExcludeFromSingleFile>true</ExcludeFromSingleFile>
    </Content>
  </ItemGroup>

https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md#build -system-interface

@morganbr

Jenis aplikasi apa yang kemungkinan besar akan Anda gunakan? (mis. WPF di Windows? ASP.NET dalam wadah Linux Docker? Sesuatu yang lain?)

Aplikasi tanpa kepala dan WPF untuk Windows

Apakah aplikasi Anda menyertakan (non-.NET) C++/kode asli?

Ya, kami P/Memanggil ke berbagai dll asli, beberapa item pihak ketiga yang tidak dapat kami kendalikan, beberapa internal dari tim lain.

Apakah aplikasi Anda akan memuat plugin atau dll eksternal lainnya yang awalnya tidak Anda sertakan dalam pembuatan aplikasi?

Ya, tetapi kami menggunakan CompilerServices untuk mengompilasinya dari sumber.

Apakah Anda bersedia membangun kembali dan mendistribusikan ulang aplikasi Anda untuk memasukkan perbaikan keamanan?

Ya

Apakah Anda akan menggunakannya jika aplikasi Anda mulai 200-500 md lebih lambat? Bagaimana dengan 5 detik?

Ya, aplikasi kami biasanya dibiarkan terbuka untuk waktu yang lama.

Apakah Anda akan menerima waktu pembuatan rilis yang lebih lama untuk mengoptimalkan ukuran dan/atau waktu mulai? Apa yang paling lama Anda terima? 15 detik? 30 detik? 1 menit? 5 menit?

Ya, kita bisa menunggu beberapa menit.

Apakah Anda bersedia melakukan pekerjaan ekstra jika itu akan memotong ukuran aplikasi Anda menjadi dua?

Ya

Terima kasih @john-cullen

Menautkan beberapa PR ke cabang single-exe untuk implementasi prototipe menjalankan aplikasi file tunggal tanpa ekstraksi ( Tahap 4 ).

https://github.com/dotnet/coreclr/pull/26197
https://github.com/dotnet/coreclr/pull/26504
https://github.com/dotnet/coreclr/pull/26697
https://github.com/dotnet/coreclr/pull/26904

Biarkan saya juga memberikan beberapa jawaban untuk @morganbr :) Saya tidak tahu apakah Anda masih membaca ini :)

1. Jenis aplikasi apa yang kemungkinan besar akan Anda gunakan? (mis. WPF di Windows? ASP.NET dalam wadah Linux Docker? Sesuatu yang lain?)

Petualangan teks (Aplikasi konsol) untuk dijalankan di berbagai platform (Linux, MacOS, Windows)

1. Apakah aplikasi Anda menyertakan (non-.NET) C++/kode asli?

Tidak.

1. Apakah aplikasi Anda akan memuat plugin atau dll eksternal lainnya yang awalnya tidak Anda sertakan dalam pembuatan aplikasi?

Tidak saat ini, tetapi akan sangat bagus dalam jangka panjang untuk mendukung skenario tertentu.

1. Apakah Anda bersedia membangun kembali dan mendistribusikan ulang aplikasi Anda untuk memasukkan perbaikan keamanan?

Ya.

1. Apakah Anda akan menggunakannya jika aplikasi Anda mulai 200-500 md lebih lambat? Bagaimana dengan 5 detik?

Ya.
(Akan sangat bagus untuk memberikan beberapa keluaran teks atau kotak pesan untuk memberi tahu pengguna bahwa sesuatu sedang terjadi)

1. Berapa ukuran terbesar yang Anda anggap dapat diterima untuk aplikasi Anda? 5MB? 10? 20? 50? 75? 100?

10-20 MB.

1. Apakah Anda akan menerima waktu pembuatan rilis yang lebih lama untuk mengoptimalkan ukuran dan/atau waktu mulai? Apa yang paling lama Anda terima? 15 detik? 30 detik? 1 menit? 5 menit?

1+ menit tidak apa-apa.

1. Apakah Anda bersedia melakukan pekerjaan ekstra jika itu akan memotong ukuran aplikasi Anda menjadi dua?

Mungkin.

Terima kasih atas tanggapannya, @lenardg.

Masalah ini melacak kemajuan pada fitur distribusi file tunggal .NET Core 3.0.
Inilah dokumen desain dan rencana pementasan untuk fitur tersebut.

Ini adalah fitur yang sangat berguna untuk memudahkan penerapan dan mengurangi ukuran.
Beberapa pemikiran perbaikan pada desain terutama untuk penerapan perusahaan di mana lingkungan dikontrol secara ketat melalui kebijakan grup.

1. Secara kondisional apakah mungkin untuk mengompres saat mengemas executable tunggal?
   yaitu menambahkan Bungkus seperti logika, jadi kita tidak perlu integrasi alat lain.
   Dikompresi akan menghasilkan exe yang lebih kecil lagi.

2. Saat meluncurkan exe, itu memperluas isinya ke folder temp. Untuk produk kami, di situs pengguna tertentu, mesin klien dikontrol dengan ketat dan tidak mengizinkan executable diluncurkan dari folder temp atau bahkan lokasi %userprofile%.

Apakah mungkin untuk menentukan/ mengontrol tempat untuk mengekstrak atau mungkin 'ekstrak di tempat' di ".\extract" atau subfolder semacam itu?
Ini memungkinkan kepatuhan kebijakan grup serta kemampuan untuk menggunakan fitur exe tunggal.

1. Sebelum pengepakan, apakah mungkin untuk menandatangani folder dan kemudian mengambil file untuk dikemas?
   Kami dapat menandatangani exe tunggal, tetapi mengekstrak file tidak ditandatangani, dan karenanya di lokasi klien tertentu lainnya, itu tidak mengizinkan eksekusi, kecuali binari ditandatangani.

@RajeshAKumar https://github.com/dotnet/core-setup/issues/7940

Hanya ingin memberi tahu Anda, saya melihat masalah yang sama dengan @Safirion hari ini. Saya memiliki aplikasi dotnetcore 3.0 yang menargetkan ubuntu, dan menjalankannya di server Synology saya. Itu tidak akan mengekstrak - terus gagal dengan kesalahan "Terjadi kesalahan fatal. Tidak dapat mengekstrak konten bundel". Dibangun kembali beberapa kali, tetapi hal yang sama. Setelah me-reboot Host, itu berfungsi dengan baik lagi.

Akan berguna untuk memahami jika ada kunci file atau sesuatu di sini, dan jika ada waktu tentang cara men-debugnya.

@RajeshAKumar dotnet/core-setup#7940

Saya tidak yakin bagaimana tautan itu membantu.
Itu hanya berbicara tentang ekstraksi temp, saya telah mencantumkan 3 poin di atas.

Dan saya memberi Anda solusi untuk salah satunya. Saya tidak tahu tentang 2 lainnya

Dan saya memberi Anda solusi untuk salah satunya. Saya tidak tahu tentang 2 lainnya

Ekstrak temp tidak bekerja untuk kita, maka itu bukan solusinya. Permintaan saya adalah kemampuan untuk mengontrol di mana ia mengekstrak atau dapat diekstraksi ke dalam subfolder.
Admin TI di banyak komputer klien kami tidak mengizinkan untuk menjalankan yang dapat dieksekusi dari folder sementara atau dari profil pengguna.
Silakan baca kembali posting https://github.com/dotnet/coreclr/issues/20287#issuecomment -542497711

@RajeshAKumar : Anda dapat mengatur DOTNET_BUNDLE_EXTRACT_BASE_DIR untuk mengontrol jalur dasar tempat host mengekstrak konten bundel.
Silakan lihat detail lebih lanjut di sini: https://github.com/dotnet/designs/blob/master/accepted/single-file/extract.md#extraction -location

@RajeshAKumar : Kompresi exe tunggal yang dibundel adalah fitur yang sedang dipertimbangkan untuk .net 5: https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md#compression

Untuk saat ini, Anda harus menggunakan utilitas lain untuk mengompresi file exe tunggal yang dihasilkan.

@RajeshAKumar , mengenai penandatanganan, Anda dapat menandatangani semua file/binari yang diterbitkan dan dibundel ke dalam exe tunggal. Saat host mengekstrak komponen yang disematkan ke disk, file individual akan ditandatangani sendiri. Anda juga dapat menandatangani file tunggal yang dibuat itu sendiri, seperti yang telah Anda sebutkan.

Apakah itu memenuhi persyaratan Anda?

@Webreaper Jika Anda dapat mengulangi masalahnya, dapatkah Anda menjalankan aplikasi dengan mengaktifkan COREHOST_TRACE (mengatur variabel lingkungan COREHOST_TRACE ke 1 ) dan membagikan log yang dihasilkan? Terima kasih.

@swaroop-sridhar
Ini adalah fitur yang sangat keren. Apakah Anda memiliki tautan kapan tahapan yang berbeda akan tersedia di rilis dotnet mana?

@RajeshAKumar : Anda dapat mengatur DOTNET_BUNDLE_EXTRACT_BASE_DIR untuk mengontrol jalur dasar tempat host mengekstrak konten bundel.
Silakan lihat detail lebih lanjut di sini: https://github.com/dotnet/designs/blob/master/accepted/single-file/extract.md#extraction -location

Terima kasih swaroop-sridhar

@RajeshAKumar , mengenai penandatanganan, Anda dapat menandatangani semua file/binari yang diterbitkan dan dibundel ke dalam exe tunggal. Saat host mengekstrak komponen yang disematkan ke disk, file individual akan ditandatangani sendiri. Anda juga dapat menandatangani file tunggal yang dibuat itu sendiri, seperti yang telah Anda sebutkan.

Apakah itu memenuhi persyaratan Anda?

Saya mencoba mencari cara untuk memecahkan 'kompilasi' dan menerbitkan bagian.
Saya menggunakan perintah berikut saat ini, jadi itu tidak memberi saya kemampuan untuk masuk.
Setel publishargs=-c Rilis /p:PublishSingleFile=True /p:PublishTrimmed=True /p:PublishReadyToRun=false
dotnet publish -r win-x64 -o bin\Output\Win64 %publishargs%

Karena kompilasi di atas serta trim dan paket, tidak yakin bagaimana memecahkannya.
Idealnya untuk menggunakan pendekatan Anda, saya harus mengkompilasi, lalu menandatangani lalu akhirnya menerbitkannya.

@Webreaper Jika Anda dapat mengulangi masalahnya, dapatkah Anda menjalankan aplikasi dengan mengaktifkan COREHOST_TRACE (mengatur variabel lingkungan COREHOST_TRACE ke 1 ) dan membagikan log yang dihasilkan? Terima kasih.

Terima kasih. Itu hilang sekarang karena saya mem-boot ulang, tetapi berguna untuk mencatat ini jika itu terjadi lagi!

@RajeshAKumar Anda harus menandai penandatanganan ke target yang berjalan tepat sebelum bundling.
Karena Anda menggunakan PublishReadyToRun dan PublishTrimmed , Anda tidak dapat menggunakan target Afterbuild atau BeforePublish standar.

Anda dapat menambahkan target yang berjalan tepat sebelum BundlePublishDirectory dan melakukan penandatanganan.

@swaroop-sridhar
Ini adalah fitur yang sangat keren. Apakah Anda memiliki tautan kapan tahapan yang berbeda akan tersedia di rilis dotnet mana?

Terima kasih @etherealjoy. Pekerjaan untuk file tunggal yang berjalan langsung dari bundel sedang berlangsung, menargetkan rilis .net 5 menurut pemahaman terbaik saya.

@RajeshAKumar Anda harus menandai penandatanganan ke target yang berjalan tepat sebelum bundling.
Karena Anda menggunakan PublishReadyToRun dan PublishTrimmed , Anda tidak dapat menggunakan target Afterbuild atau BeforePublish standar.

Anda dapat menambahkan target yang berjalan tepat sebelum BundlePublishDirectory dan melakukan penandatanganan.

Terima kasih.
Tautan yang Anda berikan terlihat seperti tugas MS Build.
Bagaimana cara membuat penangan untuk "BundlePublishDirectory"? Apakah ini di Studio/Project props/Build Events atau apakah saya harus membuat sesuatu dari awal.

@RajeshAKumar dalam hal ini, Anda akan membutuhkan sesuatu yang lebih halus daripada acara pra-pembangunan pasca-pembangunan.
Jadi, saya pikir Anda harus mengedit file proyek dan menambahkan sesuatu seperti:

<Target Name="Sign" BeforeTargets="BundlePublishDirectory">
    ... 
</Target>

Apa perilaku yang diharapkan dari perintah dotnet pack dengan ini? Katakanlah kita memiliki artefak exe tunggal yang didorong ke repositori nuget lokal. Jika saya mencoba menginstalnya dengan chocolatey, ia mencoba mengembalikan semua nuget deps yang tercantum dalam file proyek. Yang diharapkan sebelumnya, tapi saya ragu apakah perilaku ini benar untuk SFD.

Apakah mungkin untuk menambahkan beberapa bilah kemajuan atau indikator pemuatan selama ekstraksi aplikasi WPF mandiri file tunggal, itu dapat memakan waktu cukup lama tanpa terjadi apa-apa.
Aplikasi WPF mandiri dasar lebih dari 80Mo dan ekstraksi dapat memakan waktu lebih dari 5 detik. Ini sangat tidak ramah pengguna dan saya menerima keluhan dari pengguna akhir saya.

Sunting: Adakah cara untuk membersihkan versi lama secara otomatis saat diluncurkan?

@Safirion Saya tidak bisa melihat bagaimana hal itu bisa terjadi untuk fitur ini. Jika Anda mengharuskan Anda akan dilayani dengan baik dengan membuat aplikasi kecil Anda sendiri yang menampilkan layar splash dan meluncurkan aplikasi yang sebenarnya, dan kemudian meminta aplikasi yang sebenarnya menghentikan program layar splash saat dimulai.

@ProfessionalNihilist Saya pikir Anda tidak mengerti maksud saya.
Aplikasi WPF yang kosong menggunakan penyimpanan disk 80 bulan saat dikompilasi. Anda tidak dapat memiliki aplikasi WPF yang lebih kecil dari 80 bulan tanpa mengompilasinya sebagai aplikasi yang bergantung pada kerangka kerja
Masalahnya adalah waktu ekstraksi kerangka kerja yang disertakan sebelum aplikasi bahkan dapat diluncurkan. Jadi itu harus dilakukan oleh .Net Core dan itu benar-benar terkait dengan fitur ini.

Mungkin menambahkan kemampuan untuk memiliki png yang akan ditampilkan saat aplikasi didekompresi?

@Safirion @ayende kurangnya "umpan balik UI" selama startup dilacak di sini: https://github.com/dotnet/core-setup/issues/7250

Apa perilaku yang diharapkan dari perintah dotnet pack dengan ini? Katakanlah kita memiliki artefak exe tunggal yang didorong ke repositori nuget lokal. Jika saya mencoba menginstalnya dengan chocolatey, ia mencoba mengembalikan semua nuget deps yang tercantum dalam file proyek. Yang diharapkan sebelumnya, tapi saya ragu apakah perilaku ini benar untuk SFD.

@catlion properti PublishSingleFile hanya didukung oleh perintah dotnet publish . Jadi, itu tidak berdampak pada dotnet pack . Apakah ada motivasi untuk menggunakan file tunggal dan pengemasan?

Sunting: Adakah cara untuk membersihkan versi lama secara otomatis saat diluncurkan?

@Safirion dalam rilis saat ini, pembersihan dilakukan secara manual, host tidak berusaha menghapus file yang diekstrak, karena file tersebut berpotensi digunakan kembali di masa mendatang.

Oke, saya akan membuat pembersih sendiri
Terimakasih atas balasan anda.

@cup tidak ada yang istimewa tentang mono, itu hanya kompilasi standar, sekarang tambahkan referensi nuget dan solusi itu bukan lagi satu file. Mono memiliki mkbundle meskipun untuk mencapai file tunggal

@Suchiman apakah Anda yakin? Contoh saya di atas menghasilkan file 3 KB tunggal. Sementara ukuran minimum dotnet tampaknya 27 MB:

https://github.com/dotnet/coreclr/issues/24397#issuecomment -502217519

@cup ya

C:\Users\Robin> type .\Program.cs
using System;
class Program {
   static void Main() {
      Console.WriteLine("sunday monday");
   }
}
C:\Users\Robin> C:\Windows\Microsoft.NET\Framework\v4.0.30319\csc.exe .\Program.cs
Microsoft (R) Visual C# Compiler version 4.8.3752.0
for C# 5
Copyright (C) Microsoft Corporation. All rights reserved.

This compiler is provided as part of the Microsoft (R) .NET Framework, but only supports language versions up to C# 5, which is no longer the latest version. For compilers that support newer versions of the C# programming language, see http://go.microsoft.com/fwlink/?LinkID=533240

C:\Users\Robin> .\Program.exe
sunday monday
C:\Users\Robin> dir .\Program.exe


    Verzeichnis: C:\Users\Robin


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       10.11.2019     18:36           3584 Program.exe

@Suchiman apakah Anda yakin? Contoh saya di atas menghasilkan file 3 KB tunggal. Sementara ukuran minimum dotnet tampaknya 27 MB:

#24397 (komentar)

File 3k Anda hanya berfungsi karena mono sudah diinstal. Inti dari distribusi file tunggal dotnetcore adalah Anda tidak perlu menginstal clr, ini adalah exe tunggal yang berdiri sendiri termasuk runtime.

@Webreaper sebenarnya saya percaya itu hanya menggunakan mcs dari mono untuk dikompilasi, karena dia tidak menulis mono sun-mon.exe kemungkinan berjalan di .NET Framework.

Tetapi .NET Core juga mendukung skenario runtime yang sudah diinstal sebelumnya, alias penerapan yang bergantung pada kerangka kerja. Ini masih bukan penyebaran file tunggal dalam kasus itu karena ada beberapa file tambahan untuk .NET Core seperti .deps.json dan .runtimeconfig.json

@chris3713 Cara terbaik untuk mengakses lokasi exe saat ini adalah dengan mengaktifkan PIN ke API asli. Contoh: GetModuleFileNameW (Null, <buffer>, <len>)

Tampaknya Environment.CurrentDirectory adalah solusi yang lebih baik, meskipun saya belum mencoba kedua pendekatan pada sesuatu selain Windows.

EDIT: Tidak. Jalur tersebut dapat berubah pada titik masuk yang berbeda dalam aplikasi. Tidak baik.

Pada catatan yang sedikit terkait, saya menemukan regresi ini dalam penerbitan file tunggal aplikasi Blazor di pratinjau terbaru VS untuk Mac: https://github.com/aspnet/AspNetCore/issues/17079 - Saya telah melaporkannya di bawah AspNeCore/Blazor, tetapi mungkin ini lebih relevan untuk grup coreclr - tidak yakin. Akan meninggalkannya untuk kalian untuk bergerak!

@ Suchiman hati-hati, kompiler itu memiliki masalah:

https://github.com/dotnet/roslyn/issues/39856

@cup kecuali bahwa menggunakan jalur file yang saya beri nama, Anda menggunakan kompiler C# 5 lama yang ditulis dalam C++, itu bukan roslyn dan mereka mungkin akan menutup masalah itu karena alasan itu. Tapi roslyn bisa melakukan hal yang sama, hanya jalan yang berbeda...

Pada catatan yang sedikit terkait, saya menemukan regresi ini dalam penerbitan satu file aplikasi Blazor di pratinjau terbaru VS untuk Mac: aspnet/AspNetCore#17079 - Saya telah melaporkannya di bawah AspNeCore/Blazor, tetapi mungkin ini lebih relevan untuk grup coreclr - tidak yakin. Akan meninggalkannya untuk kalian untuk bergerak!

@Webreaper Terima kasih telah melaporkan masalah ini, yang terlihat seperti masalah ASP.net terkait aset statis. Jadi, itu adalah tempat yang tepat untuk mengajukannya.

* Memindahkan pos dari edisi lain ke sini.

@swaroop-sridhar ,

Waktu startup aplikasi DotNet Core Single File WPF jauh lebih lambat daripada aplikasi WPF ILMerge-ed asli yang dibangun di .net 4.7. Apakah ini yang diharapkan atau akankah ini membaik di masa depan?

Build berasal dari ImageOptimizer saya: https://github.com/devedse/DeveImageOptimizerWPF/releases

| Ketik | Perkiraan waktu Startup Pertama | Perkiraan waktu mulai kedua | Ukuran | Tautan unduhan |
| -- | -- | -- | -- | -- |
| .NET 4.7.0 + ILmerge | ~3 detik | ~1 detik | 39.3mb | LINK |
| dotnet publish -r win-x64 -c Rilis --self-contained=false /p:PublishSingleFile=true | ~10 detik | ~3 detik | 49mb | |
| dotnet publish -r win-x64 -c Rilis /p:PublishSingleFile=true | ~19 detik | ~2 detik | 201 mb | |
| dotnet publish -r win-x64 -c Rilis /p:PublishSingleFile=true /p:PublishTrimmed=true | ~15 detik | ~3 detik | 136mb | LINK |
| dotnet publish -r win-x64 -c Rilis | ~2,5 detik | ~1,5 detik | 223kb untuk exe (+400mb dalam dll) | |

@devedse , untuk memastikan, apakah "startup kedua" rata-rata beberapa kali berjalan (selain yang pertama)?
Saya ingin tahu, tetapi tidak ada penjelasan mengapa /p:PublishSingleFile=true /p:PublishTrimmed=true run harus lebih lambat dari ` /p:PublishSingleFile=true run.

Jadi, sebelum menyelidiki, saya ingin memastikan angka di "startup kedua" adalah angka yang stabil dan perbedaan dalam startup dapat direproduksi,

Juga, masalah ini tentang plugin file tunggal, bisakah Anda memindahkan diskusi perf ke masalah baru, atau ke dotnet/coreclr#20287? Terima kasih.

@swaroop-sridhar , sebagai tanggapan atas pertanyaan Anda tentang itu menjadi rata-rata:
Agak sulit bagi saya untuk mengatur waktu ini dengan sangat akurat, jadi pengaturan waktu dilakukan dengan menghitung saat aplikasi dimulai dan kemudian mencobanya beberapa kali untuk melihat apakah ada perbedaan yang signifikan dalam waktu startup. Jika Anda mengetahui metode yang lebih baik, Anda dapat dengan mudah mereproduksinya dengan membangun solusi saya: https://github.com/devedse/DeveImageOptimizerWPF

Pertanyaan utama saya berkaitan dengan mengapa diperlukan waktu lebih lama untuk memulai aplikasi yang dibundel (file tunggal) dibandingkan dengan file .exe yang tidak dibundel.

Saya mungkin salah di sini tetapi masuk akal bagi saya karena ada overhead dengan satu file. Pada dasarnya Anda memiliki aplikasi yang memulai aplikasi lain. Sementara ILMerge dimulai secara langsung. ILMerge hanya menggabungkan dll yang direferensikan ke dalam exe itu tidak membungkus semuanya di lapisan lain yang saat ini sedang dilakukan dengan PublishSingleFile.

@devedse File tunggal pada dasarnya mengekstrak, memeriksa checksum, dll. sebelum memulai dotnet run.
Kira itu sebabnya butuh waktu itu.
Ekstrak "di-cache" jadi jalankan selanjutnya, tidak ada overhead IO.

@RajeshAKumar , hmm mengekstrak benar-benar cara yang harus dilakukan dalam skenario ini? Bukankah lebih baik menggunakan cara ILMerge dan benar-benar menggabungkan DLL menjadi satu bundel tunggal?

Khusus untuk file .exe yang lebih besar, Anda juga mendorong biaya ruang disk untuk menyimpan semua file dua kali lipat.

@devedse Kami semua menunggu tahap selanjutnya dari fitur ini (Jalankan dari Bundel) tetapi untuk saat ini, itu satu-satunya solusi. 😉.

https://github.com/dotnet/designs/blob/master/accepted/single-file/staging.md

inilah yang Anda dapatkan dengan menggunakan JIT di desktop, startup lambat, sepertinya hanya Apple yang mengerti ini

(Sebagian besar mengulangi apa yang sudah dinyatakan):
Awal pertama diharapkan menjadi jauh lebih lambat - itu mengekstrak aplikasi ke disk - begitu banyak IO. Permulaan kedua dan selanjutnya harus hampir identik dengan versi aplikasi non-file tunggal. Dalam pengukuran internal kami, kami tidak melihat perbedaan.

Cara mengukur: Kami menggunakan tracing (ETW di Windows) - ada peristiwa ketika proses dimulai dan kemudian ada peristiwa runtime yang dapat digunakan untuk ini - itu tidak sepenuhnya mudah.

Seperti yang disebutkan oleh @Safirion , kami sedang mengerjakan peningkatan berikutnya untuk file tunggal yang harus menjalankan sebagian besar kode yang dikelola dari .exe secara langsung (tanpa ekstrak ke disk). Belum bisa menjanjikan kereta rilis.

JIT: Semua kerangka kerja harus dikompilasi sebelumnya dengan Ready2Run (CoreFX, WPF), jadi saat startup hanya kode aplikasi yang harus di-JIT. Ini tidak sempurna, tetapi harus membuat perbedaan besar. Mengingat waktu startup ~ 1-2 detik, saya pikir itu sudah menggunakannya di semua tes.

Terima kasih semua, saya tidak mengetahui langkah selanjutnya yang direncanakan. Ini menjelaskannya.

Awal pertama diharapkan menjadi jauh lebih lambat - itu mengekstrak aplikasi ke disk - begitu banyak IO.

Ini seharusnya tidak pernah terjadi, Anda membuat pengalaman pengguna mengerikan DENGAN DESAIN, pilihan yang mengerikan, begitulah cara Anda membuat pengguna membenci teknologi yang digunakan pengembang untuk mereka

Seperti yang disebutkan oleh @Safirion , kami sedang mengerjakan peningkatan berikutnya untuk file tunggal yang harus menjalankan sebagian besar kode yang dikelola dari .exe secara langsung (tanpa ekstrak ke disk). Belum bisa menjanjikan kereta rilis.

Mengapa merilis ini secara resmi sekarang jika itu akan segera berubah? harus ditandai sebagai pratinjau/eksperimental

menurut saya ini buang-buang waktu dan sumber daya, fokus pada kompilasi AOT dan pengguncangan pohon, letakkan semua sumber daya Anda di sana, hentikan peretasan

@RUSshy Mengapa begitu banyak kebencian? Jika Anda tidak ingin penundaan startup saat pertama kali diluncurkan, maka jangan gunakan penyebaran file tunggal.

Saya menemukan startup secara signifikan kurang dari 10-an, dan karena ini baru pertama kali Anda jalankan, itu tidak masalah sama sekali. Saya menggunakan aplikasi web sisi server yang berarti dalam banyak kasus itu akan dimulai sekali dan kemudian berjalan selama berhari-hari/minggu, jadi ekstraksi awal dapat diabaikan dalam skema banyak hal - jadi saya lebih suka ini sebagai stop-gap sampai ada gambar yang dikompilasi tunggal, karena itu hanya membuat penyebaran jauh lebih mudah daripada menyalin ratusan DLL di sekitar tempat itu.

+1 dalam kasus saya, kami memiliki build docker yang menghasilkan exe tunggal, dan docker terpisah untuk menjalankan aplikasi (menggunakan gambar docker Alpine biasa tanpa dotnet). Setelah langkah build, kita hot-load container runtime sekali dan docker-commit layer. Selanjutnya, kami belum mengamati regresi kinerja apa pun dibandingkan dengan penerapan yang bergantung pada kerangka kerja. Setelah mekanisme file load-from-bundle diimplementasikan dan dikirimkan, kami akan menghapus langkah hot-loading perantara.

@vitek-karas, apakah ada masalah pelacakan fitur "muat aset runtime dari bundel"? tertarik untuk memahami hambatan seperti apa yang ada. :)

@am11 Saat ini kami sedang menyusun rencana detailnya. Anda dapat melihat prototipe yang telah dilakukan di https://github.com/dotnet/coreclr/tree/single-exe. Implementasi sebenarnya mungkin tidak akan terlalu berbeda (anjak yang jelas lebih baik dan sebagainya, tetapi ide intinya tampaknya masuk akal).

@Webreaper Untuk aplikasi web, itu bukan masalah sama sekali tapi mungkin karena .Net Core 3 direkomendasikan untuk pengembangan WPF/WinForm sekarang, dan berbagi aplikasi Desktop .exe hilang dalam ratusan .dll bukanlah pilihan maka saya benar-benar memahami frustrasi terkait dengan tahap pertama fitur ini.
;)

Dan tidak ada pengguna yang menunggu 10 detik (atau lebih dari 3 detik) sebelum mengklik ulang exe hari ini. Fakta bahwa tidak ada indikator pemuatan adalah masalah besar kedua dari fitur ini. Sayangnya, sepertinya indikator pemuatan tidak akan menjadi bagian dari .Net Core 3.1 sehingga pengguna harus bersabar...

Pengembang desktop benar-benar menunggu tahap 2, dan saya berharap itu akan menjadi bagian dari .Net 5 karena sebenarnya, pengembangan Desktop di .Net Core adalah pengalaman yang sangat buruk bagi pengguna akhir.

@RUSshy Mengapa begitu banyak kebencian? Jika Anda tidak ingin penundaan startup saat pertama kali diluncurkan, maka jangan gunakan penyebaran file tunggal.

ini bukan kebencian, ini umpan balik yang konstruktif dan jujur, saya peduli dengan C# dan .net, saya menggunakan keduanya setiap hari, saya tidak ingin itu digantikan oleh GO atau yang lainnya

baru-baru ini:
https://old.reddit.com/r/golang/comments/e1xri3/choosing_go_at_american_express/
https://old.reddit.com/r/golang/comments/ds2z51/the_stripe_cli_is_now_available_and_its_written/

umpan balik negatif sama bermanfaatnya dengan umpan balik positif, tetapi jika Anda menganggapnya sebagai "kebencian" maka saya tidak dapat membantu Anda

komunitas .net adalah cara untuk diam, pasif dan bias, gangguan adalah satu-satunya cara untuk pergi

.NET secara objektif adalah platform terbaik untuk sebagian besar aplikasi saat ini. Saya berharap lebih banyak orang menyadari itu.

Cerita perang yang saya dengar dari platform lain seperti Java, Go, Rust, Node, ... terus terang mengganggu. Platform ini adalah pembunuh produktivitas.

menurut saya ini buang-buang waktu dan sumber daya, fokus pada kompilasi AOT dan pengguncangan pohon, letakkan semua sumber daya Anda di sana, hentikan peretasan

Saya setuju. .Net memiliki sistem tipe yang bagus. Terlalu sering itu dielakkan menggunakan refleksi. Perkakas perlu fokus pada AOT tetapi juga meminimalkan refleksi. https://github.com/dotnet/corert/issues/7835#issuecomment -545087715 akan menjadi awal yang sangat baik. Kesalahan miliaran dolar dari nol sedang dikurangi sekarang; hal yang sama harus dilakukan dengan refleksi dengan pengaturan atau penanda untuk kode bebas refleksi (atau kode yang kompatibel dengan linker atau corert).

Menghilangkan refleksi akan luar biasa. Begitu banyak penderitaan yang dapat dihindari jika refleksi dilarang. Kisah horor terbaru saya adalah menemukan bahwa saya tidak dapat memindahkan kode karena kerangka kerja yang digunakan (service fabric SDK) merasa bijaksana untuk mengikat byte bersambung ke nama perakitan implementasi serializer tanpa kemungkinan menimpa.

Setiap kemajuan menuju refleksi yang mengecilkan hati akan menjadi kemajuan.

Btw sedang mencari cara untuk menggabungkan rakitan untuk mengurangi ukuran bundel dan waktu muat, memungkinkan pengoptimalan seluruh program. Saya menyimpulkan masalah ini tidak benar-benar ditargetkan pada itu.

Sunting: Karena posting ini mengumpulkan beberapa reaksi hanya untuk memperjelas. Saya percaya pemrograman meta harus terjadi pada waktu desain, di mana kodenya adalah data, dan itu di bawah kendali saya.

Jenis yang saya suka gunakan untuk menerapkan invarian yang dapat saya percayai. Refleksi runtime merusak kepercayaan itu.

Karenanya saya ingin refleksi runtime diganti dengan pemrograman meta waktu desain. Di mana itu juga bisa menjadi tumpang tindih yang lebih kuat dengan kasus penggunaan seperti penganalisis, perbaikan cepat, dan pemfaktoran ulang.

Menandai pelanggan ke area ini: @swaroop-sridhar
Beri tahu danmosemsft jika Anda ingin berlangganan.

Desain fitur file tunggal ada dalam dokumen ini: https://github.com/dotnet/designs/blob/master/accepted/2020/single-file/design.md
Melacak kemajuan aplikasi file tunggal dalam masalah ini: https://github.com/dotnet/runtime/issues/36590.
Terima kasih kepada semua orang atas umpan balik dan saran Anda dalam masalah ini.