Runtime: Aplikasi konsol mandiri exe tunggal

Dibuat pada 3 Nov 2016  ·  98Komentar  ·  Sumber: dotnet/runtime

Menerbitkan aplikasi konsol mandiri dalam .net core, seperti yang dijelaskan di sini, menghasilkan direktori dengan banyak file, bahkan yang memiliki "footprint lebih kecil".

Apakah mungkin untuk menggabungkan semua dependensi sehingga kami mendapatkan satu executable? Satu besar-ish myapp.exe saat menargetkan Windows, misalnya.

Saya kira saya sedang mencari sesuatu yang mirip dengan ILMerge, tetapi untuk inti bersih. Apakah mungkin dengan beberapa flag opsi pada dotnet publish atau perintah lain? Jika tidak, harap pertimbangkan sebagai permintaan fitur. Terima kasih.

area-Meta question

Komentar yang paling membantu

Ini benar-benar mengerikan. Saya bertanya-tanya mengapa ini disetujui selama proses desain, ingin mendistribusikan aplikasi Anda ke salah satu klien Anda, lalu semoga dia menemukan apa yang harus dibuka:
image

Ini benar-benar jelek dan berantakan

runtime /
MyProgram.exe
MyLib.dll

Ini akan menjadi ide yang jauh lebih baik

Bahkan Java menanganinya dengan lebih baik:
explorer_2018-04-21_16-42-33

Semua 98 komentar

Skenario ini tidak didukung sekarang. Awasi https://github.com/dotnet/corert repo untuk pekerjaan yang akan mengarah ke jalur ini.

CoreRT adalah tempat yang tepat untuk mencari solusi ini.

Terima kasih. Sepertinya CoreRT persis seperti yang saya cari.

Untuk orang lain yang mungkin tersandung pada ini, baca di sini

Saya secara khusus menginginkan fitur ini tanpa kompilasi sebelumnya. Saya tidak ingin corert– Saya ingin pengalaman jit dan debugging serta runtime yang sama seperti aplikasi mandiri normal– tetapi saya juga tidak ingin mendistribusikan empat file per utilitas. Itu tidak nyaman bagi siapa pun yang ingin menggunakan utilitas tersebut. Saya hanya ingin itu dikemas dan dijalankan dari satu exe. Ini menyebabkan saya memilih .NET Framework daripada .NET Core untuk banyak utilitas.

.NET Framework "curang" karena Anda memiliki banyak file yang sudah ada di OS.
Anda dapat mencapai hal yang sama dengan .NET Core, dengan menginstal .NET Core bersama di seluruh mesin jika itu yang Anda inginkan.

Refactoring CoreCLR untuk menggabungkan semua file menjadi satu (termasuk native + managed) adalah pekerjaan yang tidak sepele dan menurut saya skenario ini tidak terlalu menarik bagi banyak pelanggan.

Perbedaannya adalah bahwa setiap mesin Windows dijamin memiliki .NET Framework tetapi tidak .NET Core, jadi kecuali ada alasan khusus yang membuat penerapan lebih kompleks, saya kira saya akan tetap di sana.
Saya kira pelanggan biasanya tidak menulis utilitas exe tunggal. Mungkin suatu hari. :-)

kecuali ada alasan khusus yang membuat penerapan menjadi lebih kompleks

Ada BANYAK alasan untuk lebih memilih .NET Core daripada .NET Framework. Performa, modularitas, kemudahan servis, isolasi, dll. Dan itu mengabaikan kemampuan lintas platform.

Memiliki utilitas exe tunggal sebagian besar merupakan masalah kosmetik. Tidak ada perbedaan fungsional yang nyata (untuk siapa pun yang terlibat) jika yang dapat dieksekusi adalah satu file atau satu folder dengan beberapa file di dalamnya.

@mellinoe Oh saya setuju untuk proyek secara umum, itu memang benar. Dalam utilitas kecil di mana kosmetik ini diinginkan, .NET Framework sejauh ini telah melakukan pekerjaan yang cukup baik. Saya setuju itu kosmetik dalam arti yang sama seperti dapat menentukan perusahaan perakitan dan pesan hak cipta. Tapi menjadi kosmetik tidak membuatku kurang menyukainya. Jelas bukan prioritas di sini, itu cukup bisa dimengerti.

Ini bukan hanya kosmetik. Bayangkan saya ingin mendistribusikan aplikasi yang memiliki beberapa komponen yang tertanam di dalamnya, seperti misalnya Idsrv4 atau RavenDb + barang saya sendiri. Mereka mengambil ketergantungan pada bit inti aspnet. Ini semua berfungsi dengan baik selama mereka bergantung pada versi inti aspnet yang sama. Segera setelah salah satu dari mereka beralih ke versi berikutnya, itu mungkin tidak akan berfungsi lagi. Jika OTOH saya dapat mengilmerge setiap komponen menjadi satu .dll masalah akan hilang.

Satu hal yang perlu diingat adalah bahwa ada lebih banyak masalah teknis daripada hanya ILMerge yang tidak berfungsi. Runtime itu sendiri pada dasarnya dibagi menjadi banyak file, dan ada juga file tambahan seperti host CLR, file teks dependensi runtime, dan banyak lagi. Satu-satunya alasan file tunggal yang dapat dieksekusi bekerja di masa lalu adalah karena .NET Framework, penginstalan seluruh sistem global, diandalkan. Membandingkan kedua skenario agak tidak adil, karena .NET Framework tidak benar-benar memiliki opsi "mandiri".

Ini semua berfungsi dengan baik selama mereka bergantung pada versi inti aspnet yang sama. Segera setelah salah satu dari mereka beralih ke versi berikutnya, itu mungkin tidak akan berfungsi lagi.

Ini tidak benar. Anda dapat memublikasikan beberapa aplikasi berbeda pada versi waktu proses yang berbeda, lalu menggabungkannya ke dalam "aplikasi uber" yang sama. Anda tidak bisa mencampur dependensinya ke dalam satu folder. Meskipun Anda menggunakan opsi publikasi yang bergantung pada kerangka kerja, Anda masih dapat mencampur dan mencocokkan versi. Saya mengerti bahwa ini kurang nyaman daripada memiliki satu file secara harfiah, dan mungkin mencegah hal-hal seperti menyematkan exe sebagai sumber daya di PE. Saya tidak yakin apakah itu yang Anda maksud, karena Anda mungkin masih perlu mengekstrak file untuk menjalankannya, yang masih dapat Anda lakukan dengan direktori.

Saya tidak bermaksud versi runtime, saya tahu itu tidak akan berhasil. Yang saya maksud adalah, apa yang terjadi dalam skenario saya ketika setiap komponen bergantung pada [email protected]. Komponen a kemudian diperbarui ke [email protected]. Biasanya tidak apa-apa, tetapi dalam hipotesis ini penulis LibXYZ tidak tahu / tidak peduli tentang pembuatan versi semantik. Ilmerge membuat masalah ini hilang.

Selain poin terkait @thefringeninja , saya menyarankan bahwa satu unit biner yang dapat

Saya menghargai dotnet tooling yang baru lahir dan baru saja mencapai 2.0, tetapi dibandingkan dengan alternatif seperti golang fitur ini sangat hilang. Mohon pertimbangkan untuk menambahkannya ke peta jalan?

