Runtime: एकल exe सेल्फ कंसोल ऐप शामिल है

यह परिदृश्य अभी समर्थित नहीं है। काम के लिए https://github.com/dotnet/corert रेपो पर नज़र रखें, जो इस मार्ग का नेतृत्व करेगा।

CoreRT इस समाधान की खोज करने के लिए सही जगह है।

धन्यवाद। ऐसा लगता है कि CoreRT वास्तव में वही है जो मैं देख रहा था।

दूसरों के लिए जो इस पर ठोकर खा सकते हैं, यहां पढ़ें

मैं विशेष रूप से समय संकलन के बिना इस सुविधा

.NET फ्रेमवर्क "धोखा" है क्योंकि आपके पास ओएस में पहले से मौजूद बहुत सारी फाइलें हैं।
यदि आप चाहते हैं तो मशीन-वाइड साझा .NET कोर स्थापित करके आप .NET कोर के साथ ही इसे प्राप्त कर सकते हैं।

अपनी सभी फाइलों को एक में मिलाने के लिए CoreCLR को रिफलैक्ट करना (incl। Native + प्रबंधित) गैर-तुच्छ काम है और मुझे नहीं लगता कि यह परिदृश्य बहुत अधिक ग्राहकों के लिए दिलचस्प है।

अंतर यह है कि प्रत्येक विंडोज मशीन में .NET फ्रेमवर्क की गारंटी है, लेकिन .NET कोर नहीं है, इसलिए जब तक कि एक विशेष कारण नहीं है कि तैनाती को और अधिक जटिल बनाने के लायक है, तो मुझे लगता है कि मैं वहां रहूंगा।
मुझे लगता है कि ग्राहक आमतौर पर एकल exe उपयोगिताओं को नहीं लिखते हैं। शायद एक दिन। :-)

जब तक कि एक विशेष कारण नहीं है कि तैनाती को और अधिक जटिल बनाने के लायक है

.NET फ्रेमवर्क .NET .NET पर पसंद करने के कई कारण हैं। प्रदर्शन, प्रतिरूपकता, सेवाक्षमता, अलगाव इत्यादि। और यह क्रॉस-प्लेटफॉर्म-नेस की अनदेखी कर रहा है।

एक एकल exe उपयोगिता होने के नाते ज्यादातर एक कॉस्मेटिक चिंता है। इसमें कोई वास्तविक कार्यात्मक अंतर नहीं है (यदि किसी को भी शामिल किया गया है) यदि निष्पादन योग्य एक फ़ाइल या एक फ़ोल्डर है जिसमें मुट्ठी भर फाइलें हैं।

@ एमेलीनो ओह मैं सामान्य रूप से परियोजनाओं के लिए सहमत हूं, यह निश्चित रूप से सच है। छोटी उपयोगिताओं में जहां यह कॉस्मेटिक वांछनीय है, .NET फ्रेमवर्क ने इस प्रकार अब तक काफी अच्छा काम किया है। मैं मानता हूं कि यह एक सभा कंपनी और कॉपीराइट संदेश को निर्दिष्ट करने में सक्षम होने के रूप में एक ही अर्थ में कॉस्मेटिक है। लेकिन एक कॉस्मेटिक चीज होने के नाते यह मुझे कम पसंद नहीं है। जाहिर है कि यहां प्राथमिकता नहीं है, यह काफी समझ में आता है।

संभवतः संबंधित: https://github.com/dotnet/core/issues/600

यह ज्यादातर कॉस्मेटिक नहीं है। कल्पना कीजिए कि मैं एक ऐसे एप्लिकेशन को वितरित करना चाहता हूं जिसमें कई घटक अंदर हों, जैसे Idsrv4 या रेवेनडब + मेरा अपना सामान। वे एस्पनेट कोर बिट्स पर निर्भरता लेते हैं। यह सब ठीक काम करता है जब तक कि वे एस्पनेट कोर के एक ही संस्करण पर निर्भर करते हैं। जैसे ही उनमें से एक अगले संस्करण के लिए आगे बढ़ता है यह शायद अब काम नहीं करेगा। यदि OTOH मैं प्रत्येक घटक को एक एकल में ilmerge कर सकता है। तो समस्या दूर हो जाएगी।

एक बात का ध्यान रखें कि सिर्फ ILMerge के काम न करने से ज्यादा तकनीकी समस्याएं हैं। रनटाइम मूल रूप से कई फाइलों में विभाजित है, और सीएलआर होस्ट, रनटाइम निर्भरता पाठ फ़ाइल, और अधिक जैसी सहायक फाइलें भी हैं। एक एकल-फ़ाइल निष्पादन योग्य एकमात्र कारण अतीत में काम किया है, क्योंकि .NET फ्रेमवर्क, एक वैश्विक सिस्टम-वाइड इंस्टॉलेशन, पर भरोसा किया गया था। दो परिदृश्यों की तुलना करना थोड़ा अनुचित है, क्योंकि .NET फ्रेमवर्क में वास्तव में "स्व-निहित" विकल्प नहीं है।

यह सब ठीक काम करता है जब तक कि वे एस्पनेट कोर के एक ही संस्करण पर निर्भर करते हैं। जैसे ही उनमें से एक अगले संस्करण के लिए आगे बढ़ता है यह शायद अब काम नहीं करेगा।

यह वास्तव में सच नहीं है। आप अलग-अलग रनटाइम संस्करणों के खिलाफ कई अलग-अलग एप्लिकेशन प्रकाशित कर सकते हैं और फिर उन्हें उसी "uber-app" में बंडल कर सकते हैं। आप बस उनकी निर्भरता को एक फ़ोल्डर में नहीं मिला सकते हैं। यहां तक ​​कि अगर आप ढांचे पर निर्भर प्रकाशन विकल्प का उपयोग करते हैं, तो भी आप संस्करणों को मिला सकते हैं और मिलान कर सकते हैं। मैं समझता हूं कि यह शाब्दिक रूप से एकल फ़ाइल होने से कम सुविधाजनक है, और पीई में एक संसाधन के रूप में एक exe को एम्बेड करने जैसी चीजों को रोक सकता है। मुझे यकीन नहीं है कि अगर आप इसका जिक्र कर रहे हैं, हालांकि, तब भी आपको शायद इसे निष्पादित करने के लिए फ़ाइल निकालने की आवश्यकता होगी, जिसे आप अभी भी एक निर्देशिका के साथ कर सकते हैं।

मेरा मतलब रनटाइम संस्करण नहीं था, मुझे पता है कि काम नहीं कर रहा है। मेरा क्या मतलब है, मेरे परिदृश्य में क्या होता है जब प्रत्येक घटक [email protected] पर निर्भरता लेता है [email protected] को अपडेट

साथ ही @thefringeninja प्रासंगिक बिंदु, मैं सुझाव ओपेड को कम करती है। यह एक तैनाती के साथ कुछ गलत होने की संभावना को कम करता है, आपने जो भी भेजा है उसकी संज्ञानात्मक सराहना के बोझ को कम करता है और ऑप्स टूलींग के लिए कॉन्फ़िगर को कम करता है यह स्क्रिप्टिंग, या वांछित स्थिति।

मैं dotnet की सराहना करता हूं

एक डेवलपर के रूप में, मैं ILMerge को कोर में वापस रखने की सराहना करता हूं। 👍

Dotnet.exe एक एकल फ़ाइल है। NuGet.exe एक एकल फ़ाइल है। मुझे लगता है कि सौंदर्य प्रसाधन महत्वपूर्ण हैं, और एक एकल फ़ाइल इस तरह से सादगी दिखाती है, जिसमें 100 फ़ाइलों वाला फ़ोल्डर नहीं होता है! डॉटनेटकोर के साथ इसे प्राप्त करने का तरीका खोजने के लिए बहुत अच्छा होगा

मुझे लगता है कि यह संभव था, और कई हफ्तों के काम के बाद, सीएलआई कंसोल टूल को एक एकल .exe में प्रकाशित करने के लिए आया था ... उम्म को इस समय लगता है कि मैं सिर्फ एक * .exe प्राप्त नहीं कर सकता हूं।
मैंने सोचा था कि आत्म निहित कोर क्षुधा की बात थी?

@PRIMETSS

मैंने सोचा था कि आत्म निहित कोर क्षुधा की बात थी?

स्व-निहित ऐप्स की बात यह है कि वे स्व-निहित हैं, अर्थात, उन्हें .Net कोर को लक्ष्य मशीन पर स्थापित करने की आवश्यकता नहीं है, क्योंकि ऐप में ही वह सब कुछ है, जिसे उसे चलाने की आवश्यकता है।

इस तरह के ऐप को तैनात करने के लिए, आपको फ़ाइलों की एक पूरी निर्देशिका को कॉपी करना होगा। सिर्फ एक फ़ाइल होने से तैनाती आसान हो जाएगी, लेकिन यह है, यह अभी भी एक स्व-निहित ऐप है उसके बिना भी।