Sebagai pengembang lib, saya akan menghargai memiliki ILMerge kembali di Core. 👍

Dotnet.exe adalah satu file. NuGet.exe adalah satu file. Menurut saya kosmetik itu penting, dan satu file exe meneriakkan kesederhanaan dengan cara yang tidak dimiliki folder dengan 100 file! Akan sangat bagus untuk menemukan cara untuk mencapai ini dengan dotnetcore

Saya berasumsi ini mungkin, dan setelah beberapa minggu bekerja, datang untuk mempublikasikan alat konsol CLI ke satu .exe ... ummm tampaknya saat ini saya tidak bisa hanya mendapatkan satu * .exe ??
Saya pikir itulah inti dari aplikasi inti mandiri?

@PRIM

Saya pikir itulah inti dari aplikasi inti mandiri?

Inti dari aplikasi mandiri adalah bahwa aplikasi tersebut berdiri sendiri, yaitu, mereka tidak memerlukan .Net Core untuk diinstal pada mesin target, karena aplikasi itu sendiri berisi semua yang dibutuhkan untuk dijalankan.

Untuk menerapkan aplikasi semacam itu, Anda harus menyalin seluruh direktori file. Hanya memiliki satu file akan membuat penerapan lebih mudah, tetapi hanya itu, itu masih aplikasi mandiri bahkan tanpa itu.

Untuk aplikasi besar dan mirip layanan, ini mungkin tidak terlalu penting, tetapi sangat penting agar alat baris perintah dan aplikasi kecil menjadi sesederhana mungkin dan ramah penerapan COPY.

Saya secara teratur menulis alat baris perintah di .NET dan menjadikannya sebagai 1 EXE membuat peningkatan / penerapan / pengemasan JAUH lebih sederhana. Saya selalu mengemas semua .config dan file lain yang diperlukan di dalam EXE.

Pikirkan single-EXE itu sebagai wadah mini. Hampir semua manfaat penerapan berbasis kontainer berlaku di sini.

Ini benar-benar mengerikan. Saya bertanya-tanya mengapa ini disetujui selama proses desain, ingin mendistribusikan aplikasi Anda ke salah satu klien Anda, lalu semoga dia menemukan apa yang harus dibuka:
image

Ini benar-benar jelek dan berantakan

runtime /
MyProgram.exe
MyLib.dll

Ini akan menjadi ide yang jauh lebih baik

Bahkan Java menanganinya dengan lebih baik:
explorer_2018-04-21_16-42-33

Ya, saya memikirkan hal yang sama, karena aplikasi mandiri perlu memiliki file runtime yang disertakan dengannya (jelas!) (Dan kami tidak memiliki cara untuk menggabungkannya), maka saya juga berpikir hanya pemisahan folder yang akan lebih rapi, dan ya saya juga berpikir file runtime harus disimpan di folder runtime, jadi siapa pun yang mencoba menggunakan Alat Baris Perintah yang ditulis dalam inti, setidaknya akan merasa sedikit lebih intuitif seperti apa yang harus dijalankan ..

@Scellow @PRIMETSS Saya harus setuju

Bagaimana ini bahkan masih menjadi masalah? Permintaan melalui atap untuk ini.

ya untuk folder terpisah ini dengan tambahan zip yang menjadi bin dan memiliki dua file, exe dan bin. Distribusi mudah.

+1 lain untuk dibuka kembali dan dijadikan sebagai fitur.

Saya mengharapkan penerapan mandiri itu mandiri dan menemukan jalan saya di sini. Saya juga ingin melihat ini terjadi.

Bagaimana orang bisa mengatakan ini hanya masalah kosmetik? (Hanya pengembang Kerangka ...)
Tidak ada yang memikirkan alat yang tidak terpasang? (.NET memecahkan dll-hell, dan .net core mengembalikannya)

Saya hanya ingin alat Baris Perintah saya berdiri sendiri.

Ini buruk, sangat buruk!

+1

+1 Saya baru saja mencoba menjalankan aktivitas kustom di Azure Batch di kluster tanpa runtime inti .net dan tidak dapat menangani sejumlah besar file yang dibuat oleh versi "mandiri".

Total size of resourceFiles cannot be more than 32768 characters

Ini bukan solusi resmi, tetapi mungkin berguna. Saya penulis warp, alat yang memungkinkan Anda membuat aplikasi biner tunggal mandiri: https://github.com/dgiagio/warp

Saya pikir warp pada dasarnya adalah apa yang dicari semua orang di sini! Ini hanya tentang kemampuan untuk memiliki satu file exe, apa pun yang ada di latar belakang, tidak lebih. Pikirkan tentang paket NuGet: ini adalah satu file .nuget dan hanya itu; itu bukan sesuatu yang lebih kompleks daripada file yang mengemas file lain.

warp adalah solusi hacky, ini bukan yang kami inginkan

Yang kami inginkan adalah:

dotnet publish --self-contained -c Release -r win10-x64

Dan itu menghasilkan:

App.exe
runtime/

Atau lebih baik seperti GO / Rust dll

App.exe

Segala sesuatu yang lain tidak diinginkan

Warp menghasilkan App.exe ... Bagaimana hacky? Jelas itu bukan bagian dari kerangka kerja, tetapi mencapai tujuan "satu file exe".

Ini yang saya maksud, itu harus perilaku default, tidak menggunakan solusi pihak ke-3 (menurut saya)

Warp bekerja dengan baik. Terima kasih atas pekerjaan Anda @dgiagio!

+1

Saya sangat ingin melihat semacam arsip file tunggal yang menggabungkan executable dan semua dependensi. Tidak harus menyertakan yang asli - saya pikir tidak apa-apa jika inti dotnet harus diinstal pada sistem. Sesuatu yang sangat mirip dengan file jar Java. File dar?

Sesuatu seperti:
dotnet mempublikasikan - mandiri
dotnet run - MyApp.dar mandiri

Saya membaca proposal dan saya melihat ini:

image

Bukan itu yang saya pikirkan, ini terdengar seperti proses yang lambat, pada dasarnya hanya membuat zip semuanya ..
Saya pikir semua kode akan digabungkan menjadi satu executable / dll? atau mungkin saya melewatkan sesuatu dalam proposal?

@RUSshy Apakah Anda bertanya tentang native-compiling semua kode yang dikelola dan menghubungkan semuanya bersama-sama untuk mendapatkan satu executable (seperti dalam CoreRT)? Ini bukan tujuan untuk pekerjaan file tunggal saat ini di .Net Core.

Namun, ada solusi yang diusulkan untuk mengurangi ekstraksi disk dan waktu startup (mis .: memuat jenis file tertentu langsung dari bundel , menggunakan kembali file yang diekstrak ). Tahapan pengembangan solusi file tunggal dijelaskan di sini .

CC: @jeffschwMSFT

Mengapa file perlu diekstrak? Kami biasa lolos dengan ini di .NET dengan ILMerge.

@ phillip-haydon, seperti yang dijelaskan di sini , ILMerge dan solusi file tunggal mencapai tujuan yang berbeda.

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 assembly asli akan gagal. Aplikasi masih dapat menggunakan ILMerge jika mereka dapat mentolerir perubahan ini.

CoreRT adalah sesuatu yang lain, kompilasi AOT dari kode .NET Anda, memang terlihat menarik, tetapi belum siap (saya berharap MS akan fokus padanya, dan mengalokasikan lebih banyak sumber daya .. inilah yang diinginkan orang, dan mengapa mereka pindah ke GO )

Bagaimanapun, saya tidak memiliki pengetahuan teknis untuk membicarakan detailnya, tetapi kasus penggunaannya adalah:

Publikasikan satu yang dapat dieksekusi mandiri, dan hanya itu, tidak ada yang di-zip, tidak ada yang diekstraksi, tidak ada overhead, hanya yang dapat dieksekusi

@ swaroop-sridhar apakah Anda memiliki contoh ini berfungsi untuk inti dotnet di linux? menurut https://github.com/dotnet/ILMerge/blob/master/ILMerge/ILMerge.csproj#L13 ini adalah proyek khusus windows / mono.

@thefringeninja ILMerge adalah alat windows, saya tidak tahu ada rencana untuk mem-port ILMerge ke platform lain.
Solusi file tunggal akan diimplementasikan lintas platform. Ini sedang dalam proses pengembangan.

@karelz @mellinoe
Deploy Deploy!jika Single atau kurang seperti 1-3 file itu akan lebih baik untuk Deploy (Inlcude Publish, Update)!

CoreRT adalah AOT
tapi ppl mau AOT?
proyek (CoreRT) selalu tidak mudah digunakan (dari 2014). Sekarang adalah 2019! ( Kira-kira butuh 5 tahun )
Betapa berharga 5 tahun untuk bahasa pragram!CoreRT bahkan tidak ada rencana untuk rilis berikutnya !!!biarkan ppl menunggu 5 tahun lagi?

@ Swaroop-sridhar Itu sangat disayangkan. ILMerge / ILRepack sangat bagus untuk pengembang perpustakaan untuk menghindari masalah ketergantungan berlian.

Ada rencana untuk mendukungnya di .NET Core 3.0 - @richlander dapat memperbarui status Anda.
Ini telah disebutkan dalam entri blog .NET Core 3.0 - misalnya di sini: https://devblogs.microsoft.com/dotnet/net-core-3-and-support-for-windows-desktop-applications/ di "Berdampingan- side and App-local Deployment ".
Baca juga: https://www.hanselman.com/blog/BrainstormingCreatingASmallSingleSelfcontainedExecutableOutOfANETCoreApplication.aspx

.net seharusnya tidak memerlukan semua peretasan ini untuk menghasilkan eksekusi mandiri tunggal kecil .. itu harus menjadi perilaku default, Anda dimakan hidup-hidup oleh GO, Rust juga datang, fokus pada CoreRT atau ILMerge, aplikasi inti .net sudah juga lama untuk memulai karena semua file akan dimuat, jangan menambahkan lebih banyak yang tidak sengaja dengan zip / unzip seperti yang disebutkan dalam proposal, ini bukan cara yang tepat

.net seharusnya tidak memerlukan semua peretasan ini untuk menghasilkan eksekusi mandiri tunggal kecil .. itu harus menjadi perilaku default, Anda dimakan hidup-hidup oleh GO, Rust juga datang, fokus pada CoreRT atau ILMerge, aplikasi inti .net sudah juga lama untuk memulai karena semua file akan dimuat, jangan menambahkan lebih banyak yang tidak sengaja dengan zip / unzip seperti yang disebutkan dalam proposal, ini bukan cara yang tepat

Sesuka Anda .net seharusnya tidak perlu hidup, karena ppl memiliki java.
go atau rust atau dlang seharusnya tidak mendukung target build ke program yang dapat dieksekusi Tunggal, karena mereka memiliki Fuck Zip / Unzip!

@RUSY

.net seharusnya tidak memerlukan semua peretasan ini untuk menghasilkan executable tunggal kecil yang mandiri

Sepakat. Pada saat yang sama, .NET menyediakan fitur-fitur tertentu di atas bahasa lain yang menantang untuk disesuaikan dengan persyaratan linker statis (misalnya, pembuatan kode on the fly, refleksi, pengikatan data, dll). Kami telah bereksperimen dengan mengecualikan fitur ini dalam skenario di mana file tunggal / tautan statis penting. Kami telah belajar dari umpan balik pelanggan bahwa hasilnya tidak lagi terasa seperti .NET, sebagian karena jumlah pustaka yang dapat Anda konsumsi dari ekosistem turun drastis.

Jadi melakukan penaut dengan benar yang tidak berkompromi dengan fitur yang kita semua gunakan sebagai ketergantungan dan cintai di .NET, adalah masalah yang sulit. Sebagai bagian dari pemecahan ini, kami bereksperimen dengan berbagai pendekatan. Anda menyebutnya peretasan, saya menyebutnya berpikiran terbuka dan bersedia berpikir di luar kotak. Tapi hanya dengan membabi buta mengubah .NET menjadi Go / Rust / C ++ bukanlah jawaban yang tepat.

Kami telah bereksperimen dengan mengecualikan fitur ini dalam skenario di mana file tunggal / tautan statis penting. Kami telah belajar dari umpan balik pelanggan bahwa hasilnya tidak lagi terasa seperti .NET, sebagian karena jumlah pustaka yang dapat Anda konsumsi dari ekosistem turun drastis.

Sudahkah tim berpikir untuk membuat versi .net terpisah yang difokuskan untuk pengembangan native dan lingkungan terbatas, seperti yang dilakukan jetbrains dengan kotlin JVM / kotlin NATIVE?

Seperti yang Anda katakan, mencoba membuat .net sesuai dengan setiap kasus penggunaan bukanlah pilihan paling cerdas sehingga rasa tertentu mungkin menjadi jawaban yang tepat untuk masalah ini

Dan tbh, afaik, masalah ini tidak benar-benar ada sebelumnya .net core karena setiap instalasi windows sudah memiliki framework .net, jadi Anda hanya perlu mendistribusikan beberapa KB exe Anda, dan yang mengganggu saya adalah sepertinya tidak ada yang memikirkan hal ini masalah saat mendesain inti bersih yang pada dasarnya merupakan penulisan ulang kerangka kerja .net .. inilah mengapa saya mengatakan opsi ini disebutkan adalah peretasan biasa, mereka di sini untuk memperbaiki kesalahan desain

Setelah membaca https://github.com/dotnet/designs/blob/master/accepted/single-file/staging.md tampaknya ada lebih banyak langkah untuk proposal tersebut, dan tidak berakhir pada zip / unzip jadi bukan itu kalah bertarung, semoga tim bisa datang dengan sesuatu yang lebih ringan, yang disebutkan dalam dokumen itu, bagus!

Hal-hal seperti inilah mengapa Windows tetap menjadi OS mainan.

@kjkrum Hal-hal seperti apa?

@cryru itu yang orang katakan ketika mereka tidak tahu apa yang mereka lakukan.

@Cryru Hal-hal seperti tidak dapat membangun executable mandiri, dan pemecatan menyadari kebutuhan yang sangat nyata untuk melakukannya. Hampir semua sistem build lain yang ada tidak hanya akan membangun executable yang terhubung secara statis, tetapi juga akan menghapus bagian dependensi yang tidak digunakan. Dependensi pengupasan telah menjadi fitur standar setidaknya selama satu dekade; menghubungkan statis sejak penemuan pelengkap.