बड़े और सेवा जैसे ऐप के लिए यह शायद उतना महत्वपूर्ण नहीं है, लेकिन कमांड-लाइन टूल और छोटे ऐप के लिए यह जितना संभव हो उतना सरल और COPY- परिनियोजन के अनुकूल होना आवश्यक है।

मैं नियमित रूप से .NET में कमांड लाइन टूल लिखता हूं और उन्हें 1 EXE अपग्रेड / तैनाती / पैकेजिंग WAY सरल बनाता है। मैं हमेशा EXE के अंदर सभी .config और अन्य आवश्यक फाइलों को पैक करता हूं।

उस एकल-EXE को एक मिनी-कंटेनर के रूप में सोचें। कंटेनर आधारित तैनाती के लगभग सभी लाभ यहां लागू होते हैं।

यह सिर्फ भयानक है मुझे आश्चर्य है कि यह डिजाइन प्रक्रिया के दौरान क्यों अनुमोदित किया गया था, अपने आवेदन को अपने एक ग्राहक को वितरित करना चाहते हैं, फिर उसे शुभकामनाएं कि क्या खोलना है:

यह सिर्फ बदसूरत और एक पूरी गड़बड़ है

रनटाइम /
MyProgram.exe
MyLib.dll

यह एक बेहतर विचार है

यहां तक ​​कि जावा बेहतर है कि संभाल:

हाँ, मैं उसी तर्ज पर सोच रहा था, क्योंकि स्वयं निहित क्षुधा के साथ रनटाइम फ़ाइलों को इसके साथ शामिल करने की आवश्यकता है (जाहिर है!) (और हमारे पास उन को मर्ज करने का एक तरीका नहीं है), तो मैंने भी सोचा कि बस एक फ़ोल्डर जुदाई होगा। निडर बनो, और हाँ मुझे भी लगता है कि रनटाइम फ़ाइलों को एक रनटाइम फ़ोल्डर में संग्रहीत किया जाना चाहिए, इसलिए कोई भी कोर में लिखे गए कमांड लाइन टूल का उपयोग करने की कोशिश कर रहा है, कम से कम इसे थोड़ा और अधिक सहज रूप से पता चलेगा कि क्या चलाना है ..

@Scellow @PRIMETSS मुझे सहमत होना है

यह अभी भी एक मुद्दा कैसे है? इसके लिए छत के माध्यम से मांग की जा रही है।

ज़िप में जोड़ के साथ इस अलग फ़ोल्डर के लिए हाँ, एक बिन में और दो फ़ाइलें हैं, exe और बिन। आसान वितरण।

एक और +1 को फिर से खोलने के लिए और एक सुविधा के रूप में।

मैं उम्मीद कर रहा था कि आत्म-निहित तैनाती आत्म-निहित थी और मुझे यहाँ अपना रास्ता मिल गया। मैं यह भी देखना चाहूंगा।

कोई कैसे कह सकता है कि यह सिर्फ एक कॉस्मेटिक मुद्दा है? (केवल फ्रेमवर्क डेवलपर्स ...)
कोई भी उपकरण के बारे में नहीं सोचा जो स्थापित नहीं हैं? (.NET हल dll-hell, और .net कोर इसे वापस लाता है)

मैं बस इतना चाहता हूं कि मेरा कमांड लाइन टूल आत्मनिर्भर हो।

यह बुरा है, वास्तव में बुरा है!

+1

+1 मैंने बस .net कोर रनटाइम के बिना एक क्लस्टर पर एज़्योर बैच में कस्टम गतिविधि चलाने की कोशिश की है और यह "स्व-निहित" संस्करण बनाने वाली फ़ाइलों की उच्च संख्या को संभाल नहीं सकता है।

Total size of resourceFiles cannot be more than 32768 characters

यह एक आधिकारिक समाधान नहीं है, लेकिन यह उपयोगी हो सकता है। मैं ताना का लेखक हूँ, एक उपकरण है जो आपको स्व-निहित एकल द्विआधारी अनुप्रयोग बनाने की अनुमति देता है: https://github.com/dgiagio/vp

मुझे लगता है कि ताना मूल रूप से हर कोई यहाँ खोज रहा है! यह एक एकल exe फ़ाइल की क्षमता के बारे में है, जो भी पृष्ठभूमि में हो, अधिक कुछ नहीं। NuGet पैकेज के बारे में सोचें: यह एक एकल .nuget फ़ाइल है और यह है; यह एक फ़ाइल पैकेजिंग अन्य फ़ाइलों की तुलना में अधिक जटिल नहीं है।

ताना एक घिनौना समाधान है, यह वह नहीं है जो हम चाहते हैं

हम क्या चाहते हैं:

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

और यह उत्पादन:

App.exe
runtime/

या बेहतर जैसे जीओ / जंग आदि

App.exe

बाकी सब कुछ नहीं चाहता है

Warp एक App.exe का उत्पादन करता है ... यह कैसे हैक किया जाता है? जाहिर है कि यह फ्रेमवर्क का हिस्सा नहीं है, लेकिन "वन एक्स फाइल" लक्ष्य को प्राप्त करता है।

यह मेरा मतलब है, यह डिफ़ॉल्ट व्यवहार होना चाहिए, 3 पार्टी समाधान का उपयोग नहीं करना चाहिए (मुझे लगता है)

ताना एक इलाज का काम करता है। आपके काम के लिए धन्यवाद @dgiagio!

+1

मैं किसी प्रकार की एकल-फ़ाइल संग्रह देखना बहुत पसंद करता हूं जो निष्पादन योग्य और सभी निर्भरताओं को बंडल करता है। देशी को शामिल करने की जरूरत नहीं है - मुझे लगता है कि सिस्टम पर डॉटनेट कोर की आवश्यकता पूरी तरह से ठीक है। जावा की जार फ़ाइलों के समान कुछ। एक डार फाइल?

कुछ इस तरह:
डॉटनेट प्रकाशित - स्वयं निहित
डॉटनेट रन - स्व-निहित MyApp.dar

ऐसा लगता है कि अब इसके लिए एक प्रस्ताव है: https://github.com/dotnet/designs/pull/52/files?short_path=28dba55

यहाँ ट्रैकिंग मुद्दा है: https://github.com/dotnet/coreclr/issues/20287

इसके अलावा, @shanselman के पास ताना समाधान पर एक ब्लॉग पोस्ट है:

https://www.hanselman.com/blog/BrainstormingCreatingASmallSingleSelfcontainExecutableOutOfANETCoreApplication.aspx

मैंने प्रस्ताव पढ़ा और मैंने यह देखा:

यह मेरे दिमाग में नहीं है, यह एक धीमी प्रक्रिया की तरह लगता है, मूल रूप से बस सब कुछ zipping ..
हालांकि मैं सभी कोड एक ही निष्पादन योग्य / dll में विलीन हो जाऊंगा? या शायद मैं प्रस्ताव में कुछ याद किया?

@RUSshy क्या आप सभी प्रबंधित कोड के मूल-संकलन के बारे में पूछ रहे हैं और एक निष्पादन योग्य (कोरआरटी ​​के रूप में) पाने के लिए सब कुछ एक साथ जोड़ रहे हैं? यह .Net कोर में वर्तमान एकल-फ़ाइल कार्य के लिए एक लक्ष्य नहीं है।

हालांकि, डिस्क निष्कर्षण और स्टार्टअप समय को कम करने के लिए प्रस्तावित समाधान हैं (उदा: बंडल से सीधे कुछ फ़ाइल प्रकार लोड करें, निकाले गए फ़ाइलों का पुन: उपयोग करें )। एकल-फ़ाइल समाधान के विकास के चरणों का वर्णन यहां किया गया

CC: @JffschwMSFT

फ़ाइलों को निकालने की आवश्यकता क्यों है? हम ILMerge के साथ .NET में इसे प्राप्त करते थे।

@ फिलिप-हैडन, जैसा कि यहां वर्णित

ILMerge , IL को कई असेंबली से एक में जोड़ता है, लेकिन इस प्रक्रिया में, मर्ज की गई असेंबली की मूल पहचान खो देता है। इसलिए, मूल विधानसभा नामों के आधार पर प्रतिबिंब का उपयोग करने जैसी चीजें विफल हो जाएंगी। यदि वे इस परिवर्तन को सहन कर सकते हैं, तब भी ऐप ILMerge का उपयोग कर सकते हैं।

CoreRT कुछ और है, आपके .NET कोड का AOT संकलन, यह दिलचस्प लग रहा है, लेकिन अभी तक तैयार नहीं है (काश MS इस पर ध्यान केंद्रित करता, और अधिक संसाधन आवंटित करता। यह वही है जो लोग चाहते हैं, और वे GO पर क्यों चले गए )