@Cryru Hal-hal seperti tidak dapat membangun executable mandiri, dan pemecatan menyadari kebutuhan yang sangat nyata untuk melakukannya. Hampir semua sistem build lain yang ada tidak hanya akan membangun executable yang terhubung secara statis, tetapi juga akan menghapus bagian dependensi yang tidak digunakan. Dependensi pengupasan telah menjadi fitur standar setidaknya selama satu dekade; menghubungkan statis sejak penemuan pelengkap.

Setuju, ini sebenarnya terkait dengan posisi program C # di sistem operasi.
Program C # selalu tidak bisa menjadi warga negara kelas satu.Hanya untuk menjadi kelas dua.

Ini terselesaikan.
TLDR: dotnet publish -r win10-x64 /p:PublishSingleFile=true

Rincian:
https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0#single -file-executables
https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md

Ini terselesaikan.
TLDR: dotnet publish -r win10-x64 /p:PublishSingleFile=true

Rincian:
https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0#single -file-executables
https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md

Dalam versi dotnet-core manakah fitur ini ditambahkan? Saya menggunakan 3.0.100-preview5-011568 dan mendapatkan kesalahan ini:
error MSB4030: "/p:PublishSingleFile=true" is an invalid value for the "SelfContained" parameter of the "ResolveFrameworkReferences" task. The "SelfContained" parameter is of type "System.Boolean".

LE: Sebenarnya ini berfungsi, sepertinya hanya ada kesalahan sintaks di https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md yang menyatakan penerbitan dengan dotnet publish -r win10-x64 --self-contained /p:PublishSingleFile=true dan sebenarnya tanpa menambahkan --self-contained .

Terima kasih @mihaimyh Saya akan memperbaiki kesalahan ketik di dokumen desain.

im selalu menentang penggunaan solusi zip / unzip untuk fitur mandiri exe tunggal .
karena ini akan menyebabkan masalah berikutnya.
Bagaimana cara mengurangi ukuran file exe tunggal!

Padahal, sejak awal harus menggunakan cara-cara serupa IL-Merge.

Seharusnya tidak ada perdebatan, ini buang-buang waktu, tidak ada yang meminta zip / unzip semuanya, namun mereka datang dengan desain ini dan menyia-nyiakan waktu mereka dan waktu kita.

Orang-orang meminta satu executable dan AOT, berhenti buang waktu kita Microsoft

Saya secara eksplisit ingin file tunggal tanpa AOT. Saya lebih suka kemampuan JIT sehingga saya dapat menggunakan refleksi, generik, dan kode yang dihasilkan runtime.

Saya kira MS tidak mau mendengar, ok

im selalu menentang penggunaan solusi zip / unzip untuk fitur mandiri exe tunggal .
karena ini akan menyebabkan masalah berikutnya.
Bagaimana cara mengurangi ukuran file exe tunggal!

Tidak yakin saya mengerti, seolah-olah Zipped-nya sudah dikompresi. Atau apakah yang Anda maksud adalah pengurangan dependensi yang berlebihan dan karena itu mengurangi ukuran sebelum kompresi?

Tidak memahami negativitas. Saya belum menggunakannya selain tes cepat. Namun tampaknya satu-satunya yang dapat dieksekusi berfungsi dengan baik untuk situasi penerapan aplikasi ke klien, atau sebagai alat CLI. Di situlah saya yakin fitur ini berguna. Di luar itu, di Dev atau lingkungan lain saya tidak melihat kasus penggunaan untuk itu, jadi apa yang telah mereka lakukan berfungsi dengan baik sebagai solusi untuk saat ini ..

@RUSY

Saya kira MS tidak mau mendengar, ok

Sebaliknya, mereka meminta dan mengumpulkan berbagai kasus penggunaan yang dapat Anda lihat di utas terkait. Pendapat Anda itu penting, tetapi pendapat orang lain di komunitas sama pentingnya dan Anda tidak boleh mengejek Microsoft karena mendengarkannya.

Berdasarkan pernyataan Anda, saya pikir Anda mungkin salah mengira saya sebagai Microsoft. Saya hanya anggota komunitas seperti Anda yang tidak berbicara untuk Microsoft dalam kapasitas apa pun.

im selalu menentang penggunaan solusi zip / unzip untuk fitur mandiri exe tunggal .
karena ini akan menyebabkan masalah berikutnya.
Bagaimana cara mengurangi ukuran file exe tunggal!

Tidak yakin saya mengerti, seolah-olah Zipped-nya sudah dikompresi. Atau apakah yang Anda maksud adalah pengurangan dependensi yang berlebihan dan karena itu mengurangi ukuran sebelum kompresi?

jika Anda menggunakan WebApi atau MVC atau ConsoleApp, tulis HelloWorld! Anda sangat tahu apa maksud saya.
file yang dikemas terlalu besar. terlalu banyak kode tetapi tidak akan pernah dieksekusi.
jika cara IL-Merge akan mengurangi cabang kode yang tidak digunakan.

Ya yakin saya melakukan konsol HelloWorld dan ya yakin 68K nya
Capture
Tidak ada yang mandiri adalah 67K
Tapi C #-nya bukan perakitan. Jika saya menginginkan <1K HelloWorld lalu mengapa menggunakan c #?
Aplikasi yang lebih besar menggunakan lebih banyak kerangka kerja, jadi pada satu titik lebih banyak kode khusus daripada kerangka kerja ..
Apakah kita benar-benar khawatir tentang beberapa 100K? Jika demikian, jangan gunakan kerangka kerja dan menghabiskan waktu menulis semuanya dari awal ??
Apa yang kulewatkan di sini?

im selalu menentang penggunaan solusi zip / unzip untuk fitur mandiri exe tunggal .
karena ini akan menyebabkan masalah berikutnya.
Bagaimana cara mengurangi ukuran file exe tunggal!
jika Anda menggunakan WebApi atau MVC atau ConsoleApp, tulis HelloWorld! Anda sangat tahu apa maksud saya.
file yang dikemas terlalu besar. terlalu banyak kode tetapi tidak akan pernah dieksekusi.
jika cara IL-Merge akan mengurangi cabang kode yang tidak digunakan.

@sgf ada dua masalah yang agak terpisah di sini:

  • Bagaimana cara mengurangi kode untuk suatu aplikasi?
  • Bagaimana cara mengemas aplikasi menjadi satu file?

Untuk pengurangan kode, ada beberapa teknik lebih lanjut

  • Menggabungkan IL: Ini bukan untuk semua aplikasi, karena kehilangan identitas perakitan dalam prosesnya. Ini bukan tujuan untuk pekerjaan single-exe saat ini.
  • Memangkas IL yang tidak digunakan: ILLinker bertujuan untuk memangkas IL yang tidak digunakan. Fitur ini diintegrasikan ke dalam dotnet SDK ( PublishTrimmed property), dan lebih banyak pengoptimalan di ILLinker sedang dikembangkan.
  • Zip / Unzip: dotnet publish saat ini tidak membuat zip file tunggal yang dipublikasikan, tetapi itu bisa dilakukan.

Bagaimana cara mengemas aplikasi menjadi satu file?
dotnet publish mendukung penerbitan ke dalam satu file - file yang diterbitkan akan sebesar aplikasi yang seharusnya.

Mengenai pembuatan kode asli:

  • Saat ini dukungan untuk menghasilkan kode native adalah melalui kompilator yang siap dijalankan ( PublishReadyToRun property).
  • Menerbitkan melalui kompilasi AOT memang bagus ( CoreRT ), tetapi belum tersedia. Dengan kompilasi AOT juga, ukuran file yang dapat dieksekusi bergantung pada opsi kompilasi: ex: apakah kita menyertakan jit untuk mengeksekusi kode yang dihasilkan, dll.?

Ya yakin saya melakukan konsol HelloWorld dan ya yakin 68K nya
Capture
Tidak ada yang mandiri adalah 67K
Tapi C #-nya bukan perakitan. Jika saya menginginkan <1K HelloWorld lalu mengapa menggunakan c #?
Aplikasi yang lebih besar menggunakan lebih banyak kerangka kerja, jadi pada satu titik lebih banyak kode khusus daripada kerangka kerja ..
Apakah kita benar-benar khawatir tentang beberapa 100K? Jika demikian, jangan gunakan kerangka kerja dan menghabiskan waktu menulis semuanya dari awal ??
Apa yang kulewatkan di sini?

maaf seperti yang ditunjukkan img ur, dengan self contianed. Itu 68626KB, sekitar 68mb = 68KK, tidak hanya 68K !!!
kita tidak perlu <1kb (Dengan self contianed Itu tidak mungkin), <3000KB ok, terima.
Tapi 68mb lebih dari 30X +
Anda tidak akan selalu hanya menulis Program HelloWorld !!!

Maaf, larut malam salah dengan K's
Terima kasih atas penjelasan / info tambahan swaroop-sridhar, beberapa sakelar baru di sana yang tidak saya ketahui.
Baru saja mencoba dengan 3. pratinjau 6 dengan sakelar berikut

dotnet publish -r RID / p: PublishTrimmed = true / p: PublishSingleFile = true
dan sekarang turun menjadi 29.000K

Tentu tidak semua aplikasi akan menjadi Hello World, tetapi untuk Aplikasi C # Core SelfContained, yang juga berisi runtime ... Secara pribadi saya tidak perlu khawatir. Tentu saya mengerti jika Anda menulis alat konsol kecil alangkah baiknya memiliki 3K. Tapi mengapa menggunakan C # untuk itu?
Diskusi yang menarik ya guys!

image
Capture

30mb LOL, hubungi saya ketika itu akan menjadi sekitar 1-3mb, runtime penuh dengan bloat, periksa GO, orang-orang bermigrasi dalam gelombang

https://www.jetbrains.com/lp/devecosystem-2019/

Bahkan kotlin mulai mendapatkan bagian, dan dengan kotlin asli itu membuat c # malu

Dan Swift datang ke windows https://forums.swift.org/t/swift-win32-programming/20686

Jadi inilah beberapa saran:

  • Tambahkan opsi untuk menghapus Refleksi
  • Tambahkan opsi untuk menghapus barang JIT
  • Optimalkan kode C # dengan lebih baik sehingga Anda tidak bergantung pada JIT

30mb LOL, hubungi saya ketika itu akan menjadi sekitar 1-3mb, runtime penuh dengan bloat, periksa GO, orang-orang bermigrasi dalam gelombang

https://www.jetbrains.com/lp/devecosystem-2019/

Bahkan kotlin mulai mendapatkan bagian, dan dengan kotlin asli itu membuat c # malu

Dan Swift datang ke windows https://forums.swift.org/t/swift-win32-programming/20686

Jadi inilah beberapa saran:

  • Tambahkan opsi untuk menghapus Refleksi
  • Tambahkan opsi untuk menghapus barang JIT
  • Optimalkan kode C # dengan lebih baik sehingga Anda tidak bergantung pada JIT

Menurut saya ini tidak adil. .NET tidak dirancang untuk membangun aplikasi konsol file tunggal terkecil. Kami menggunakannya untuk situs web Asp.Net dan apis. Oleh karena itu, framework itu sendiri menghadirkan banyak fitur selain banyak paket nuget yang dapat Anda sertakan. Saya tidak dapat membayangkan bahwa ada kekhawatiran jika aplikasi web berukuran 50 atau beberapa ratus megabyte. Perhatian utama adalah kecepatan, penggunaan memori dan dalam pemeliharaan jangka panjang. Siapa yang peduli dengan ukuran di server.

Jika satu-satunya niat Anda adalah membuat aplikasi konsol ukuran mb tunggal kecil, mengapa tidak menggunakan alat yang tepat untuk pekerjaan itu. Alih-alih mengeluh bahwa aplikasi dengan kerangka berfitur lengkap yang dikemas dalam satu file berukuran beberapa puluh megabyte bahkan untuk "dunia hallo", mengapa tidak menggunakan Rust misalnya?

Microsoft melakukan pekerjaan yang hebat dengan .NET sejak awal dan bahkan lebih dalam beberapa tahun terakhir, jadi terima kasih untuk itu.

Apa jawaban untuk rasa tidak masuk akal, kebohongan dan kurangnya efisiensi?

Anda gagal menyadari betapa salahnya arah inti .net, dan baru-baru ini mereka mulai menyadarinya dengan bekerja di Distribution / IL Merge / AOT

Dan sekarang untuk beralih ke gerobak perakitan web, mereka tidak dapat melakukannya karena .net runtime adalah pembengkakan yang BESAR sehingga mereka tidak dapat menggunakan file berukuran layak

Dan Anda masih terjebak dengan "Siapa yang peduli dengan ukuran di server.", Cara berpikir inilah yang membuat inti .net "yang seharusnya modern" menjadi tumpukan teknologi yang sudah ketinggalan zaman dan tidak relevan

Microsoft tidak melakukan pekerjaan yang baik dengan .net, mereka gagal karena mereka ingin menyenangkan orang tua untuk kompatibilitas framework .net, itu adalah salah satu kesalahan mereka

Maaf jika saya terdengar kasar tetapi terkadang Anda perlu melakukan perubahan

Maaf jika saya terdengar kasar tapi

Anda terdengar kasar, titik. Itu, dan pemecatan Anda dan melompat ke kesimpulan, tidak memiliki efek persuasif.

Maaf, larut malam salah dengan K's
Terima kasih atas penjelasan / info tambahan swaroop-sridhar, beberapa sakelar baru di sana yang tidak saya ketahui.
Baru saja mencoba dengan 3. pratinjau 6 dengan sakelar berikut

dotnet publish -r RID / p: PublishTrimmed = true / p: PublishSingleFile = true
dan sekarang turun menjadi 29.000K

Tentu tidak semua aplikasi akan menjadi Hello World, tetapi untuk Aplikasi C # Core SelfContained, yang juga berisi runtime ... Secara pribadi saya tidak perlu khawatir. Tentu saya mengerti jika Anda menulis alat konsol kecil alangkah baiknya memiliki 3K. Tapi mengapa menggunakan C # untuk itu?
Diskusi yang menarik ya guys!

image
Capture

Bukankah sebagai bahasa modern harus memiliki sedikit ambisi untuk mempersatukan dunia?
Apakah Anda ingin semua pengembang menulis c # kembali ke rumah untuk C ++? atau dorong mereka ke Go, Kotlin, Swift?
Pangsa pasar dan semakin mengikis c #?

.Net karena tidak mengimplementasikan cross-platform melewatkan 15+ tahun pertama dari peluang pengembangan yang besar.
Tapi Sekarang .net kembali ke cara yang benar.