वैसे भी, मेरे पास विस्तार के बारे में बात करने के लिए तकनीकी ज्ञान नहीं है, लेकिन उपयोग का मामला है:

एक एकल आत्म-निष्पादन योग्य प्रकाशित करें, और बस, कुछ भी नहीं निकाला, कुछ भी नहीं निकाला गया, कोई उपरि नहीं, बस निष्पादन योग्य

@ स्वारूप-श्रीधर क्या आपके पास लिनक्स पर डॉटनेट कोर के लिए काम करने का एक उदाहरण है? https://github.com/dotnet/ILMerge/blob/master/ILMerge/ILMerge.csproj#L13 के अनुसार यह एक विंडोज़ / मोनो केवल परियोजना है।

@thefringeninja ILMerge एक विंडोज़ टूल है, मैं ILMerge को अन्य प्लेटफॉर्म पर पोर्ट करने की किसी योजना के बारे में नहीं जानता।
सिंगल-फ़ाइल समाधान को क्रॉस-प्लेटफ़ॉर्म लागू किया जाएगा। यह विकास की प्रक्रिया में है।

@ कारेलज़
तैनाती के लिए तैनात!अगर 1-3 या कम की तरह एक या अधिक फ़ाइलें Thats के लिए बेहतर होगा Deploy (Inlcude पब्लिश, अपडेट)!

CoreRT AOT है
लेकिन ppl एओटी चाहते हैं?
परियोजना (CoreRT) हमेशा पढ़ने के लिए नहीं (इसका उपयोग 2014 से)। अब 2019 है! ( लगभग 5 वर्ष )
क्या एक अनमोल भाषा के लिए एक कीमती 5 साल!अगली रिलीज के लिए भी कोई योजना नहीं CoreRT !!!पीपीएल को और 5 साल तक इंतजार करने दें?

@ स्वर-श्रीधर यह दुर्भाग्यपूर्ण है। ILMerge / ILRepack पुस्तकालय डेवलपर्स के लिए हीरे की निर्भरता की समस्या से बचने के लिए बहुत अच्छा है।

.NET Core 3.0 में इसका समर्थन करने की योजना है - @richlander आपको स्टेटस पर अपडेट कर सकता है।
इसका उल्लेख .NET कोर 3.0 ब्लॉग पोस्टों में किया गया है - जैसे यहाँ: https://devblogs.microsoft.com/dotnet/net-core-3-and-support-for-windows-desktop-applications/ "साइड-बाय-" में पक्ष और अनुप्रयोग-स्थानीय परिनियोजन "अनुभाग।
इसे भी पढ़ें: https://www.hanselman.com/blog/BrainstormingCreatingASmallSingleSelfcontainExecutableOutOfANETCoreApplication.aspx

.net को छोटे एकल स्व-निहित निष्पादन योग्य उत्पादन करने के लिए इन सभी हैक की आवश्यकता नहीं होनी चाहिए .. यह डिफ़ॉल्ट व्यवहार होना चाहिए, आपको जीओ द्वारा खाया जाता है, जंग भी आ रही है, CoreRT या ILMerge पर ध्यान केंद्रित करें, .net कोर ऐप पहले से ही हैं। लोड करने के लिए सभी फ़ाइलों के कारण शुरू करने के लिए लंबे समय, प्रस्ताव में उल्लिखित की तरह ज़िप / अनज़िप के साथ इसे और अधिक जोड़ना नहीं है, यह जाने का तरीका नहीं है

.net को छोटे एकल स्व-निहित निष्पादन योग्य उत्पादन करने के लिए इन सभी हैक की आवश्यकता नहीं होनी चाहिए .. यह डिफ़ॉल्ट व्यवहार होना चाहिए, आपको जीओ द्वारा खाया जाता है, जंग भी आ रही है, CoreRT या ILMerge पर ध्यान केंद्रित करें, .net कोर ऐप पहले से ही हैं। लोड करने के लिए सभी फ़ाइलों के कारण शुरू करने के लिए लंबे समय, प्रस्ताव में उल्लिखित की तरह ज़िप / अनज़िप के साथ इसे और अधिक जोड़ना नहीं है, यह जाने का तरीका नहीं है

जैसा कि आप चाहते हैं। नेट को जीवित रहने की आवश्यकता नहीं है, क्योंकि पीपीएल में जावा है।
गो या रस्ट या डलांग सिंगल एक्ज़ीक्यूटिव प्रोग्राम को बिल्ड टारगेट का समर्थन नहीं करना चाहिए, क्योंकि उनके पास बकवास ज़िप / अनज़िप है!

@ रूषी

.net को छोटे एकल स्व-निष्पादन योग्य उत्पादन करने के लिए इन सभी हैक्स की आवश्यकता नहीं होनी चाहिए

माना। उसी समय, .NET अन्य भाषाओं पर कुछ सुविधाएँ प्रदान करता है जो एक स्थैतिक लिंकर की आवश्यकताओं के साथ सामंजस्य स्थापित करने के लिए चुनौतीपूर्ण हैं (उदाहरण के लिए, फ्लाई कोड पीढ़ी, प्रतिबिंब, डेटा बाइंडिंग आदि पर)। हमने इन विशेषताओं को उन परिदृश्यों में शामिल करने के लिए प्रयोग किया है, जहाँ एकल फ़ाइल / स्थैतिक लिंकिंग महत्वपूर्ण है। हमने ग्राहक प्रतिक्रिया से सीखा है कि इसका परिणाम .NET जैसा नहीं लगता है, आंशिक रूप से क्योंकि पुस्तकालयों की संख्या आप पारिस्थितिक तंत्र से अत्यधिक गिरावट का उपभोग कर सकते हैं।

तो एक लिंकर को ठीक से करना जो उन विशेषताओं की निष्ठा से समझौता नहीं करता है जिन्हें हमने .NET में एक निर्भरता और प्रेम के रूप में लिया है, एक कठिन समस्या है। इसे हल करने के भाग के रूप में, हम विभिन्न दृष्टिकोणों के साथ प्रयोग कर रहे हैं। आप इस हैक को कहते हैं, मैं इस खुले दिमाग और बॉक्स के बाहर सोचने के लिए तैयार हूं। लेकिन सिर्फ आंख मूंदकर .NET को गो / रस्ट / C ++ में बदलना सही जवाब नहीं है।

हमने इन विशेषताओं को उन परिदृश्यों में शामिल करने के लिए प्रयोग किया है, जहाँ एकल फ़ाइल / स्थैतिक लिंकिंग महत्वपूर्ण है। हमने ग्राहक प्रतिक्रिया से सीखा है कि इसका परिणाम .NET जैसा नहीं लगता है, आंशिक रूप से क्योंकि पुस्तकालयों की संख्या आप पारिस्थितिक तंत्र से अत्यधिक गिरावट का उपभोग कर सकते हैं।

क्या टीम ने नेट विकास और विवश वातावरण के लिए .net का एक अलग संस्करण बनाने के बारे में सोचा है, जैसे कि जेटब्रेन्स ने कोटलिन जेवीएम / कोटलिन NATIVE के साथ किया था?

जैसा कि आपने कहा कि प्रत्येक उपयोग के मामलों में .net फिट होने की कोशिश करना सबसे आसान विकल्प नहीं है, इसलिए एक विशिष्ट स्वाद इस समस्या का सही जवाब हो सकता है

और tbh, afaik, यह समस्या वास्तव में पहले से मौजूद नहीं है .net कोर क्योंकि हर विंडोज़ इंस्टाल में पहले से ही .net फ्रेमवर्क है, इसलिए आपको केवल अपने कुछ KBs exe को वितरित करना था, और मुझे जो गुस्सा आता है, वह इस तरह के बारे में सोचा नहीं है। मुद्दा जब डिजाइन .net कोर जो मूल रूप से .net फ्रेमवर्क का पुनर्लेखन था .. यही कारण है कि मैं कह रहा हूं कि इन विकल्पों का उल्लेख सादे हैक हैं, वे यहां डिजाइन गलतियों को ठीक करने के लिए हैं

Https://github.com/dotnet/designs/blob/master/accepted/single-file/staging.md पढ़ने के बाद प्रस्ताव के लिए और अधिक कदम होने लगते हैं, और यह zip / unzip पर समाप्त नहीं होता है, इसलिए ऐसा नहीं है एक हारी हुई लड़ाई, उम्मीद है कि टीम कुछ हल्का लाने में सक्षम होगी, जिसका उल्लेख उस दस्तावेज़ में किया गया है, अच्छा है!

इस तरह की चीजें विंडोज एक खिलौना ओएस क्यों बनी हुई हैं।

@kjkrum जैसी बातें क्या?

@ यह तब है जब लोग कहते हैं कि वे नहीं जानते कि वे क्या कर रहे हैं।