Ya seperti yang saya komentari sebelumnya, saya tidak yakin mengapa negativitasnya.
.Net Core tidak lain adalah luar biasa jika Anda berasal dari Full Framework. Dan visi penggabungan .Net Standard + Core menurut saya masuk akal dan progresif.

Membandingkan .NET ke GO atau bahasa / kerangka kerja lainnya tidak ada gunanya.
Pokoknya, Saya TIDAK MENGENAI topik ini, karena saya pikir solusi yang mereka kerjakan dan tingkatkan untuk Single .exe telah menyelesaikan 'permintaan' saya dari beberapa tahun yang lalu dengan cukup baik ... Cukup baik untuk saya, dan sesuai dengan kebutuhan mendesak saya.

Terima kasih Guys & Gals!

DI LUAR

Saya ingin mengingatkan semua orang di utas ini tentang Pedoman Perilaku .

Tidak apa-apa untuk tidak setuju atau memiliki pendapat berbeda, tapi tolong, mari bersikap sopan dan mari kita ungkapkan itu sebagai diskusi teknis. Tidak perlu menggunakan kata-kata yang kuat.
Selain itu, menargetkan ide, implementasi dengan pendapat Anda adalah permainan yang adil. NAMUN, TIDAK DITERIMA untuk menyerang ORANG di belakang mereka. Tolong mari kita semua saling menghormati satu sama lain, mari kita dengar pendapat yang berbeda dan mari kita menahan diri dari pernyataan yang kuat dan komentar yang menyinggung.

Juga, saya ingin meminta semua orang untuk terbuka terhadap sudut pandang dan pendapat lain. Sebelum membuat penilaian, biasanya baik untuk mendengarkan pihak lain - sering kali ada cerita di balik mengapa keadaan menjadi seperti ini. Menyodok ide dan solusi ketika seseorang tahu mengapa mereka seperti itu biasanya lebih produktif.

Terima kasih!

im selalu menentang penggunaan solusi zip / unzip untuk fitur mandiri exe tunggal .
karena ini akan menyebabkan masalah berikutnya.
Bagaimana cara mengurangi ukuran file exe tunggal!
jika Anda menggunakan WebApi atau MVC atau ConsoleApp, tulis HelloWorld! Anda sangat tahu apa maksud saya.
file yang dikemas terlalu besar. terlalu banyak kode tetapi tidak akan pernah dieksekusi.
jika cara IL-Merge akan mengurangi cabang kode yang tidak digunakan.

@sgf ada dua masalah yang agak terpisah di sini:

  • Bagaimana cara mengurangi kode untuk suatu aplikasi?
  • Bagaimana cara mengemas aplikasi menjadi satu file?

Untuk pengurangan kode, ada beberapa teknik lebih lanjut

  • Menggabungkan IL: Ini bukan untuk semua aplikasi, karena kehilangan identitas perakitan dalam prosesnya. Ini bukan tujuan untuk pekerjaan single-exe saat ini.
  • Memangkas IL yang tidak digunakan: ILLinker bertujuan untuk memangkas IL yang tidak digunakan. Fitur ini diintegrasikan ke dalam dotnet SDK ( PublishTrimmed property), dan lebih banyak pengoptimalan di ILLinker sedang dikembangkan.
  • Zip / Unzip: dotnet publish saat ini tidak membuat zip file tunggal yang dipublikasikan, tetapi itu bisa dilakukan.

Bagaimana cara mengemas aplikasi menjadi satu file?
dotnet publish mendukung penerbitan ke dalam satu file - file yang diterbitkan akan sebesar aplikasi yang seharusnya.

Mengenai pembuatan kode asli:

  • Saat ini dukungan untuk menghasilkan kode native adalah melalui kompilator yang siap dijalankan ( PublishReadyToRun property).
  • Menerbitkan melalui kompilasi AOT memang bagus ( CoreRT ), tetapi belum tersedia. Dengan kompilasi AOT juga, ukuran file yang dapat dieksekusi bergantung pada opsi kompilasi: ex: apakah kita menyertakan jit untuk mengeksekusi kode yang dihasilkan, dll.?

Seperti yang diperlukan, gabungkan native-DLL dinamis ke Satu nama seperti: XXX.exe (Tidak Dikelola).
Menggunakan analisis statis untuk menganalisis saat mengompilasi Penautan Tingkat Fungsi nativeDLLs (UnManaged).

api-ms-win-core-console-l1-1-0.dll
api-ms-win-core-datetime-l1-1-0.dll
api-ms-win-core-debug-l1-1-0.dll
api-ms-win-core-errorhandling-l1-1-0.dll
api-ms-win-core-file-l1-1-0.dll
api-ms-win-core-file-l1-2-0.dll
api-ms-win-core-file-l2-1-0.dll
api-ms-win-core-handle-l1-1-0.dll
api-ms-win-core-heap-l1-1-0.dll
api-ms-win-core-interlocked-l1-1-0.dll
api-ms-win-core-libraryloader-l1-1-0.dll
api-ms-win-core-localization-l1-2-0.dll
api-ms-win-core-memory-l1-1-0.dll
api-ms-win-core-namedpipe-l1-1-0.dll
api-ms-win-core-processenvironment-l1-1-0.dll
api-ms-win-core-processthreads-l1-1-0.dll
api-ms-win-core-processthreads-l1-1-1.dll
api-ms-win-core-profile-l1-1-0.dll
api-ms-win-core-rtlsupport-l1-1-0.dll
api-ms-win-core-string-l1-1-0.dll
api-ms-win-core-synch-l1-1-0.dll
api-ms-win-core-synch-l1-2-0.dll
api-ms-win-core-sysinfo-l1-1-0.dll
api-ms-win-core-timezone-l1-1-0.dll
api-ms-win-core-util-l1-1-0.dll
api-ms-win-crt-conio-l1-1-0.dll
api-ms-win-crt-convert-l1-1-0.dll
api-ms-win-crt-environment-l1-1-0.dll
api-ms-win-crt-filesystem-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-locale-l1-1-0.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-multibyte-l1-1-0.dll
api-ms-win-crt-private-l1-1-0.dll
api-ms-win-crt-process-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-time-l1-1-0.dll
api-ms-win-crt-utility-l1-1-0.dll
aspnetcorev2_inprocess.dll
clrcompression.dll
clretwrc.dll
clrjit.dll
coreclr.dll
dbgshim.dll
dotnet-aspnet-codegenerator-design.dll
hostfxr.dll
hostpolicy.dll
mscordaccore_amd64_amd64_4.6.27317.07.dll
mscordbi.dll
mscorrc.dll
mscorrc.debug.dll
sni.dll
sos.dll
sos_amd64_amd64_4.6.27317.07.dll
ucrtbase.dll
...etc...

jika melakukan pekerjaan dengan baik hasilnya mungkin akan menjadi 2-3mb. ketika saya langsung mengemas semuanya dengan 7zip, dibutuhkan sekitar 4.85mb. Sekarang kita mendapatkan XXX.exe

mengembangkan Tautan Tingkat Fungsi serupa dengan IL-merge.
Untuk trik lama yang sama DLL yang dikelola lagi.
Terakhir, sematkan DLL terkelola sebagai Bagian PE.exe (tandai sebagai bagian .net).

Untuk mencerminkan, analisis DLL dari jenis refleksi. Mempertahankan metadata dan jenis refleksi (termasuk fungsi) dan semua yang bergantung pada pohonnya.

Saya minta maaf, saya tidak ingin mengambil lebih banyak waktu untuk berpartisipasi dalam diskusi tentang ini lagi. Opini tidak dapat disatukan.
Awalnya saya mengharapkan hasilnya. Tapi sekarang, saya mungkin harus mempertimbangkan bahasa pemrograman lain untuk memenuhi kebutuhan saya (mungkin Dlang mungkin Go mungkin Kotlin mungkin Nim atau mungkin Rust adalah yang terbaik).

terima kasih untuk semua, bicarakan ini dengan saya. maaf atas omelan saya. di luar

@sgf Saya pikir Anda telah membuat beberapa poin bagus dan saya tahu Anda telah menandatangani topik tersebut. Hanya ingin mengatakan bahwa saya yakin fitur yang Anda minta, akan hadir dalam beberapa tahun mendatang ke .NET Core. Padahal jika Anda ingin mendapatkan ukuran file kecil hari ini, mungkin saja jika Anda menargetkan mono.

  1. Mono sudah mendukung kompilasi AOT dengan Linking untuk memperkecil ukuran file. Inilah salah satu alasan mengapa mono dipilih untuk implementasi runtime browser .net. https://www.mono-project.com/docs/advanced/aot/ dan saya berasumsi itulah sebabnya proyek Blazor dapat memiliki Linker.

  2. Microsoft telah menyatakan bahwa mereka ingin mengkonsolidasikan runtime .NET mereka menjadi satu yang "sangat kuat". Daripada memiliki mono untuk beberapa hal, dan .NET Core untuk yang lain, mereka menginginkan runtime tunggal yang dapat memenuhi semua skenario. Defacto ini berarti perlu mendukung AOT dan Linking / Code stripping dll. Oleh karena itu saya berharap dalam beberapa tahun ke depan, baik runtime .NET Core untuk mendapatkan fitur-fitur ini, atau untuk fitur Mono dan .NET Core untuk dikonsolidasikan menjadi yang baru. Runtime.

Jika ada yang lebih tahu, tolong beri tahu saya.

+ 2 ¢

Saya pikir masalahnya adalah sepertinya keputusan dibuat tanpa banyak informasi. Hari-hari ini di mana-mana saya melihat orang-orang membicarakan hal ini; sebagian besar orang yang menerapkan program memiliki ini di atas daftar keinginan mereka, dan banyak yang beralih dari C # ke bahasa lain dengan AOT / deployability yang lebih baik. Saya pikir itu fakta yang cukup mapan yang menjadi sangat jelas jika Anda aktif di komunitas. Namun, hal itu tampaknya tidak memengaruhi keputusan sedikit pun.

Masalahnya, sepertinya tidak ada yang tahu persis sejauh mana ini penting. Bagi saya pribadi ini sangat penting, jadi tentu saja saya sangat bias tetapi kesan yang saya miliki adalah bahwa secara keseluruhan ini adalah yang terpenting dan tampaknya MS tidak memberikan perhatian yang layak, meninggalkan banyak kesan bagi kita mereka mengambil keputusan berseragam yang pada gilirannya tidak membuat kami yakin tentang masa depan teknologi secara keseluruhan.

Saya setuju dengan @RUSshy. CoreRT adalah proyek luar biasa dan pasti menuju ke arah yang benar, tetapi secara keseluruhan tampaknya semua upaya difokuskan pada teknologi server / web. Hal-hal seperti runtime, jits, dan binari besar berbicara sendiri dalam hal itu. Tidak ada yang menerapkan perangkat lunak menginginkan hal-hal itu.

Meskipun demikian, saya secara pribadi masih menggunakan teknologi ini meskipun saya tidak terlalu menahan diri tentang masa depan di beberapa area.

Saya ingin melihat lebih banyak partisipasi dari komunitas ke arah yang diambil, meskipun ternyata itu berlawanan dengan apa yang saya harapkan secara pribadi. Namun sejauh ini tampaknya keputusan dibuat tanpa memperhitungkan hal itu. Tampaknya server / web adalah yang menghasilkan uang dan orang-orang yang menyebarkan program adalah minoritas yang dapat diabaikan (setidaknya dalam hal keuntungan), tetapi jika itu masalahnya, setidaknya saya ingin tahu itulah yang mereka dasarkan keputusan mereka (yang mana sangat mungkin), karena dari luar sepertinya mereka sedang melempar koin.

@ Alan-FGR

Namun sejauh ini tampaknya keputusan dibuat tanpa memperhitungkan hal itu.

Apakah Anda memiliki contoh spesifik tentang keputusan seperti itu untuk dibagikan, karena saya ingin tahu lebih banyak.

Saya rasa MS sangat menyadari kekurangan dari runtime inti dotnet saat ini dan itulah mengapa mereka akan mencari kesamaan fitur dengan runtime mono di masa mendatang.

Lihat saja catatan rilis untuk .net core 3.0.0 preview 6:

Hari ini, kami mengumumkan .NET Core 3.0 Preview 6. Ini mencakup pembaruan untuk menyusun rakitan untuk peningkatan startup, mengoptimalkan aplikasi untuk ukuran dengan peningkatan linker dan EventPipe. Kami juga telah merilis gambar Docker baru untuk Alpine di ARM64.

Bagi saya, mereka sangat sadar bahwa ukuran aplikasi penting untuk skenario tertentu - terutama sekarang dengan Blazor dalam campurannya.

@ Alan-FGR Setuju, fokus web agak aneh mengingat IIS memiliki sekitar 8% pangsa pasar dan jatuh. ASP.NET tidak relevan, dan tidak ada perbaikan pada C # atau pustaka standarnya yang akan mengubahnya. C # didukung oleh aplikasi konsol, layanan Windows, aplikasi seluler, dan game PC. Itu berutang keberadaannya yang berkelanjutan ke Unity dan Xamarin. Yang memalukan, karena C # adalah bahasa yang sangat menyenangkan untuk dikembangkan. Itu pujian yang tinggi datang dari pengembang Java lama yang masih berpikir Microsoft meninggalkan jejak air yang tinggi dengan Windows XP.

Seperti yang diperlukan, gabungkan native-DLL dinamis ke Satu nama seperti: XXX.exe (Tidak Dikelola).
Menggunakan analisis statis untuk menganalisis saat mengompilasi Penautan Tingkat Fungsi nativeDLLs (UnManaged).

Saya tidak yakin apa yang Anda maksud dengan penggabungan dinamis, tetapi ada rencana untuk secara statis menghubungkan komponen asli dengan host. Silakan lihat bagian ini .

mengembangkan Tautan Tingkat Fungsi serupa dengan IL-merge.
Untuk mencerminkan, analisis DLL dari jenis refleksi. Mempertahankan metadata dan jenis refleksi (termasuk fungsi) dan semua yang bergantung pada pohonnya.

Kami telah membahas opsi untuk menggabungkan rakitan menjadi satu, dan memiliki tabel meta-data samping untuk mendukung fitur dinamis. Ini memang memberikan penghematan ukuran yang cukup besar. Tetapi biaya untuk mengimplementasikannya cukup tinggi - karena dukungan meta-data baru, dan perubahan yang diperlukan dalam debugger / profiler dll untuk menanganinya.