@ क्रिउ थ्रू जैसी चीजें एक स्टैंडअलोन निष्पादन योग्य बनाने में सक्षम नहीं हैं, और ऐसा करने के लिए बहुत वास्तविक जरूरत से बेखबर बर्खास्तगी। अस्तित्व में बहुत अधिक हर दूसरी निर्माण प्रणाली न केवल एक सांख्यिकीय रूप से जुड़े निष्पादन योग्य का निर्माण करेगी, यह निर्भरता के अप्रयुक्त भागों को छीन लेगी। स्ट्रिपिंग निर्भरता कम से कम एक दशक के लिए एक मानक विशेषता रही है; संकलक के आविष्कार के बाद से स्थिर लिंकिंग।

@ क्रिउ थ्रू जैसी चीजें एक स्टैंडअलोन निष्पादन योग्य बनाने में सक्षम नहीं हैं, और ऐसा करने के लिए बहुत वास्तविक जरूरत से बेखबर बर्खास्तगी। अस्तित्व में बहुत अधिक हर दूसरी निर्माण प्रणाली न केवल एक सांख्यिकीय रूप से जुड़े निष्पादन योग्य का निर्माण करेगी, यह निर्भरता के अप्रयुक्त भागों को छीन लेगी। स्ट्रिपिंग निर्भरता कम से कम एक दशक के लिए एक मानक विशेषता रही है; संकलक के आविष्कार के बाद से स्थिर लिंकिंग।

सहमत, यह वास्तव में ऑपरेटिंग सिस्टम में सी # कार्यक्रमों की स्थिति से संबंधित है।
C # प्रोग्राम हमेशा एक प्रथम श्रेणी का नागरिक नहीं बन सकता है।केवल द्वितीय श्रेणी का होना चाहिए।

इसका समाधान किया जाता है।
TLDR: dotnet publish -r win10-x64 /p:PublishSingleFile=true

विवरण:
https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0#single -file-execables
https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md

इसका समाधान किया जाता है।
TLDR: dotnet publish -r win10-x64 /p:PublishSingleFile=true

विवरण:
https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0#single -file-execables
https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md

डॉटनेट-कोर के किस संस्करण में यह सुविधा जोड़ी गई थी? मैं 3.0.100-preview5-011568 का उपयोग कर रहा हूं और मुझे यह त्रुटि मिली है:
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: वास्तव में यह काम कर रहा है, ऐसा लगता है कि केवल https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md में एक वाक्यविन्यास त्रुटि है जो dotnet publish -r win10-x64 --self-contained /p:PublishSingleFile=true साथ प्रकाशित करने वाले राज्यों में है। --self-contained जोड़ने के बिना है।

थैंक्स @mihaimyh मैं डिजाइन डॉक में टाइपो को ठीक करूंगा।

हमेशा एकल exe स्वयं निहित सुविधा के लिए zip / unzip समाधान का उपयोग करने के खिलाफ im।
क्योंकि यह अगले मुद्दे का कारण होगा।
एकल exe फ़ाइल का आकार कैसे कम करें!

वास्तव में, शुरू से ही समान तरीकों से आईएल-मर्ज का उपयोग करना चाहिए।

बहस नहीं होनी चाहिए, यह समय बर्बाद है, किसी ने भी जिप के लिए नहीं कहा / पूरी बात को अनजिप कर दिया, और फिर भी वे इस डिजाइन के साथ आए और अपना समय और हमारा समय बर्बाद किया

लोग एकल निष्पादन योग्य और एओटी के लिए पूछते हैं, हमारा समय बर्बाद करना बंद करें Microsoft

मैं स्पष्ट रूप से एओटी के बिना एकल-फ़ाइल चाहता हूं। मैं जेआईटी की क्षमता को पसंद करता हूं ताकि मैं प्रतिबिंब, जेनेरिक और रनटाइम-जनरेटेड कोड का उपयोग कर सकूं।

मुझे लगता है कि एमएस सुनना नहीं चाहता, ठीक है

हमेशा एकल exe स्वयं निहित सुविधा के लिए zip / unzip समाधान का उपयोग करने के खिलाफ im।
क्योंकि यह अगले मुद्दे का कारण होगा।
एकल exe फ़ाइल का आकार कैसे कम करें!

यकीन नहीं होता कि मैं समझ गया हूं, जैसे कि इसका Zipped पहले से ही संकुचित था। या क्या आप निरर्थक निर्भरताओं की कमी और इसलिए संपीड़न से पहले आकार कम कर रहे हैं?

नकारात्मकता को न समझना। Ive त्वरित परीक्षण के अलावा अभी तक इसका इस्तेमाल नहीं किया। लेकिन लगता है कि एकल निष्पादन योग्य स्थिति क्लाइंट के लिए एक ऐप को तैनात करने या सीएलआई उपकरण के रूप में अच्छी तरह से काम करती है। जहां मुझे विश्वास है कि यह सुविधा उपयोगी है। उस के बाहर, देव या अन्य वातावरण में मुझे इसके लिए उपयोग का मामला नहीं दिखता है, इसलिए उन्होंने जो किया है वह एक समाधान के रूप में ठीक काम करता है ..

@ रूषी

मुझे लगता है कि एमएस सुनना नहीं चाहता, ठीक है

इसके विपरीत, वे उपयोग के मामलों की एक विस्तृत श्रृंखला के लिए पूछ रहे हैं और एकत्र कर रहे हैं जिसे आप संबंधित थ्रेड्स में देख सकते हैं। आपकी राय महत्वपूर्ण है, लेकिन समुदाय के अन्य लोगों की राय उतनी ही महत्वपूर्ण है और आपको उन्हें सुनने के लिए Microsoft का मजाक नहीं उड़ाना चाहिए।

आपके कथन के आधार पर मुझे लगता है कि आपने मुझे Microsoft के लिए गलत समझा होगा। मैं अपने जैसा एक सामुदायिक सदस्य हूं जो किसी भी क्षमता में Microsoft के लिए नहीं बोलता।

हमेशा एकल exe स्वयं निहित सुविधा के लिए zip / unzip समाधान का उपयोग करने के खिलाफ im।
क्योंकि यह अगले मुद्दे का कारण होगा।
एकल exe फ़ाइल का आकार कैसे कम करें!

यकीन नहीं होता कि मैं समझ गया हूं, जैसे कि इसका Zipped पहले से ही संकुचित था। या क्या आप निरर्थक निर्भरताओं की कमी और इसलिए संपीड़न से पहले आकार कम कर रहे हैं?

अगर आप WebApi या MVC या कंसोल का उपयोग करते हैं, तो एक HelloWorld लिखें! उर अच्छी तरह से पता है कि मेरा क्या मतलब है।
पैक्ड फ़ाइल बहुत बड़ी है। यह बहुत अधिक कोड लाती है लेकिन कभी भी निष्पादित नहीं होगी।
यदि IL-Merge तरीके अप्रयुक्त कोड शाखा को कम कर देंगे।

हां, मुझे यकीन है कि मैंने हैलोवर्ल्ड को सांत्वना दी है और हां इसका 68K को यकीन है

कोई भी आत्म निहित 67K नहीं था
लेकिन इसकी C # विधानसभा नहीं है। अगर मुझे एक <1K HelloWorld चाहिए था तो c # का उपयोग क्यों करें?
बड़े ऐप फ्रेमवर्क का अधिक उपयोग करते हैं, इसलिए एक बिंदु पर फ्रेमवर्क की तुलना में अधिक कस्टम कोड है।
क्या हम वास्तव में कुछ 100K के बारे में चिंतित हैं? यदि ऐसा है, तो एक रूपरेखा का उपयोग न करें और खरोंच से सब कुछ लिखने में समय व्यतीत करें ??
मुझे यहां क्या समझ नहीं आ रहा है?

हमेशा एकल exe स्वयं निहित सुविधा के लिए zip / unzip समाधान का उपयोग करने के खिलाफ im।
क्योंकि यह अगले मुद्दे का कारण होगा।
एकल exe फ़ाइल का आकार कैसे कम करें!
अगर आप WebApi या MVC या कंसोल का उपयोग करते हैं, तो एक HelloWorld लिखें! उर अच्छी तरह से पता है कि मेरा क्या मतलब है।
पैक्ड फ़ाइल बहुत बड़ी है। यह बहुत अधिक कोड लाती है लेकिन कभी भी निष्पादित नहीं होगी।
यदि IL-Merge तरीके अप्रयुक्त कोड शाखा को कम कर देंगे।

@ यहां दो अलग मुद्दे हैं:

• ऐप के लिए कोड कैसे कम करें?
• ऐप को सिंगल फाइल में कैसे पैकेज करें?

कोड-कटौती के लिए, आगे कई तकनीकें हैं

• मर्जिंग IL: यह सभी ऐप्स के लिए नहीं है, क्योंकि यह प्रक्रिया में असेंबली पहचान खो देता है। यह मौजूदा एकल-निर्गमन कार्य के लिए एक लक्ष्य नहीं है।
• अप्रयुक्त आईएल को ट्रिम करना: ILLinker का उद्देश्य अप्रयुक्त आईएल को ट्रिम करना है। यह सुविधा डॉटनेट एसडीके ( PublishTrimmed संपत्ति) में एकीकृत है, और ILLinker में अधिक अनुकूलन विकास के अधीन हैं।
• ज़िप / अनज़िप: डॉटनेट प्रकाशन वर्तमान में प्रकाशित एकल फ़ाइल को ज़िप नहीं करता है, लेकिन यह किया जा सकता है।

ऐप को सिंगल फाइल में कैसे पैकेज करें?
डॉटनेट प्रकाशन एकल फ़ाइल में प्रकाशन का समर्थन करता है - प्रकाशित फ़ाइल उतनी ही बड़ी होगी जितनी कि ऐप अन्यथा होगी।

जनरेटिंग कोड के बारे में:

• वर्तमान में देशी कोड तैयार करने के लिए समर्थन रेडी-टू-रन कंपाइलर ( PublishReadyToRun संपत्ति) के माध्यम से है।
• एओटी संकलन के माध्यम से प्रकाशन महान है (

हां, मुझे यकीन है कि मैंने हैलोवर्ल्ड को सांत्वना दी है और हां इसका 68K को यकीन है

कोई भी आत्म निहित 67K नहीं था
लेकिन इसकी C # विधानसभा नहीं है। अगर मुझे एक <1K HelloWorld चाहिए था तो c # का उपयोग क्यों करें?
बड़े ऐप फ्रेमवर्क का अधिक उपयोग करते हैं, इसलिए एक बिंदु पर फ्रेमवर्क की तुलना में अधिक कस्टम कोड है।
क्या हम वास्तव में कुछ 100K के बारे में चिंतित हैं? यदि ऐसा है, तो एक रूपरेखा का उपयोग न करें और खरोंच से सब कुछ लिखने में समय व्यतीत करें ??
मुझे यहां क्या समझ नहीं आ रहा है?

खेद के रूप में उर img दिखाया गया है, स्वयं contianed.Thats 68626KB के साथ, इसके बारे में 68mb = 68KK, न केवल 68K !!!
हमें <1kb की आवश्यकता नहीं है (स्वयं के साथ यह असंभव है), <3000KB ठीक है, स्वीकार करें।
लेकिन 68mb ज्यादा 30X + है
यू वोंट हमेशा सिर्फ एक हैलोवर्ल्ड प्रोग्राम लिखें !!!

क्षमायाचना, देर रात गलती K के साथ
अतिरिक्त स्पष्टीकरण / जानकारी स्वरूप-श्रीधर के लिए धन्यवाद, कुछ नए स्विच, जिनके बारे में मुझे जानकारी नहीं थी।
बस निम्नलिखित स्विच के साथ 3.preview 6 के साथ की कोशिश की

डॉटनेट पब्लिश -r RID / p: PublishTrimmed = true / p: पब्लिशिंगसाइलफाइल = सच
और अब 29,000K तक नीचे

निश्चित रूप से सभी ऐप हैलो वर्ल्ड नहीं होंगे, लेकिन C # Core SelfContain App के लिए, जिसमें रनटाइम भी शामिल है ... व्यक्तिगत रूप से Im को चिंता नहीं है। यकीन है कि अगर मैं अपने लेखन एक छोटे से सांत्वना उपकरण यह 3K है अच्छा होगा। लेकिन पहली जगह में इसके लिए C # का उपयोग क्यों करें?
दिलचस्प चर्चा हालांकि दोस्तों!

30mb LOL, मुझे कॉल करें जब यह 1-3mb जैसा कुछ होगा, रनटाइम ब्लोट से भरा होता है, GO को चेक करें, लोग तरंग में माइग्रेट करते हैं

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

यहां तक ​​कि कोटलिन को भी शेयर मिलना शुरू हो जाता है, और कोटलिन मूल निवासी के साथ शर्म की बात है

और स्विफ्ट विंडोज़ पर आ रहा है https://forums.swift.org/t/swift-win32-programming/20686

तो यहाँ कुछ सुझाव हैं:

• प्रतिबिंब हटाने के लिए विकल्प जोड़ें
• JIT सामान हटाने के लिए विकल्प जोड़ें
• बेहतर C # कोड का अनुकूलन करें ताकि आप JIT पर भरोसा न करें

30mb LOL, मुझे कॉल करें जब यह 1-3mb जैसा कुछ होगा, रनटाइम ब्लोट से भरा होता है, GO को चेक करें, लोग तरंग में माइग्रेट करते हैं

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

यहां तक ​​कि कोटलिन को भी शेयर मिलना शुरू हो जाता है, और कोटलिन मूल निवासी के साथ शर्म की बात है

और स्विफ्ट विंडोज़ पर आ रहा है https://forums.swift.org/t/swift-win32-programming/20686

तो यहाँ कुछ सुझाव हैं:

• प्रतिबिंब हटाने के लिए विकल्प जोड़ें
• JIT सामान हटाने के लिए विकल्प जोड़ें
• बेहतर C # कोड का अनुकूलन करें ताकि आप JIT पर भरोसा न करें

मुझे लगता है कि यह उचित नहीं है। .NET को सबसे छोटी सिंगल फाइल कंसोल एप्लिकेशन के निर्माण के लिए नहीं बनाया गया था। हम इसका उपयोग Asp.Net वेबसाइटों और एपिस के लिए करते हैं। इसलिए, ढांचा अपने आप में टन टन के अतिरिक्त सुविधाओं के साथ लाता है जिसमें आप नगेट पैकेज शामिल कर सकते हैं। मैं सोच भी नहीं सकता कि अगर कोई वेब एप्लिकेशन 50 या कई सैकड़ों मेगाबाइट आकार का है तो चिंता का विषय है। प्राथमिक चिंता गति, स्मृति उपयोग और दीर्घकालिक स्थिरता में है। सर्वर पर आकार के बारे में कौन परवाह करता है।

यदि आपका एकमात्र इरादा छोटे एकल एमबी आकार के कंसोल एप्लिकेशन का निर्माण करना है, तो नौकरी के लिए सही उपकरण का उपयोग क्यों न करें। शिकायत करने के बजाय कि एक एकल फ़ाइल में पैक किए गए पूर्ण रुपरेखा के साथ एक अनुप्रयोग एक "हैलो दुनिया" के लिए भी आकार में कई दसियों मेगाबाइट है, उदाहरण के लिए रस्ट के साथ क्यों नहीं?

Microsoft अपनी शुरुआत से लेकर अभी तक और पिछले कुछ वर्षों में .NET के साथ बहुत अच्छा काम कर रहा है, इसलिए इसके लिए आपको धन्यवाद।

ऐसी गैर-समझ, झूठ और दक्षता की भावना की कमी का क्या जवाब दें?

आप यह महसूस करने में विफल रहते हैं कि .net कोर दिशा कितनी गलत थी, और केवल हाल ही में उन्होंने वितरण / IL मर्ज / AOT पर काम करके इसे महसूस करना शुरू किया

और अब वेब-असेंबली वैगन पर जाने के लिए वे नहीं कर सकते हैं क्योंकि .net रनटाइम इतना बड़ा ब्लोट है कि वे सभ्य आकार की फाइलों को तैनात करने में असमर्थ हैं

और आप अभी भी "कौन सर्वर पर आकार के बारे में परवाह करता है" के साथ फंस गया है, इस तरह की सोच ने "आधुनिक माना जाता है" बनाया है। पहले से ही पुराने और अप्रासंगिक तकनीकी स्टैक में .net कोर

Microsoft .net के साथ बहुत अच्छा काम नहीं कर रहा है, वे असफल हो गए क्योंकि वे पुराने लोगों को .net फ्रेमवर्क संगतता के लिए खुश करना चाहते थे, यह उनकी गलती में से एक था।

क्षमा करें अगर मैं असभ्य लगता हूं लेकिन कभी-कभी आपको बदलाव करने की आवश्यकता होती है

माफ करना, अगर मैं असभ्य लगता हूं लेकिन

आप अशिष्ट ध्वनि करते हैं, अवधि। यह, और आपकी बर्खास्तगी और निष्कर्ष पर कूदना, प्रेरक होने का प्रभाव नहीं है।

क्षमायाचना, देर रात गलती K के साथ
अतिरिक्त स्पष्टीकरण / जानकारी स्वरूप-श्रीधर के लिए धन्यवाद, कुछ नए स्विच, जिनके बारे में मुझे जानकारी नहीं थी।
बस निम्नलिखित स्विच के साथ 3.preview 6 के साथ की कोशिश की

डॉटनेट पब्लिश -r RID / p: PublishTrimmed = true / p: पब्लिशिंगसाइलफाइल = सच
और अब 29,000K तक नीचे

निश्चित रूप से सभी ऐप हैलो वर्ल्ड नहीं होंगे, लेकिन C # Core SelfContain App के लिए, जिसमें रनटाइम भी शामिल है ... व्यक्तिगत रूप से Im को चिंता नहीं है। यकीन है कि अगर मैं अपने लेखन एक छोटे से सांत्वना उपकरण यह 3K है अच्छा होगा। लेकिन पहली जगह में इसके लिए C # का उपयोग क्यों करें?
दिलचस्प चर्चा हालांकि दोस्तों!

आधुनिक भाषा के रूप में दुनिया को एकजुट करने के लिए थोड़ी महत्वाकांक्षा नहीं होनी चाहिए?
क्या आप चाहते हैं कि सभी डेवलपर्स C ++ के लिए सी # बैक होम लिखें? या उन्हें गो, कोटलिन, स्विफ्ट में धकेल दें?
बाजार में हिस्सेदारी और आगे # ग?

.Net क्योंकि क्रॉस-प्लेटफ़ॉर्म लागू नहीं होता है महान विकास के अवसर के पहले 15+ वर्षों से चूक गए।
लेकिन अब .net सही तरीके से वापस आ गया है।

हाँ जैसा कि मैंने Im से पहले टिप्पणी की कि निगेटिविटी क्यों नहीं है।
अगर आप फुल फ्रेमवर्क से आ रहे हैं तो नेट कोर कुछ भी शानदार नहीं है। और .Net मानक + कोर समामेलन दृष्टि मुझे लगता है कि समझदार और प्रगतिशील है।

.NET को GO या किसी अन्य भाषा / फ्रेमवर्क से तुलना करना व्यर्थ है।
वैसे भी, इस विषय पर Im बाहर, जैसा कि मुझे लगता है कि वे जिस समाधान पर काम कर रहे हैं और एकल .exe के लिए सुधार कर रहे हैं, उसने कई सालों पहले से मेरे 'पूछ' को काफी अच्छी तरह से हल कर दिया है ... मेरे लिए बहुत अच्छा है, और मेरी तत्काल आवश्यकताओं के अनुरूप है।

तो धन्यवाद दोस्तों और लड़कियों!

बाहर

मैं इस आचार संहिता के बारे में सभी को याद दिलाना चाहूंगा।

असहमत होना या अलग-अलग राय रखना ठीक है, लेकिन कृपया, हम सभ्य रहें और चलिए इसे तकनीकी चर्चा के रूप में व्यक्त करते हैं। मजबूत शब्दों का उपयोग करने की आवश्यकता नहीं है।
इसके अलावा, विचारों को लक्षित करना, आपकी राय के साथ कार्यान्वयन उचित खेल है। फिर भी, यह उनके पीछे लोगों पर हमला करने के लिए स्वीकार्य नहीं है। कृपया सभी एक-दूसरे के प्रति सम्मानजनक रहें, विभिन्न रायों को सुनें और मजबूत बयानों और आपत्तिजनक टिप्पणियों से परहेज करें।

इसके अलावा, मैं हर किसी को अन्य दृश्य बिंदुओं और राय के लिए खुले रहने के लिए कहना चाहता हूं। निर्णय लेने से पहले, दूसरे पक्ष को सुनने के लिए आम तौर पर अच्छा होता है - अक्सर इसके पीछे एक कहानी होती है कि चीजें जिस तरह से होती हैं। विचारों और समाधानों को देखकर जब कोई जानता है कि वे जिस तरह से हैं वह आम तौर पर अधिक उत्पादक है।

धन्यवाद!

हमेशा एकल exe स्वयं निहित सुविधा के लिए zip / unzip समाधान का उपयोग करने के खिलाफ im।
क्योंकि यह अगले मुद्दे का कारण होगा।
एकल exe फ़ाइल का आकार कैसे कम करें!
अगर आप WebApi या MVC या कंसोल का उपयोग करते हैं, तो एक HelloWorld लिखें! उर अच्छी तरह से पता है कि मेरा क्या मतलब है।
पैक्ड फ़ाइल बहुत बड़ी है। यह बहुत अधिक कोड लाती है लेकिन कभी भी निष्पादित नहीं होगी।
यदि IL-Merge तरीके अप्रयुक्त कोड शाखा को कम कर देंगे।

@ यहां दो अलग मुद्दे हैं:

• ऐप के लिए कोड कैसे कम करें?
• ऐप को सिंगल फाइल में कैसे पैकेज करें?

कोड-कटौती के लिए, आगे कई तकनीकें हैं

• मर्जिंग IL: यह सभी ऐप्स के लिए नहीं है, क्योंकि यह प्रक्रिया में असेंबली पहचान खो देता है। यह मौजूदा एकल-निर्गमन कार्य के लिए एक लक्ष्य नहीं है।
• अप्रयुक्त आईएल को ट्रिम करना: ILLinker का उद्देश्य अप्रयुक्त आईएल को ट्रिम करना है। यह सुविधा डॉटनेट एसडीके ( PublishTrimmed संपत्ति) में एकीकृत है, और ILLinker में अधिक अनुकूलन विकास के अधीन हैं।
• ज़िप / अनज़िप: डॉटनेट प्रकाशन वर्तमान में प्रकाशित एकल फ़ाइल को ज़िप नहीं करता है, लेकिन यह किया जा सकता है।

ऐप को सिंगल फाइल में कैसे पैकेज करें?
डॉटनेट प्रकाशन एकल फ़ाइल में प्रकाशन का समर्थन करता है - प्रकाशित फ़ाइल उतनी ही बड़ी होगी जितनी कि ऐप अन्यथा होगी।

जनरेटिंग कोड के बारे में:

• वर्तमान में देशी कोड तैयार करने के लिए समर्थन रेडी-टू-रन कंपाइलर ( PublishReadyToRun संपत्ति) के माध्यम से है।
• एओटी संकलन के माध्यम से प्रकाशन महान है (

जैसा कि डायनामिक मर्ज देशी-डीएलएल को एक नाम पसंद है: XXX.exe (अनवांटेड)।
देशी डीएलएलएस (अनमैन्डेड) फंक्शन-लेवल लिंकिंग को संकलित करने के लिए विश्लेषण के लिए स्थैतिक विश्लेषण का उपयोग करना।

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

यदि अच्छा काम करते हैं तो परिणाम 2-3l होगा। जब im सीधे उन सभी को 7zip के साथ पैक करता है, तो इसके बारे में 4.85mb.Now हमें XXX.exe मिलता है

IL- मर्ज के साथ समान फ़ंक्शन-स्तर लिंक विकसित करें।
एक प्रबंधित DLL के लिए फिर से वही पुरानी चाल।
अंतिम एम्बेड में DL.exe PE.exe अनुभाग (.net अनुभाग के रूप में चिह्न) के रूप में प्रबंधित किया गया।

प्रतिबिंब के लिए, प्रतिबिंब प्रकार के डीएलएल का विश्लेषण करें। मेटाडाटा और प्रतिबिंब के प्रकार (फ़ंक्शन सहित) और उसके पेड़ के सभी - आश्रित बनाए रखें।

मैं माफी माँगता हूँ, मैं इस बारे में चर्चा में भाग लेने के लिए और अधिक समय नहीं लेना चाहता। किसी भी अन्य को एकीकृत नहीं किया जा सकता है।
पहले मुझे परिणाम की उम्मीद थी। लेकिन अब, मैं शायद अन्य प्रोग्रामिंग भाषाओं मेरी जरूरतों (शायद Dlang शायद जाओ शायद Kotlin शायद निम या शायद जंग सबसे अच्छा है) को पूरा करने के विचार करना चाहिए।

मेरे साथ यह बात करने के लिए धन्यवाद। मेरी नैगिंग के लिए खेद है। बाहर

@sgf मुझे लगता है कि आपने कुछ अच्छे अंक बनाए हैं और मुझे पता है कि आपने इस विषय पर हस्ताक्षर कर दिए हैं। बस यह कहना चाहता था कि मुझे विश्वास है कि आप जो सुविधाएँ माँग रहे हैं, वे अगले दो वर्षों में .NET कोर पर आ जाएँगी। वास्तव में यदि आप आज छोटे फ़ाइल आकार प्राप्त करना चाहते हैं, तो यह संभव हो सकता है यदि आप मोनो को लक्षित करते हैं।

1. मोनो पहले से ही फ़ाइल आकार को कम करने के लिए लिंक के साथ एओटी संकलन का समर्थन करता है। यह एक कारण है कि मोनो को ब्राउज़र के लिए चुना गया था। नेट रनटाइम कार्यान्वयन। https://www.mono-project.com/docs/advanced/aot/ और मेरा मानना ​​है कि ब्लेज़र परियोजनाओं में एक लिंकर हो सकता है।

2. Microsoft ने घोषित किया है कि वे अपने .NET रनटाइम्स को एक "सभी शक्तिशाली" एक में समेकित करना चाहते हैं। कुछ चीजों के लिए मोनो और दूसरों के लिए .NET कोर के बजाय, वे एक एकल रनटाइम चाहते हैं जो सभी परिदृश्यों पर वितरित कर सके। इस डिफैक्टो का मतलब है कि इसे एओटी और लिंकिंग / कोड स्ट्रिपिंग आदि का समर्थन करने की आवश्यकता होगी। इसलिए मुझे अगले कुछ वर्षों में उम्मीद है कि या तो .NET कोर रनटाइम इन सुविधाओं को प्राप्त करने के लिए, या मोनो और .NET कोर सुविधाओं को एक नए में समेकित करने के लिए। रनटाइम।

अगर किसी को बेहतर पता है, तो कृपया मुझे सूचित करें।

+ 2 ¢

मुझे लगता है कि समस्या यह है कि लगता है कि निर्णय बिना अधिक जानकारी के किए जा रहे हैं। इन दिनों हर जगह मुझे लगता है कि लोग इस बारे में बात कर रहे हैं; कार्यक्रमों की तैनाती करने वाले अधिकांश लोगों के पास उनकी इच्छा सूची के शीर्ष पर है, और कई बेहतर एओटी / तैनाती के साथ सी # से अन्य भाषाओं से दूर जा रहे हैं । मुझे लगता है कि यह एक बहुत स्थापित तथ्य है जो समुदाय में सक्रिय होने पर बहुत स्पष्ट हो जाता है। फिर भी यह निर्णयों को थोड़ा भी प्रभावित नहीं करता है।

बात यह है, ऐसा लगता है कि कोई नहीं जानता कि यह वास्तव में किस हद तक महत्वपूर्ण है। मेरे लिए व्यक्तिगत रूप से यह अत्यंत महत्वपूर्ण है, इसलिए निश्चित रूप से मैं बहुत पक्षपाती हूं, लेकिन मुझे जो धारणा है वह यह है कि कुल मिलाकर यह प्रमुख महत्व का है और ऐसा लगता है कि एमएस केवल यह ध्यान नहीं दे रहा है कि यह बहुत योग्य है, जिससे हम बहुत प्रभावित हुए। वे एकसमान निर्णय ले रहे हैं जो बदले में हमें एक पूरे के रूप में प्रौद्योगिकी के भविष्य के बारे में आश्वस्त नहीं करता है।

मैं @RUSshy से सहमत हूं। CoreRT एक अविश्वसनीय परियोजना है और निश्चित रूप से सही दिशा में जा रही है, लेकिन कुल मिलाकर ऐसा लगता है कि सभी प्रयास सर्वर / वेब प्रौद्योगिकियों पर केंद्रित हैं। रनटाइम्स, जेट्स और बड़े बायनेरिज़ जैसी चीजें उस संबंध में खुद के लिए बोलती हैं। सॉफ्टवेयर की तैनाती करने वाला कोई भी व्यक्ति उन चीजों को नहीं चाहता है।

कहा जा रहा है कि मैं व्यक्तिगत रूप से अभी भी तकनीक का उपयोग कर रहा हूं, हालांकि मैं वास्तव में कुछ क्षेत्रों में इसके भविष्य के बारे में सांस नहीं ले रहा हूं।

मैं इस दिशा में समुदाय से अधिक भागीदारी देखना चाहूंगा, भले ही यह पता चले कि मैं व्यक्तिगत रूप से इसकी अपेक्षा कर रहा हूं। लेकिन अब तक ऐसा लगता है कि निर्णय को ध्यान में रखते हुए निर्णय किए जा रहे हैं। ऐसा लगता है कि सर्वर / वेब वह है जो पैसा कमाता है और प्रोग्राम को तैनात करने वाले लोग एक नगण्य अल्पसंख्यक हैं (कम से कम मुनाफे के मामले में), लेकिन अगर ऐसा है तो मैं कम से कम यह जानना चाहता हूं कि वे अपने फैसले किस आधार पर ले रहे हैं ( बहुत संभावना है), क्योंकि बाहर से ऐसा लगता है कि वे एक सिक्का उछाल रहे हैं।

@ एलन-एफजीआर

लेकिन अब तक ऐसा लगता है कि निर्णय को ध्यान में रखते हुए निर्णय किए जा रहे हैं।

क्या आपके पास साझा करने के लिए ऐसे निर्णयों के विशिष्ट उदाहरण हैं, क्योंकि मैं और अधिक जानने के लिए उत्सुक हूं।

मुझे लगता है कि एमएस वर्तमान डॉटनेट कोर रनटाइम की कमियों से बहुत अवगत हैं और इसीलिए वे भविष्य में मोनो रनटाइम के साथ फीचर समानता की तलाश करेंगे।

बस .net कोर 3.0.0 पूर्वावलोकन 6 के लिए जारी किए गए नोट्स देखें:

आज, हम .NET कोर 3.0 पूर्वावलोकन 6 की घोषणा कर रहे हैं। इसमें बेहतर स्टार्टअप के लिए असेंबलियों को संकलित करने, लिंकर और आकार में सुधार के साथ अनुप्रयोगों के अनुकूलन के लिए अपडेट शामिल हैं। हमने ARM64 पर अल्पाइन के लिए नई डॉकर छवियां भी जारी की हैं।

मुझे ऐसा लगता है कि वे इस बात से बहुत अवगत हैं कि कुछ आकारों के लिए आवेदन का आकार महत्वपूर्ण है - विशेषकर अब मिश्रण में ब्लेज़र के साथ।

@ एलन-एफजीआर सहमत, वेब फोकस यह सोचकर अजीब है कि आईआईएस की लगभग 8% बाजार हिस्सेदारी है और गिर रही है। ASP.NET अप्रासंगिक है, और C # या इसके मानक पुस्तकालयों में कोई सुधार कभी भी इसे बदलने वाला नहीं है। कंसोल एप्स, विंडोज सर्विसेज, मोबाइल एप्स, और पीसी गेम्स द्वारा C # कायम रखा जा रहा है। यह एकता और ज़ामरीन के अस्तित्व को जारी रखता है। यह एक शर्म की बात है, क्योंकि C # में विकसित होने के लिए एक बहुत ही सुखद भाषा है। यह लंबे समय से जावा डेवलपर से आने वाली उच्च प्रशंसा है, जो अभी भी सोचते हैं कि माइक्रोसॉफ्ट ने विंडोज एक्सपी के साथ अपने उच्च पानी के निशान को छोड़ दिया है।

जैसा कि डायनामिक मर्ज देशी-डीएलएल को एक नाम पसंद है: XXX.exe (अनवांटेड)।
देशी डीएलएलएस (अनमैन्डेड) फंक्शन-लेवल लिंकिंग को संकलित करने के लिए विश्लेषण के लिए स्थैतिक विश्लेषण का उपयोग करना।

मुझे यकीन नहीं है कि आप गतिशील मर्ज से क्या मतलब है, लेकिन मूल रूप से मेजबान के साथ देशी घटकों को जोड़ने की योजना है। कृपया इस अनुभाग को देखें।

IL- मर्ज के साथ समान फ़ंक्शन-स्तर लिंक विकसित करें।
प्रतिबिंब के लिए, प्रतिबिंब प्रकार के डीएलएल का विश्लेषण करें। मेटाडाटा और प्रतिबिंब के प्रकार (फ़ंक्शन सहित) और उसके पेड़ के सभी - आश्रित बनाए रखें।

हमने विधानसभाओं को एक में विलय करने के विकल्प पर चर्चा की है, और गतिशील विशेषताओं का समर्थन करने के लिए मेटा-डेटा तालिकाओं का पक्ष लिया है। यह काफी आकार-बचत प्रदान करता है। लेकिन इसे लागू करने की लागत काफी अधिक है - नए मेटा-डेटा समर्थन के कारण, और इसे संभालने के लिए डिबगर / प्रोफाइलर आदि में आवश्यक परिवर्तन।

द्विआधारी आकार को कम करने के लिए कुछ अन्य विकल्प हैं - उदाहरण के लिए, जब हम सीधे एक एकल-फ़ाइल को निष्पादित करने में सक्षम होते हैं (फ़ाइलों को निकालने के बिना), हम प्रत्येक DLL के पक्ष में हस्ताक्षर / प्रमाण पत्र छोड़ सकते हैं एक पूरे के रूप में एप्लिकेशन पर हस्ताक्षर। यह कभी-कभी कुछ MB बचा सकता है।

लेकिन अब तक ऐसा लगता है कि निर्णय को ध्यान में रखते हुए निर्णय किए जा रहे हैं।

क्या आपके पास साझा करने के लिए ऐसे निर्णयों के विशिष्ट उदाहरण हैं, क्योंकि मैं और अधिक जानने के लिए उत्सुक हूं।

मुझे लगता है कि एमएस वर्तमान डॉटनेट कोर रनटाइम की कमियों से बहुत अवगत हैं और इसीलिए वे भविष्य में मोनो रनटाइम के साथ फीचर समानता की तलाश करेंगे।

@dazinator मुझे लगता है कि बहुत तथ्य यह है कि एमएस किसी भी तरह से सोचता है कि मोनो किसी भी चीज के लिए एक सभ्य समाधान है यह दिखाने के लिए कि वे वास्तव में अपने उत्पादों को नहीं जानते हैं। मैंने मोनो का उपयोग किया है, और जब यह तकनीक का एक महत्वपूर्ण टुकड़ा है और .NET को काफी लोकप्रिय बनाने में मदद की है, तो निश्चित रूप से इसमें कुछ गुणवत्ता की कमी है ... ज़मारिन ने अपनी तकनीक को बढ़ावा देने के लिए कुछ महान विपणन कार्य किए, लेकिन यह ओवर-होनहार और अंडर-आधारित था वितरित करना, और ऐसा लगता है कि जो कोई भी एमएस में उन निर्णयों को ले रहा है, उन्होंने अपनी कुछ प्रोमो सामग्री देखी और वास्तव में कभी भी तकनीक का इस्तेमाल नहीं किया। दूसरी ओर CoreRT एक ऐसी तकनीक है, जो अब तक मेरे लिए बहुत अधिक है। यह मेरी राय में गुणवत्ता के एक और स्तर पर है, और फिर भी यह एमएस द्वारा कुछ तकनीक के पक्ष में उपेक्षित किया जा रहा है कि मुझे संदेह है कि मैं बतख टेप के साथ एक साथ आयोजित किया जाता है।

सहमत हैं, वेब फोकस यह देखते हुए अजीब है कि IIS में लगभग 8% बाजार हिस्सेदारी और गिरावट है। ASP.NET अप्रासंगिक है, और C # या इसके मानक पुस्तकालयों में कोई सुधार कभी भी इसे बदलने वाला नहीं है। कंसोल एप्स, विंडोज सर्विसेज, मोबाइल एप्स, और पीसी गेम्स द्वारा C # कायम रखा जा रहा है।

@kjkrum की बात है। हालांकि, शायद उनके लिए वेब पर 8% बाजार हिस्सेदारी अभी भी विंडोज और मोबाइल ऐप की तुलना में अधिक महत्वपूर्ण है। बहुत कम से कम विंडोज़ सर्वर की बिक्री में अच्छी वेब तकनीकें मदद करती हैं, इसलिए उस पर उनकी रुचि काफी स्पष्ट है, लेकिन इस पर इतना ध्यान केंद्रित करना भी एक बहुत उथली रणनीति है और मैं यह मानने से इनकार करता हूं कि उनके फैसले क्या हैं। एमएस डॉटनेट फाउंडेशन के साथ सही दिशा में जा रहा था और इतने सारे होनहार प्रोजेक्ट चल रहे थे, लेकिन ऐसा लगता है कि वे इस अवसर को एक प्रमुख टेक पास होने दे रहे हैं।

मुझे पता है कि यह एक ऐसा अनोखा तरीका है, जो शायद व्यर्थ है, लेकिन मैं सभी लोगों को जानता हूं, जो अपनी परियोजनाओं के लिए C # का उपयोग कर रहे थे (ज्यादातर गेम देव) कुछ और सीमाओं में स्थानांतरित हो गए, जो पूरी तरह से हल करने योग्य थे। वे रुस्त, डी, गो और सी ++ में चले गए। मैं स्वयं नियमित रूप से C ++ का उपयोग करता हूं और मैं Rust सीख रहा हूं, लेकिन मैं अभी भी कुछ व्यक्तिगत परियोजनाओं के लिए C # का उपयोग कर रहा हूं, क्योंकि यह बहुत बेहतर है, भले ही गुणवत्ता वाले उत्पाद को तैनात करना रियर में दर्द हो।

यह एकता और ज़ामरीन के अस्तित्व को जारी रखता है।

हां, कई तकनीकी समस्याओं के कारण क्या आशीर्वाद और एक अभिशाप है। उदाहरण के लिए एकता की बहुत खराब प्रतिष्ठा है, लेकिन सौभाग्य से वह .NET / C # को प्रभावित नहीं करता था।
XNA हालाँकि, हालांकि अभी भी एकदम सही है लेकिन उपयोगकर्ताओं और डेवलपर्स के बीच एक अविश्वसनीय रूप से बहुत अच्छी प्रतिष्ठा है।

आज .NET कोर 3.0 के साथ इस भूमि को देखकर खुशी हुई। धन्यवाद दोस्तों! 👍

मुझे यकीन नहीं है कि लोग क्या चाहते हैं, अगर हम साधारण कैलकुलेटर के साथ समाप्त होते हैं जो 141mb exe है, तो सुविधा एक विफलता है (और मेरा मानना ​​है कि वास्तविक लागत 141mb * 2 है, क्योंकि यह कहीं सामान निकालने वाला है)

हां, यह निश्चित रूप से मैं चाहता हूं। यह अभी भी एक नियमित रूप से स्व-निहित तैनाती से छोटा है।

अधिक आक्रामक विधानसभा ट्रिमिंग और ट्री-शेकिंग का स्वागत किया जाएगा, लेकिन यह एक बहुत ही उपयोगी शुरुआत है। वृद्धिशील सुधार मूल्य देने का सबसे चतुर तरीका है।

ओह, यह आप क्या चाहते हैं? मेरा बुरा, मुझे नहीं पता था कि फूला हुआ आवेदन लोकप्रिय था

एक कैलकुलेटर को जेआईटी की जरूरत नहीं है, यहां तक ​​कि प्रतिबिंब भी नहीं, लेकिन जब से आप चाहते हैं, मुझे लगता है कि मैं शुरुआत से ही गलत हूं, मुझे प्रोग्रामिंग बंद कर देना चाहिए

@ रूस यह किसी भी अन्य आत्म निहित तैनाती की तुलना में अधिक फूला हुआ नहीं है, है ना?

जेआईटी को हटाने और प्रतिबिंब से स्वतंत्र है कि क्या सब कुछ एक ही exe में पैक किया गया है। यानी आप जेआईटी को हटा सकते हैं और सिंगल-एक्स के बिना परावर्तन कर सकते हैं, और आप जेआईटी और प्रतिबिंब को हटाए बिना सिंगल-एक्स कर सकते हैं। वे काम के अलग-अलग टुकड़े हैं।

मुझे यकीन नहीं है कि लोग क्या चाहते हैं, अगर हम साधारण कैलकुलेटर के साथ समाप्त होते हैं जो 141mb exe है, तो सुविधा एक विफलता है (और मेरा मानना ​​है कि वास्तविक लागत 141mb * 2 है, क्योंकि यह कहीं सामान निकालने वाला है)

इसकी फ़ाइलों को C: उपयोगकर्ता [YourUserName] AppDataLocalTemp.net पर निकालें

क्या कोई ऐसा तरीका है जिससे सिंगल एक्सपेक्ट किया जा सकेगा?
जब मैं / var / .... में निकालने का प्रयास करता हूं, तो मैं समस्या में भाग गया, जहां उपयोगकर्ता के पास लिखने की कोई अनुमति नहीं है।

@eiva यह कौन सा ओएस था? क्या यह AWS लंबा था?
https://github.com/dotnet/core-setup/issues/7940 इस समस्या को ठीक करने वाले ट्रैक।

इस बीच, आप यह नियंत्रित करने के लिए DOTNET_BUNDLE_EXTRACT_BASE_DIR वातावरण चर सेट कर सकते हैं जहां बंडल की गई फ़ाइलों को निकाला जाता है।

@ स्वर-श्रीधर उत्तर के लिए धन्यवाद!
यह "प्रतिबंधित" सेवा खाते से सेंटो.7 लॉन्चिंग ऐप है।

@ jnm2 मैं सराहना करता हूं कि आप C # से प्यार करते हैं, मैं भी करता हूं। लेकिन ईमानदार होने दें, यह पागलपन है कि एक कैलकुलेटर 128 मेगाबाइट है।

@TechnikEmpire मुझे यह इंगित करना आवश्यक लगता है कि "I love C #" जो मैंने ऊपर कहा है उसकी बहुत गहन कमी है: D

मैं व्यक्तिगत रूप से पूरी तरह से संतुष्ट महसूस नहीं करने जा रहा हूं जब तक कि मैं अपने स्वयं के कोड और libs के ट्री-शेकिंग करने की क्षमता रखता हूं, तृतीय पक्ष के लिबास, और .NET स्वयं को संदर्भित करता हूं। लेकिन यह आज मेरे लिए किसी भी कम मूल्यवान सुविधा को नहीं बनाता है। यह एक आयाम के साथ एक कदम है। ट्री-शेकिंग एक स्वतंत्र आयाम है और मुझे उम्मीद है कि इस पर बहुत ध्यान दिया जाएगा।