Ada beberapa opsi lain untuk mengurangi ukuran biner - misalnya, ketika kami dapat mengeksekusi satu file secara langsung (tanpa harus mengekstrak ke file), kami dapat melepaskan tanda tangan / sertifikat pada setiap DLL untuk mendukung menandatangani aplikasi secara keseluruhan. Ini terkadang dapat menghemat beberapa MB.

Namun sejauh ini tampaknya keputusan dibuat tanpa memperhitungkan hal itu.

Apakah Anda memiliki contoh spesifik tentang keputusan seperti itu untuk dibagikan, karena saya ingin tahu lebih banyak.

Saya rasa MS sangat menyadari kekurangan dari runtime inti dotnet saat ini dan itulah mengapa mereka akan mencari kesamaan fitur dengan runtime mono di masa mendatang.

@dazinator Saya pikir fakta bahwa MS entah bagaimana menganggap Mono adalah solusi yang layak untuk apa pun menunjukkan bahwa mereka benar-benar tidak tahu produk mereka. Saya telah menggunakan Mono, dan meskipun ini adalah bagian penting dari teknologi dan sangat membantu mempopulerkan .NET, itu pasti kurang berkualitas ... Xamarin melakukan beberapa pekerjaan pemasaran yang hebat mempromosikan teknologi mereka, tetapi itu didasarkan pada terlalu menjanjikan dan kurang mengirimkan, dan tampaknya siapa pun yang mengambil keputusan tersebut di MS hanya melihat beberapa materi promo mereka dan tidak pernah benar-benar menggunakan teknologi tersebut. CoreRT di sisi lain adalah teknologi yang sejauh ini memberikan hasil yang sangat berlebihan bagi saya. Ini pada tingkat kualitas lain menurut saya, namun diabaikan oleh MS demi beberapa teknologi yang saya curigai terkait dengan pita bebek.

Setuju, fokus web agak aneh mengingat IIS memiliki sekitar 8% pangsa pasar dan jatuh. ASP.NET tidak relevan, dan tidak ada perbaikan pada C # atau pustaka standarnya yang akan mengubahnya. C # didukung oleh aplikasi konsol, layanan Windows, aplikasi seluler, dan game PC.

@kjrum itulah intinya. Namun, mungkin bagi mereka 8% pangsa pasar di web masih jauh lebih penting daripada Windows dan aplikasi seluler. Teknisi web yang baik setidaknya membantu penjualan server Windows, jadi minat mereka pada hal itu cukup jelas, tetapi terlalu fokus pada hal itu juga merupakan strategi yang sangat dangkal dan saya menolak untuk percaya bahwa itulah yang mendorong keputusan mereka. MS tampaknya menuju ke arah yang benar dengan yayasan dotnet dan begitu banyak proyek menjanjikan yang sedang berlangsung, tetapi tampaknya mereka membiarkan kesempatan untuk memiliki teknologi yang dominan berlalu begitu saja.

Saya tahu ini anekdot jadi mungkin tidak ada artinya, tetapi semua orang yang saya kenal yang menggunakan C # untuk proyek mereka (kebanyakan game dev) pindah ke sesuatu yang lain karena keterbatasan yang benar-benar dapat dipecahkan. Mereka pindah ke Rust, D, Go, dan C ++. Saya sendiri menggunakan C ++ secara teratur dan saya belajar Rust, tetapi saya masih menggunakan C # untuk beberapa proyek pribadi karena jauh lebih baik, meskipun menerapkan produk berkualitas sangat merepotkan.

Itu berutang keberadaannya yang berkelanjutan ke Unity dan Xamarin.

Ya, alangkah berkah dan kutukan karena banyaknya masalah teknis. Unity misalnya memiliki reputasi yang sangat buruk tetapi untungnya hal itu tampaknya tidak memengaruhi .NET / C #.
Namun XNA, meskipun jauh dari sempurna, masih memiliki reputasi yang luar biasa di antara pengguna dan pengembang.

Senang melihat negeri ini dengan .NET Core 3.0 hari ini. Terima kasih semuanya! 👍

Saya tidak yakin itu yang diinginkan orang, jika kita berakhir dengan kalkulator sederhana yaitu 141mb exe, maka fiturnya gagal (dan saya yakin biaya sebenarnya adalah 141mb * 2, karena itu akan mengekstrak barang di suatu tempat yang benar)

image

Ya, pasti itu yang saya inginkan. Ini masih lebih kecil dari penerapan mandiri biasa.

Pemangkasan perakitan yang lebih agresif dan pengocokan pohon akan diterima, tetapi ini adalah awal yang sangat berguna. Peningkatan bertahap adalah cara paling cerdas untuk memberikan nilai.

Oh, ini yang kamu inginkan? saya buruk, saya tidak tahu aplikasi kembung itu populer

Kalkulator tidak membutuhkan JIT, bahkan Refleksi, tetapi karena itu yang Anda inginkan, saya kira saya salah sejak awal, saya harus menghentikan pemrograman

@RUSshy Ini tidak lebih membengkak dari penyebaran mandiri lainnya, kan?

Menghapus JIT dan refleksi tidak tergantung dari apakah semuanya dikemas ke dalam satu exe. Yaitu Anda dapat menghapus JIT dan refleksi tanpa single-exe, dan Anda dapat memiliki single-exe tanpa menghapus JIT dan refleksi. Mereka adalah bagian dari pekerjaan yang terpisah.

Saya tidak yakin itu yang diinginkan orang, jika kita berakhir dengan kalkulator sederhana yaitu 141mb exe, maka fiturnya gagal (dan saya yakin biaya sebenarnya adalah 141mb * 2, karena itu akan mengekstrak barang di suatu tempat yang benar)

ekstrak file tersebut ke C: Users [YourUserName] AppDataLocalTemp.net

Apakah ada cara untuk mengganti di mana single exe akan dibongkar?
Saya mengalami masalah ketika mencoba mengekstrak ke / var / .... di mana pengguna tidak memiliki izin untuk menulis.

@eiva OS yang mana ini? Apakah itu AWS lambda?
https://github.com/dotnet/core-setup/issues/7940 trek memperbaiki masalah ini.

Sementara itu, Anda dapat menyetel variabel lingkungan DOTNET_BUNDLE_EXTRACT_BASE_DIR untuk mengontrol di mana file yang dibundel akan diekstraksi.

@ swaroop-sridhar Terima kasih atas balasannya!
Ini adalah centos.7 meluncurkan aplikasi dari akun layanan "terbatas".

@ jnm2 Saya menghargai bahwa Anda menyukai C #, saya juga. Tapi mari kita jujur, itu gila bahwa kalkulator adalah 128 megabyte.

@TechnikEmpire Saya merasa perlu untuk menunjukkan bahwa "I love C #" adalah pengurangan yang cukup intensif dari apa yang saya katakan di atas: D

Saya pribadi tidak akan merasa sepenuhnya puas sampai saya memiliki kemampuan untuk melakukan pengocokan kode dan libs saya sendiri, referensi lib pihak ketiga, dan .NET itu sendiri. Tetapi itu tidak membuat fitur single-exe menjadi kurang berharga bagi saya hari ini. Ini adalah langkah sepanjang satu dimensi. Goyangan pohon adalah dimensi independen dan yang saya harap mendapat banyak perhatian.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat