Runtime: एकल-फ़ाइल वितरण का समर्थन करें

दिलचस्प बात यह है कि इस पहल की तुलना CoreRT से कैसे की जाती है? वे समान प्रयासों की तरह लगते हैं?

क्या यह ' संभवतः मूल उपयोगकर्ता कोड ' से संबंधित है, यानी यह अभी भी कोड को जेआईटी-संकलित करने की अनुमति देगा, न कि केवल एओटी?

साथ ही, मुझे लगता है कि रनटाइम घटक (' मूल कोड (रनटाइम, होस्ट, ढांचे के मूल भाग .. ') CoreCLR रेपो से होंगे?

आप बहुत अच्छे प्रश्न पूछ रहे हैं, लेकिन चूंकि यह अभी भी डिजाइन में शुरुआती है, मेरे पास अभी तक अच्छे उत्तर नहीं हैं।

दिलचस्प बात यह है कि इस पहल की तुलना CoreRT से कैसे की जाती है? वे समान प्रयासों की तरह लगते हैं?

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

क्या यह 'संभवतः मूल उपयोगकर्ता कोड' से संबंधित है, यानी यह अभी भी कोड को जेआईटी-संकलित करने की अनुमति देगा, न कि केवल एओटी?

"मूल उपयोगकर्ता कोड" से मेरा मतलब था कि आपके ऐप में कुछ सी ++ मूल कोड हो सकता है (या तो आपके द्वारा या किसी तृतीय-पक्ष घटक द्वारा लिखित)। हम उस कोड के साथ क्या कर सकते हैं, इस पर सीमाएं हो सकती हैं - यदि इसे .dll में संकलित किया जाता है, तो इसे चलाने का एकमात्र तरीका डिस्क से बाहर है; अगर यह एक .lib है, तो इसे लिंक करना संभव हो सकता है, लेकिन इससे अन्य जटिलताएं आती हैं।

साथ ही, मुझे लगता है कि रनटाइम घटक ('मूल कोड (रनटाइम, होस्ट, ढांचे के मूल भाग ..') CoreCLR रेपो से होंगे?

ऊपर दी गई हर चीज के आधार पर, हम यह पता लगाएंगे कि कौन से रेपो शामिल हैं। "ढांचे के मूल भाग" में CoreFX मूल फ़ाइलें जैसे ClrCompression और Unix PAL शामिल होंगी।

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

कुछ परिदृश्य जो हमारे लिए रुचिकर हैं। क्रॉस प्लेटफॉर्म के संदर्भ में यह कैसे काम करेगा?
मुझे लगता है कि हमारे पास प्रति प्लेटफॉर्म एक अलग "फाइल" होगी?

मूल कोड के संबंध में, मैं मंच के आधार पर विभिन्न मूल घटकों का चयन कैसे कर पाऊंगा?

कुछ परिदृश्य जो हमारे लिए रुचिकर हैं। क्रॉस प्लेटफॉर्म के संदर्भ में यह कैसे काम करेगा?
मुझे लगता है कि हमारे पास प्रति प्लेटफॉर्म एक अलग "फाइल" होगी?
मूल कोड के संबंध में, मैं मंच के आधार पर विभिन्न मूल घटकों का चयन कैसे कर पाऊंगा?

@ayende , मैं @morganbr टिप्पणी से उद्धृत कर रहा हूं:

एक संभावित डिज़ाइन एक .NET कोर स्व-निहित एप्लिकेशन में सभी फ़ाइलों को अनिवार्य रूप से एक फ़ाइल में संयोजित करना हो सकता है।

स्व-निहित अनुप्रयोगों के लिए वर्तमान क्रॉस-प्लेटफ़ॉर्म कहानी प्रति प्लेटफ़ॉर्म एक परिनियोजन पैकेज बना रही है जिसे आप लक्षित करना चाहते हैं, क्योंकि आप एप्लिकेशन को रनटाइम के साथ शिप करते हैं, जो एक प्लेटफ़ॉर्म-विशिष्ट है।

@morganbr मैं इस तरह के विस्तृत उत्तर देने के लिए समय निकालने के लिए आपकी सराहना करता हूं

मुझे यह देखने में दिलचस्पी होगी कि डिज़ाइन कहाँ जाता है, यह वास्तव में एक दिलचस्प पहल है

मेरे पास उन लोगों के लिए कुछ प्रश्न हैं जो सिंगल-फाइल का उपयोग करना चाहते हैं। आपके उत्तर हमें अपने विकल्पों को सीमित करने में मदद करेंगे:

1. आप किस प्रकार के ऐप के साथ इसका उपयोग करने की संभावना रखते हैं? (उदाहरण के लिए विंडोज़ पर डब्ल्यूपीएफ? एएसपी.नेट एक लिनक्स डॉकर कंटेनर में? कुछ और?)
2. क्या आपके ऐप में (गैर-.NET) C++/मूल कोड शामिल है?
3. क्या आपका ऐप प्लगइन्स या अन्य बाहरी डीएलएस लोड करेगा जिन्हें आपने मूल रूप से अपने ऐप बिल्ड में शामिल नहीं किया था?
4. क्या आप सुरक्षा सुधारों को शामिल करने के लिए अपने ऐप का पुनर्निर्माण और पुनर्वितरण करने के इच्छुक हैं?
5. यदि आपका ऐप 200-500 ms अधिक धीमी गति से शुरू होता है तो क्या आप इसका उपयोग करेंगे? 5 सेकंड के बारे में क्या?
6. आप अपने ऐप के लिए स्वीकार्य सबसे बड़ा आकार क्या मानेंगे? 5 एमबी? 10? 20? 50? 75? 100?
7. क्या आप आकार और/या स्टार्टअप समय को अनुकूलित करने के लिए एक लंबा रिलीज़ बिल्ड समय स्वीकार करेंगे? आप सबसे लंबे समय तक क्या स्वीकार करेंगे? 15 सेकंड? 30 सेकंड? 1 मिनट? 5 मिनट?
8. क्या आप अतिरिक्त काम करने के इच्छुक होंगे यदि यह आपके ऐप के आकार को आधा कर देगा?

1. सभी प्लेटफॉर्म पर कंसोल/यूआई ऐप।
2. शायद तीसरे पक्ष के घटक के रूप में।
3. शायद हाँ।
4. हां, खासकर अगर एक साधारण क्लिकऑन जैसी प्रणाली है।
5. कुछ शुरुआती मंदी को सहन किया जा सकता है। क्या बिंदु 3 इसमें मदद कर सकता है?
6. संपत्ति पर निर्भर करता है। हैलो वर्ल्ड का साइज एमबी के ऑर्डर पर होना चाहिए।
7. कोई फर्क नहीं पड़ता अगर यह सिर्फ उत्पादन है।
8. प्रतिबिंब सामग्री को श्वेतसूची में डालना पसंद है? हां।

@morganbr , क्या आपको लगता है कि ये प्रश्न व्यापक दर्शकों से बेहतर तरीके से पूछे जाते हैं; यानी, व्यापक रूप से जो लोग इस गिटहब मुद्दे के बारे में जानते हैं?

उदाहरण के लिए, एक संभावित डिज़ाइन एक .NET कोर स्व-निहित एप्लिकेशन में सभी फ़ाइलों को अनिवार्य रूप से एक फ़ाइल में संयोजित करने के लिए हो सकता है।

इसे संकुचित करके देख रहे हैं; या फ़ाइल में संपीड़ित फ़ाइल सिस्टम का उपयोग कर रहे हैं?

@tpetrina , धन्यवाद! बिंदु 3 में कुछ डिज़ाइन कोण शामिल हैं:

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

@TheBlueSky , हमने अन्य लोगों से भी संपर्क किया है, लेकिन यह GitHub समुदाय के भावुक लोगों से इनपुट प्राप्त करने में मदद करता है।

@benaadams , संपीड़न मेज पर है, लेकिन मैं वर्तमान में इसे समग्र डिजाइन के लिए ऑर्थोगोनल के रूप में सोच रहा हूं। हल्के प्रयोग से पता चलता है कि स्टार्टअप समय (और निर्माण समय) के कई सेकंड की लागत पर ज़िपिंग को लगभग 50% आकार में कमी मिल सकती है। मेरे लिए, यह एक कट्टरपंथी पर्याप्त व्यापार-बंद है कि अगर हम ऐसा करते हैं, तो यह वैकल्पिक होना चाहिए।

@morganbr संपीड़न का उपयोग करते समय स्टार्टअप समय के कई सेकंड? मुझे यह विश्वास करना मुश्किल लगता है कि यूपीएक्स का दावा है कि डीकंप्रेसन गति

प्राचीन पेंटियम 133 पर ~10 एमबी/सेकंड, एथलॉन XP 2000+ पर ~200 एमबी/सेकंड।

@morganbr , मेरे लिए उत्तर हैं:

1) सेवा (मूल रूप से Kestrel चलाने वाला कंसोल ऐप)। विंडोज सर्विस/लिनक्स डेमॉन या डॉकटर के रूप में चल रहा है।
2) हाँ
3) हां, आमतौर पर प्रबंधित असेंबली AssemblyContext.LoadFrom का उपयोग करके। ये अंतिम उपयोगकर्ता द्वारा प्रदान किए जाते हैं।
4) हाँ, यह अपेक्षित है। वास्तव में, हम पहले से ही पूरे ढांचे को बंडल कर चुके हैं, इसलिए उस परिप्रेक्ष्य से कोई बदलाव नहीं आया है।
5) एक सेवा के रूप में, हम स्टार्टअप समय के लिए इतना अधिक परवाह नहीं करते हैं। 5 सेकंड उचित होगा।
6) 75 एमबी शायद सीमा है। बहुत कुछ वास्तविक संपीड़ित आकार पर निर्भर करता है, क्योंकि सभी पैकेज संपीड़ित वितरित किए जाते हैं।
7) रिलीज बिल्ड के लिए, लंबे समय तक (यहां तक ​​​​कि अधिक लंबा) निर्माण समय स्वीकार्य है।
8) हाँ, बिल्कुल। आकार इतना मायने नहीं रखता, लेकिन छोटा बेहतर है।

कुछ ऐसा जो मैंने नहीं देखा और जो बहुत महत्वपूर्ण है वह है इसकी डिबगेबिलिटी।
मुझे आशा है कि यह स्टैक ट्रेस को उलझाने वाला नहीं है, और हम pdb फ़ाइलों या किसी प्रकार के डिबगिंग प्रतीकों को शामिल करने में सक्षम होना चाहते हैं।

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

धन्यवाद, @ayende! आप सही कह रहे हैं कि मुझे डिबगेबिलिटी को कॉल करना चाहिए था। मुझे लगता है कि डिबगिंग को प्रभावित करने के कुछ ही मामूली तरीके हैं:

1. एकल-फ़ाइल पर संपादित करें और जारी रखें का उपयोग करना संभव नहीं हो सकता है (मूल असेंबली के पुनर्निर्माण और पुनः लोड करने के तरीके की आवश्यकता के कारण)
2. सिंगल-फाइल बिल्ड एक पीडीबी या कुछ अन्य फाइलें उत्पन्न कर सकता है जो आपकी असेंबली के साथ आने वाली डिबगिंग के लिए आवश्यक हैं।
3. यदि कोरआरटी ​​का उपयोग किया जाता है, तो इसमें कुछ डिबगिंग सुविधाएं हो सकती हैं जो समय के साथ भर जाती हैं (विशेषकर लिनक्स/मैक पर)।

जब आप कहते हैं "पीडीबी फाइलें शामिल करें", क्या आप उन _inside_ एकल फ़ाइल या केवल उन्हें उत्पन्न करने की क्षमता चाहते हैं और यदि आपको एकल-फ़ाइल बिल्ड को डीबग करने की आवश्यकता है तो उन पर लटका दें?

1) हमारे लिए कोई मुद्दा नहीं है। E&C यहां प्रासंगिक नहीं है क्योंकि यह केवल वास्तविक परिनियोजन के लिए उपयोग किए जाने की संभावना है, दिन-प्रतिदिन नहीं।
2) आदर्श रूप से, हमारे पास पीडीबी समेत हर चीज के लिए एक फाइल है, एक फाइल नहीं और पीडीबीएस का एक सेट। पहले से ही एम्बेडेड पीडीबी विकल्प है, अगर वह काम करेगा, तो यह बहुत अच्छा होगा।
3) डीबग के बारे में बात करते समय, मैं डीबगर लाइव संलग्न करने के बजाय उत्पादन समय के बारे में अधिक बात कर रहा हूं। अधिक विशेष रूप से, स्टैक ट्रेस जानकारी जिसमें फ़ाइल और लाइन नंबर शामिल हैं, डंप पढ़ते समय प्रतीकों को हल करने में सक्षम होना आदि।

1. मुख्य रूप से सेवाएं लेकिन कुछ UI
2. कुछ करते हैं, लेकिन यह अत्यावश्यक नहीं होगा
3. हां
4. हां
5. कुछ सेकंड ठीक है
6. हमें कोई फर्क नहीं पड़ता। डीएलएल आकार का योग ठीक है
7. आदर्श रूप से नहीं
8. आकार हमारे लिए प्राथमिक महत्व का नहीं है

हमारे लिए एक और सवाल यह है कि क्या आप इसे अलग-अलग घटकों के लिए भी कर पाएंगे (शायद मंचित भी)? उदाहरण के लिए हमारे पास लाइब्रेरी डीएलएस हैं जो बहुत सारी निर्भरताओं का उपयोग करते हैं। अगर हम उन्हें पैकेज कर सकते हैं तो यह संस्करण प्रबंधन आदि के बहुत दर्द को बचाएगा। अगर इन्हें बदले में एक exe में पैक किया जा सकता है जो कि और भी अच्छा होगा?

1. सेवाएं और कुछ यूआई।
2. इस समय नहीं।
3. हां। आदर्श रूप से प्लगइन्स जिन्हें किसी फ़ोल्डर से लोड किया जा सकता है और रनटाइम पर पुनः लोड किया जा सकता है।
4. हां
5. जब तक हम 10-15+ को आगे नहीं बढ़ा रहे हैं तब तक कोई समस्या नहीं है।
6. डीएलएल आकार का योग, या समान।
7. हां। उत्पादन निर्माण समय के लिए वास्तव में कोई समस्या नहीं है जब तक डीबग/परीक्षण निर्माण उचित रूप से तेज़ी से बनाता है।
8. निर्भर करता है, लेकिन विकल्प आसान होगा।

1. सेवा और यूआई।
2. कभी - कभी।
3. हाँ, आमतौर पर।
4. हां।
5. 5 सेकंड से कम समय का होना सबसे अच्छा है।
6. UI 5 सेकंड से कम का है, सेवा कोई मायने नहीं रखती।
7. निर्माण समय महत्वपूर्ण नहीं है, और अनुकूलन प्रभाव सबसे महत्वपूर्ण है।
8. हां।

@tpetrina @ayende @bencyoung @Kosyne @expcat आपने प्रश्न 3 के लिए हां में जवाब दिया ("क्या आपका ऐप प्लगइन्स या अन्य बाहरी डीएलएस लोड करेगा जिन्हें आपने मूल रूप से अपने ऐप बिल्ड में शामिल नहीं किया था?") - क्या आप हमें अपने उपयोग के बारे में और बता सकते हैं मामला?

एकल फ़ाइल वितरण का मुख्य विक्रय बिंदु यह है कि वितरित करने के लिए केवल एक फ़ाइल है। यदि आपके ऐप में अलग-अलग फाइलों में प्लगइन्स हैं, तो एक फ़ाइल वितरण से आपको क्या मूल्य मिलेगा, जिसमें वैसे भी कई फाइलें हैं? "app.exe+plugin1.dll+plugin2.dll" "app.exe+coreclr.dll+clrjit.dll+...+plugin1.dll+plugin2.dll" से बेहतर क्यों है?

app.exe + 300+ dlls - जो कि आज की वर्तमान स्थिति है, वास्तव में अजीब है।
app.exe + 1-5 dll जो आमतौर पर उपयोगकर्ता द्वारा स्वयं परिभाषित किए जाते हैं, बहुत आसान है।

हमारा परिदृश्य यह है कि हम उपयोगकर्ता द्वारा कुछ एक्सटेंशन की अनुमति देते हैं, इसलिए हम आम तौर पर केवल एक exe को तैनात करते हैं और उपयोगकर्ता आवश्यकतानुसार अतिरिक्त कार्यक्षमता जोड़ सकता है।

यह इतना नहीं है कि हम ऐसा करने की योजना बनाते हैं, लेकिन जरूरत पड़ने पर हम ऐसा करने में सक्षम होना चाहते हैं।

@ayende सहमत, हमारे साथ भी।

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

@ayende से सहमत हैं।

जवाबों के लिए आप सबका धन्यवाद! उन लोगों की संख्या के आधार पर जो या तो मूल कोड का उपयोग करेंगे या प्लगइन्स लोड करने की आवश्यकता होगी, हमें लगता है कि सबसे संगत दृष्टिकोण जिसे हम प्रबंधित कर सकते हैं वह शुरू करने के लिए सही जगह है। ऐसा करने के लिए, हम "पैक एंड एक्सट्रैक्ट" दृष्टिकोण के साथ जाएंगे।

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

इस योजना का सबसे पेचीदा विवरण यह है कि फ़ाइलों को कहाँ से निकाला जाए। हमें कई परिदृश्यों को ध्यान में रखना होगा:

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

मुझे लगता है कि हम उन सभी के लिए एक पथ का निर्माण कर सकते हैं जिसमें शामिल हैं:

1. एक प्रसिद्ध आधार निर्देशिका (उदाहरण के लिए विंडोज़ पर %LOCALAPPDATA%\dotnetApps और अन्य ओएस पर उपयोगकर्ता उपयोगकर्ता प्रोफ़ाइल स्थान)
2. एलिवेटेड के लिए एक अलग उपनिर्देशिका
3. आवेदन पहचान (शायद सिर्फ exe नाम)
4. एक संस्करण पहचानकर्ता। संख्या संस्करण शायद उपयोगी है, लेकिन अपर्याप्त है क्योंकि इसमें सटीक निर्भरता संस्करणों को शामिल करने की भी आवश्यकता है। प्रति-बिल्ड गाइड या हैश उपयुक्त हो सकता है।

साथ में, यह कुछ इस तरह दिख सकता है c:\users\username\AppData\Local\dotnetApps\elevated\MyCoolApp\1.0.0.0_abc123\MyCoolApp.dll
(जहां ऐप का नाम MyCoolApp है, इसका वर्जन नंबर 1.0.0.0 है और इसका हैश/गाइड abc123 है और इसे एलिवेटेड लॉन्च किया गया था)।

एक्सट्रैक्टर में फाइलों को एम्बेड करने के लिए भी काम करना होगा। विंडोज़ पर, हम केवल मूल संसाधनों का उपयोग कर सकते हैं, लेकिन लिनक्स और मैक को कस्टम काम की आवश्यकता हो सकती है।

अंत में, इसे होस्ट में समायोजन (निकाले गए फाइलों को खोजने के लिए) और डायग्नोस्टिक्स (डीएसी या अन्य फाइलों को खोजने के लिए) की भी आवश्यकता हो सकती है।

सीसी @ स्वरूप-श्रीधर @jeffschwMSFT @vitek-karas

मुझे ऐसा लगता है कि यह इलाज बीमारी से भी बदतर है। अगर हमें बाहरी निर्देशिकाओं (ओएस में अलग-अलग), अपडेट करना, अनइंस्टॉल करना और इसी तरह से निपटना है, जो इस सुविधा को पहली जगह में रखने के मेरे कारण के सामने उड़ता है (सब कुछ सरल, पोर्टेबल, स्वयं निहित और साफ रखते हुए)।

अगर यह पूरी तरह से इस तरह से होना है, तो मेरी परियोजना के लिए, मैं एक मुख्य निष्पादन योग्य और अनपॅक की गई फ़ाइलों को उस निष्पादन योग्य के साथ निर्देशिका में रहने के लिए पसंद करूंगा, या संभवतः यह तय करने की क्षमता कि वह निर्देशिका कहां जाती है।

हालांकि यह सिर्फ मैं हूं, मैं दूसरों से भी सुनने के लिए उत्सुक हूं।

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

@ कोसिन से सहमत - प्रस्तावित प्रारंभिक समाधान केवल "इंस्टॉलर" को स्वचालित करने लगता है। यदि वह समस्या की सीमा थी जिसे हम एक निष्पादन के साथ हल करने का प्रयास कर रहे हैं तो मुझे लगता है कि हम सभी ने उस स्वचालन को स्वयं ही किया होगा।

एकल निष्पादन प्रस्ताव का मुख्य लक्ष्य एक अप्रबंधित सिस्टम पर निष्पादन योग्य चलाने में सक्षम होना चाहिए। कौन जानता है कि क्या उसके पास किसी भी चुने हुए गंतव्य "इंस्टॉल" निर्देशिका तक लेखन पहुंच है? यह निश्चित रूप से लॉन्च के बाद खुद की कलाकृतियों को नहीं छोड़ना चाहिए (डिफ़ॉल्ट रूप से नहीं)।

उपरोक्त को संतुष्ट करने के लिए मौजूदा प्रस्ताव में एक छोटे से संशोधन के रूप में: क्या हम स्मृति में अनपैक नहीं कर सकते और वहां से भाग नहीं सकते?

बाकी टिप्पणियों से सहमत हैं। किसी अन्य स्थान पर अनज़िप करना कुछ ऐसा है जो _पहले से ही उपलब्ध है।
हमारे पास एक स्वयं निकालने वाला ज़िप हो सकता है जो निकाले गए मूल्यों को काफी आसानी से चलाएगा। यह बहुत सारी चिंताओं का उत्तर नहीं देता है कि यह उत्तर देने के लिए है और स्थापना के लिए सिर्फ एक और नाम है।

फ़ाइल का स्थान महत्वपूर्ण है। उदाहरण के लिए, हमारे मामले में, इसका मतलब होगा:

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

हमारे उपयोगकर्ताओं में से एक को हमारे सॉफ़्टवेयर को एक डीवीडी से चलाने की आवश्यकता है, यह कैसे काम करता है, उस सिस्टम पर जो वास्तव में चलने के लिए एचडी नहीं है।

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

यहां एक और मुद्दा वास्तविक आकार है। यदि यह सिर्फ (प्रभावी रूप से) एक इंस्टॉलर है, तो इसका मतलब है कि हम एमबी के 100 के दशक में एक उचित ऐप के लिए फ़ाइल आकार के बारे में बात कर रहे हैं, नहीं?

ऐसा लगता है कि प्रस्तावित समाधान के निर्माण के लिए (कई यदि कोई हो) सीएलआर परिवर्तन की आवश्यकता नहीं है। उपयोगकर्ता पहले से ही ऐसा समाधान बना सकते हैं। इसे CoreCLR में जोड़ने का कोई मतलब नहीं है। विशेष रूप से, चूंकि इसके लिए उपयोग का मामला काफी संकीर्ण और विशिष्ट है।

@GSPP यह मूल रूप से कुछ ऐसा लगता है जो मैं आज 7z-Extra के साथ कर सकता हूं, मैं मानता हूं कि यदि ऐसा है, तो बेहतर होगा कि _not_ इसे बिल्कुल भी प्राप्त करें।

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

ऐसा लगता है कि मूल रूप से कुछ ऐसा है जो मैं आज 7z-Extra . के साथ कर सकता हूं

आप सही कह रहे हैं कि इस समस्या को हल करने के लिए प्रोग्रामिंग पर्यावरण अज्ञेय समाधानों की संख्या आज भी मौजूद है। कई में से एक और उदाहरण: https://www.boxedapp.com/exe_bundle.html

यहां जोड़ा गया मूल्य डॉटनेट टूलिंग में एकीकरण होगा ताकि गैर-विशेषज्ञ उपयोगकर्ता भी इसे आसानी से कर सकें। जैसा कि आपने बताया है, विशेषज्ञ उपयोगकर्ता मौजूदा उपकरणों को एक साथ जोड़कर आज ऐसा कर सकते हैं।

व्यक्तिगत रूप से, मैं आपसे सहमत हूं कि यह स्पष्ट नहीं है कि हम यहां सही चुनाव कर रहे हैं। कोर टीम के भीतर इस बारे में हमारी काफी चर्चा हुई।

इस पर एक इंटर्न रखना और एक वैश्विक टूल (जिसकी अनुशंसा की जाती है, लेकिन समर्थित नहीं) के साथ आना ठीक वैसा ही होगा, और इसे स्थापित करना भी काफी आसान हो सकता है।

प्रभावी रूप से, हम dotnet publish-single-file के बारे में बात कर रहे हैं और यह दृश्य के पीछे आवश्यक सब कुछ करेगा।

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

ध्यान दें कि जितना मैं इस सुविधा को पसंद करूंगा, मेरे पास ऐसा कुछ नहीं होगा (जिसका अर्थ है कि यह _always_ होने वाला है) जो कि बाहर से भी किया जा सकता है।

मैं एक उच्च स्तरीय प्रश्न पूछना चाहता हूं: सिंगल-फाइल वितरण के इच्छुक ग्राहकों के लिए मुख्य प्रेरणा क्या है?
क्या यह मुख्य रूप से है:

1. पैकेजिंग? यदि हां, तो चाहे समाधान इनबॉक्स हो या कोई तृतीय पक्ष टूल, कौन सी विशेषताएँ सबसे महत्वपूर्ण हैं?
   ए) स्टार्टअप समय (पहले रन से परे)
   बी) गैर-लिखने योग्य वातावरण में चलने की क्षमता
   ग) दौड़ने के बाद फाइलों को पीछे नहीं छोड़ना
   d) इंस्टॉलर चलाने की आवश्यकता नहीं है
   2) प्रदर्शन?
   ए) गति (मूल कोड की स्थिर लिंकिंग, एकाधिक लाइब्रेरी लोड से परहेज, क्रॉस-मॉड्यूल ऑप्टिमाइज़ेशन इत्यादि)
   बी) कोड आकार (केवल एक प्रमाण पत्र की जरूरत है, पेड़ हिलना, आदि)
   3) कोई अन्य?

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

संकलित निष्पादन योग्य होना चाहिए:

• सभी प्रासंगिक निर्भरताओं को पैकेज करें
• कोई निष्पादन कलाकृतियाँ नहीं हैं (कोई डिस्क नहीं लिखता है)

रे @ स्वरूप-श्रीधर मैं हिम्मत करता हूं कि प्रत्येक एप्लिकेशन के पास प्रदर्शन की जरूरतों का अपना अनूठा क्रम होगा और इसलिए मुझे लगता है कि मूल समाधान से निपटने के बाद सबसे अच्छा तरीका कम लटकने वाले फल को चुनना और वहां से जाना है।

@ स्वरूप-श्रीधर मेरे लिए, यह अंतिम उपयोगकर्ता के लिए पैकेजिंग और उपयोग में आसानी के बारे में है।
सिस्टम वाइड स्टफ की स्थापना से निपटने की कोई आवश्यकता नहीं है, बस क्लिक करें और चलाएं।

यह महत्वपूर्ण है क्योंकि हम अपने सॉफ़्टवेयर को एम्बेड करने की अनुमति देते हैं, और एक एकल फ़ाइल एडऑन को प्रबंधित करना बहुत आसान है।

@strich एम्बेड करने की बात एक अच्छी है। हम आमतौर पर माइक्रो सर्विस आर्किटेक्चर में एक घटक के रूप में उपयोग किए जाते हैं, और परिनियोजन ओवरहेड को कम करने से यह आसान हो जाएगा।

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

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

यह कुछ ऐसा है जो मूल में जाना चाहिए, क्योंकि इसे सक्षम करने के लिए इसे रनटाइम में संशोधन की आवश्यकता होगी।
और यह अपने आप में मूल्यवान होगा। और ऐसा कुछ नहीं जो हम वर्तमान में कर सकते हैं।

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

हमारे लिए मुझे यकीन नहीं है कि इन-मेमोरी दृष्टिकोण काम करेगा क्योंकि हम इसे प्लगइन डीएलएस के लिए भी काम करना चाहते हैं (इसलिए प्लगइन छोड़ना भी इसकी सभी निर्भरताओं की बजाय एक फ़ाइल होगी), लेकिन कोई भी प्रगति होगी अच्छा बनो। हमने Fody.Costura को देखा है और यह कुछ सामानों के लिए अच्छा काम करता है लेकिन इसके लिए हमारे पास .NET Core के साथ समस्याएँ हैं।

तो एक अच्छा उदाहरण हैशिकॉर्प के कौंसुल जैसे गो टूल्स के अनुभव को देखना है

एह, कॉन्सल जैसे टूल के लिए आदर्श समाधान कोरर्ट होगा, न कि यह सेल्फ-एक्सट्रैक्ट इम्प्रोवाइजेशन।

@mikedn वह क्यों है? मैं नहीं देखता कि एओटी या जेआईटी संकलन का परिनियोजन पद्धति से क्या लेना-देना है?

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

यही कारण है कि? मैं नहीं देखता कि एओटी या जेआईटी संकलन का परिनियोजन पद्धति से क्या लेना-देना है?

क्योंकि यह आपको वही देता है जो आप चाहते हैं - एक एकल exe फ़ाइल जिसे आप किसी भी मशीन पर छोड़ सकते हैं (ठीक है, उपयुक्त ओएस वाली कोई भी मशीन, यह एक मूल फ़ाइल है) और चलाएं। यह कम संसाधनों का भी उपयोग करता है, जो कि कौंसल जैसे एजेंटों के लिए एक अच्छी बात है। यह गो आपको जो देता है, उसके बराबर है, स्वयं निकालने के समाधान से कहीं अधिक है।

@mikedn मुझे लगता है, लेकिन

1) यह वास्तव में अभी तक एक उत्पादन रूप में मौजूद नहीं है (जहाँ तक मुझे पता है)!
2) हम बहुत सारी गतिशील विशेषताओं का उपयोग करते हैं (IL पीढ़ी, मनमाना प्रतिबिंब)
3) हम अभी भी प्लगइन्स जोड़ने में सक्षम होना चाहते हैं (फिर से आदर्श रूप से संकुचित)

देखिए क्योंकि यह मुद्दा लोगों से यह पूछने का था कि वे क्या चाहते हैं, हम केवल अपनी राय दे रहे हैं! हम इस लाभ को प्राप्त करने के लिए वास्तव में एक अलग रनटाइम मॉडल पर स्विच नहीं करना चाहते हैं। मेरे लिए वे ओर्थोगोनल सरोकार हैं

मैं नहीं देखता कि एओटी या जेआईटी संकलन का परिनियोजन पद्धति से क्या लेना-देना है?

एक जेआईटी के बिना, डिबगिंग कहानी जैसी चीजें काफी अच्छी तरह से प्राप्त करना आसान है। JIT भाग समस्या को कठिन बना देता है, इसलिए आप इसे Go में नहीं पाएंगे। यह इंजीनियरिंग है, इसलिए आप या तो अधिक इंजीनियरों को कठिन समस्या पर फेंक देते हैं और नई जटिलता के साथ जीते हैं, या इसे कहीं और सीमित करते हैं। सेल्फ-एक्सट्रैक्टर इसे कम करने के बारे में है क्योंकि आवश्यक कौशल वाले इंजीनियरों की संख्या सीमित है।

गो प्रोजेक्ट्स (कोई जेआईटी आवश्यकताएं नहीं) जैसी परियोजनाओं वाले लोग कोरआरटी ​​से बहुत खुश हो सकते हैं, अगर वे इस पर "प्रयोगात्मक" लेबल के साथ ठीक हैं। इन दिनों कोशिश करना बहुत आसान है । यह एक ही कचरा संग्रहकर्ता, कोड जनरेटर, CoreFX, और अधिकांश CoreLib को पूर्ण CoreCLR के रूप में उपयोग करता है, और छोटे-ईश निष्पादन योग्य (एकल अंक मेगाबाइट) उत्पन्न करता है जो स्वयं निहित होते हैं।

यह वास्तव में अभी तक एक उत्पादन रूप में मौजूद नहीं है (जहाँ तक मुझे पता है)!

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

हम बहुत सारी गतिशील विशेषताओं का उपयोग करते हैं (IL पीढ़ी, मनमाना प्रतिबिंब)

यह कुछ ऐसा है जिस पर समग्र रूप से समुदाय एक दूसरा विचार करना चाहेगा। निश्चित रूप से ऐसा करने में सक्षम होना उपयोगी है लेकिन यह एकल फ़ाइल परिनियोजन जैसी अन्य इच्छाओं के साथ संघर्ष करता है। आप अभी भी एकल फ़ाइल परिनियोजन प्राप्त कर सकते हैं लेकिन यह लागत पर आता है - एक बड़ी फ़ाइल। अगर आप इसके साथ ठीक हैं तो यह बिल्कुल ठीक है। लेकिन मेरे अनुभव में जितनी बड़ी फ़ाइल उतनी ही कम उपयोगी होती है "एकल फ़ाइल" पहलू बन जाता है।

@MichalStrehovsky यकीन है, अलग-अलग विकल्प हैं। हालाँकि हमारे लिए हम प्रायोगिक का उपयोग नहीं कर सकते (यह मानते हुए कि .NET कोर में जाने का समय काफी कठिन था) और मुझे नहीं लगता कि एक अस्थायी फ़ोल्डर को निकालना हमारे मामले में भी काम करेगा। हालाँकि सबसे खराब स्थिति यह है कि हम जैसे हैं वैसे ही चलते रहते हैं और इस सुविधा का उपयोग नहीं करते हैं।

यह कुछ ऐसा है जो हम चाहेंगे हालांकि अगर यह वैसे ही चला गया जैसा हम चाहते हैं :)

@ मिकेडन मैं सहमत हूं। एकाधिक समानांतर समाधान और भी अधिक भ्रमित करने वाले हैं। मुझे लगता है कि हमारा आदर्श समाधान किसी प्रकार का सुपर ILLinker/बुनकर दृष्टिकोण होगा, लेकिन मुझे इसे खेलने देने और यह देखने में प्रसन्नता हो रही है कि हम कहां समाप्त होते हैं।

मैं इस कार्यक्षमता लैंडिंग के बारे में वास्तव में उत्साहित हूं, लेकिन टीबीएच मैं आपके द्वारा @morganbr पोस्ट किए गए प्रारंभिक प्रस्ताव के बारे में उतना ही उत्साहित नहीं हूं। आपके द्वारा पूछे गए प्रश्नों की सूची के मेरे उत्तर अन्य लोगों द्वारा पोस्ट किए गए समान हैं (इसलिए मुझे लगता है कि क्षमताओं का एक सामान्य वांछित सेट है), लेकिन आईएमएचओ प्रस्तावित 'अनपैक टू डिस्क' समाधान बिल्कुल भी नहीं है जिसे मैं देखना चाहता हूं। लागू किया गया और जैसा कि अन्य ने कहा कि यह लगभग 'बीमारी' से भी बदतर होगा। @jkotas

मैं @strich और @ayende . से सहमत हूं
संकलित निष्पादन योग्य होना चाहिए:
सभी प्रासंगिक निर्भरताओं को पैकेज करें
कोई निष्पादन कलाकृतियाँ नहीं हैं (कोई डिस्क नहीं लिखता है)

डिस्क के बजाय मेमोरी से .dll लोड करना आसान नहीं हो सकता है, लेकिन यह इस तरह की क्षमता है कि IMO MSFT निम्न-स्तरीय देवों (और फिर CoreClr में लीवरेजिंग) की गहरी विशेषज्ञता के लायक होगा, जो उपरोक्त प्रस्ताव के रूप में लागू किया जा सकता है एक बाहरी उपकरण (और पहले से ही है, https://github.com/dgiagio/warp देखें)। यदि यह हासिल किया गया, तो मुझे आश्चर्य है कि पहले और बाद के रनों के बीच कितना समय अंतर होगा? प्रेरणा/उदाहरण के लिए, मुझे लगता है कि लिनक्स 3.17+ में memfd_create है जिसका उपयोग dlopen द्वारा किया जा सकता है।

किसी अन्य विषय पर, मैं सोच रहा हूं कि क्या प्लगइन्स का समर्थन करने की आवश्यकता डिज़ाइन प्रस्ताव को ओवर-इंडेक्स कर रही है? क्या यह इस कार्यक्षमता को ऑप्ट-इन करने के लायक होगा, ताकि केवल जिन लोगों को इस क्षमता की आवश्यकता है, उन्हें संभावित दंड (पेड़ के हिलने की कमी आदि) और बाकी सभी (महत्वपूर्ण बहुमत?) को कम तैनाती योग्य आकार, पूर्ण लाभ (?)

@ स्वरूप-श्रीधर @MichalStrehovsky को पीछे छोड़ते हुए, मैं दो व्यापक उपयोग के मामलों को देख सकता हूं जिनके अलग-अलग लक्ष्य/इच्छाएं हो सकती हैं ताकि सभी को एक समाधान के साथ समायोजित करना मुश्किल हो:

• सीएलआई टूलिंग आदर्श रूप से हर बार तेजी से चलाना चाहता है, छोटे वितरण योग्य; शायद CoreRT के लिए बेहतर फिट?
• JIT और डायनेमिक कोड सुविधाओं जैसी समृद्ध कार्यक्षमता के बदले में microservice शायद लंबे समय तक चलने वाले (आदर्श रूप से <1s), बड़े वितरण योग्य को सहन कर सकता है।

मुझे उम्मीद है कि यह ब्रेनडंप कुछ समझ में आता है, मैं एक झटका बनने की कोशिश नहीं कर रहा हूं, लेकिन सिर्फ प्रतिक्रिया दें क्योंकि मुझे इस विषय में बहुत दिलचस्पी है। आपकी कड़ी मेहनत और सामुदायिक इनपुट के लिए धन्यवाद! :)

प्लगइन्स के बारे में।
मूल रूप से, केवल एक चीज जो मैं चाहूंगा वह है _not_ को Assembly.LoadFrom या LoadLibrary कॉल पर ब्लॉक किया जा रहा है।
मुझे किसी और चीज की जरूरत नहीं है और बाकी मैं खुद कर सकता हूं।

@ayende क्या आप कृपया थोड़ा और विस्तार से बता सकते हैं कि "लोडफ्रॉम पर अवरुद्ध होने और ऐसे" से आपका क्या मतलब है?

उदाहरण के लिए, इसके लिए कुछ सुझावों में CoreRT शामिल था, जिसका अर्थ था कि हम (शायद) केवल एक प्रबंधित dll लोड करने में सक्षम नहीं होंगे।
लेकिन जब तक मैं एक प्रबंधित डीएल के लिए पथ प्रदान कर सकता हूं और एक असेंबली प्राप्त कर सकता हूं या मूल डीएल पर LoadLibrary पर कॉल कर सकता हूं, तो मैं प्लगइन तंत्र होने के साथ ठीक हूं।

मैं यह स्पष्ट करने के लिए कह रहा हूं कि प्लगइन परिदृश्य कुछ ऐसा नहीं है जिसे _विचारित_ होना चाहिए, बल्कि ऐसा कुछ है जो _blockced_ नहीं होना चाहिए।

मैंने कोड में खुदाई करने में कुछ समय बिताया और पहली नज़र में, ऐसा लगता है कि यह _possible_ होना चाहिए (केवल चीजों को सरल बनाने के लिए विंडोज़ के बारे में बोलना):

• संपूर्ण CoreCLR को एक निष्पादन में पैक करें (मान लें कि यह एम्बेडेड संसाधन या ऐसा कुछ है)।
• मूल डीएलएस की गणना करें, उन्हें स्मृति में लोड करने के लिए MemoryModule (https://github.com/fancycode/MemoryModule) जैसे कुछ कॉल करें
• रनटाइम को आमंत्रित करें और मेमोरी से असेंबली लोड करें।

मैं यह मानने जा रहा हूं कि यह _not_ जितना आसान है। उदाहरण के लिए, ICLRRuntimeHost2::ExecuteAssembly इसे बफर देने का कोई तरीका प्रदान नहीं करता है, केवल डिस्क पर एक फ़ाइल है।
यह इसे पहला बनाता है (जो मुझे यकीन है कि कई होंगे) वास्तव में इसे काम करने के लिए स्टॉपर दिखाएं।

मुझे पूरा यकीन है कि बहुत सारे कोड हैं जो संबंधित सामग्री को फाइलों के रूप में संदर्भित कर सकते हैं जो विफल हो सकते हैं, लेकिन इस तरह की चीजें हैं जो मेरा मतलब है जब मैं कहता हूं कि मुझे एक फ़ाइल निष्पादन चाहिए और उस तरह का क्यों ए समाधान CoreCLR में किया जाना चाहिए न कि बाहरी रूप से (ज़िप उदाहरण में)।

मेमोरी मॉड्यूल की तरह कुछ कॉल करें

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

मैं यह मानने जा रहा हूं कि यह इतना आसान नहीं है।

ठीक है, गैर-विस्तारित एकल फ़ाइल बंडल से निष्पादन का समर्थन करने के लिए नए एपीआई (प्रबंधित और अप्रबंधित दोनों) की आवश्यकता होगी। मौजूदा कार्यक्रम और पुस्तकालय "बस काम नहीं करेंगे"।

क्या यह एंटी मालवेयर स्कैन इंटरफ़ेस के लिए एक उचित अनुरोध हो सकता है
मेमोरी मॉड्यूल पर विंडोज इंजीनियरों द्वारा कार्यान्वित किया गया जैसे हाल ही में था
मेम से लोड किए गए सहित सभी .net असेंबली?

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

संपादित करें: हम्म मेमोरी मॉड्यूल देशी मॉड्यूल लोड करने के लिए ओएस में निर्मित कुछ की तरह लग रहा था लेकिन जाहिर है कि ऐसा नहीं है, शायद यह मेरे सुझाव को अनदेखा करने का पर्याप्त कारण है

बुधवार को, 5 दिसंबर, 2018, 01:46 जनवरी कोट्स नोटिफिकेशन @github.com ने लिखा:

मेमोरी मॉड्यूल की तरह कुछ कॉल करें

मेमोरीमॉड्यूल का उपयोग करके लोड किए गए बायनेरिज़ गैर-निदान योग्य हैं (उदाहरण के लिए इनमें से कोई भी नहीं)
नियमित डिबगर्स, प्रोफाइलर, आदि) उन पर काम करेंगे, और मेमोरीमॉड्यूल
सभी निर्मित OS सुरक्षा उपायों (जैसे एंटीवायरस, आदि) को छोड़ देता है। यह नहीं
कुछ हम कभी भी समर्थित समाधान के रूप में जहाज कर सकते हैं।

मैं यह मानने जा रहा हूं कि यह इतना आसान नहीं है।

ठीक है, नए एपीआई की जरूरत होगी (प्रबंधित और अप्रबंधित दोनों)
एक गैर-विस्तारित एकल फ़ाइल बंडल से निष्पादन का समर्थन करें। वर्तमान
कार्यक्रम और पुस्तकालय "बस काम नहीं करेंगे"।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/dotnet/coreclr/issues/20287#issuecomment-444314969 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AEBfudvVHxpbeKa-L_vTQjbnNZZsn6Meks5u1xdlgaJpZM4XK-X_
.

पूरी प्रतिक्रिया के लिए धन्यवाद।
हम शीघ्र ही एकल-फ़ाइल वितरण का समर्थन करने के लिए एक अद्यतन योजना पोस्ट करेंगे।

@NinoFloris देखें dotnet/coreclr#21370

मुझे एहसास है कि मुझे इस चर्चा में देर हो चुकी है इसलिए अगर इससे मदद नहीं मिलती है तो क्षमा करें।

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

कोरआरटी ​​में शानदार रनटाइम के साथ क्यों न रहें और कोरआरटी ​​में एक जेआईटी (और तैयार होने तक दुभाषिया काम पर विस्तार) को शामिल करने पर काम पर ध्यान केंद्रित करें, जो पूर्ण ढांचे की क्षमता चाहते हैं, जबकि उनके लिए अभी भी देशी कोड बनाया गया है? क्या जेआईटी क्षमताएं चाहने के मामले में, मेटाडेटा और जेआईटी को कोरआरटी ​​के अंदर मूल रूप से संकलित निष्पादन योग्य रखना संभव नहीं होगा?
क्या यह सभी दुनियाओं में सर्वश्रेष्ठ नहीं होगा? उदा. आपके पास सबसे छोटे निष्पादन योग्य, सबसे तेज़ स्टार्टअप समय होगा, कोरआरटी ​​में एओटी कोड की सीमाओं को एक जेआईटी रखने के द्वारा विस्तारित किया जा सकता है, और मेटाडेटा और आईएल कोड उन लोगों के लिए रखा जा सकता है जो पूर्ण ढांचे की कार्यक्षमता को बनाए रखना चाहते हैं।
IMO अल्पकालिक कार्यक्षमता के बजाय 'सर्वोत्तम संभव' समाधान पर ध्यान केंद्रित करना चाहिए जो दीर्घकालिक लक्ष्यों से विचलित हो सकता है।

हो सकता है कि मुझसे गलती हुई हो, लेकिन मुझे लगता है कि CoreCLR के हिस्से के रूप में एकल फ़ाइल प्रकाशित होने से ग्राहकों को CoreRT से दूर कर दिया जाएगा, जो कि कई मामलों में उनके लिए संभावित रूप से बेहतर समाधान होगा। उदा. अगर इसे "अब आप अपने .NET कोड को एक फ़ाइल के रूप में प्रकाशित कर सकते हैं" के रूप में ब्रांडेड हो जाता है, फिर भी यह बड़ी फाइलें बना रहा है, स्टार्टअप प्रदर्शन आदि में नुकसान होगा, तो मैं देख सकता हूं कि लोग इस "ब्लोटेड .NET रनटाइम" के बारे में फिर से शिकायत करना शुरू कर देते हैं। . जबकि .NET के पास पहले से ही कोरआरटी ​​में ठीक उसी के लिए एक शानदार समाधान है, जबकि सभी तरह से जाने के लिए आधिकारिक समर्थन/आधिकारिक उत्पाद प्रतिबद्धता की कमी है।

शायद मेरी चिंता ज्यादातर यह है कि मैं कम समानांतर उत्पादों (फिर से @mikedn को उद्धृत करते हुए) देखना चाहता हूं और जो यहां हैं (रोडमैप साझा करने सहित) गहराई से प्रतिबद्ध, विस्तार और समर्थन पर अधिक जोर देना चाहता हूं।

कम समानांतर उत्पाद

हमारे पास सिर्फ एक उत्पाद है: .NET कोर। CoreRT एक अलग उत्पाद नहीं है और कभी नहीं होगा। यह इस एक उत्पाद में विकल्प जोड़ने के बारे में है। आज हमारे पास विकल्पों के कुछ उदाहरण हैं: वर्कस्टेशन जीसी और सर्वर जीसी; स्व-निहित ऐप पब्लिश बनाम फ्रेमवर्क-डिपेंडेंट ऐप पब्लिश।

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

@christianscheuer इस मुद्दे पर और कोरआरटी ​​से संबंधित अन्य मुद्दों पर आपकी प्रतिक्रिया बहुत मूल्यवान रही है। आप इस चर्चा को बिल्कुल भी दूषित नहीं कर रहे हैं।

एक नए उपकरण/विकल्प की बात हो रही है जिसे तब आंतरिक रूप से CoreRT के साथ प्रतिस्पर्धा के रूप में देखा जा सकता है

कोर टीम के बीच, हमने कई अलग, महत्वाकांक्षी या पागल विकल्पों के बारे में बात की है। मैं "अनज़िप टू डिस्क" को CoreRT पूर्ण AOT के साथ एक महत्वपूर्ण प्रतियोगी नहीं मानता। प्रत्येक .NET उपयोगकर्ताओं/ऐप्स के एक अलग खंड को लक्षित करता है।

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

मैं आपसे वादा नहीं कर सकता कि इस समय CoreRT तकनीक समर्थित .NET Core उत्पाद के हिस्से के रूप में कब शिप होगी। मुझे पता है कि इसमें अद्वितीय ताकत है और मुझे यकीन है कि हम उस तरह के महत्वपूर्ण .NET उपयोगकर्ताओं के लिए एक समर्थित समाधान शिप करने जा रहे हैं जो अंततः इससे लाभान्वित होते हैं।

एकल फ़ाइल वितरण समझ में आता है यदि:

• यह स्टार्टअप समय को प्रभावित नहीं करता है (अन्यथा केवल सबसे छोटे एप्लिकेशन ही इसका उपयोग कर पाएंगे)
• यह एक वीएफएस (वर्चुअल फाइल सिस्टम) के रूप में कार्य करता है जो आपको असेंबली और संसाधनों तक पहुंचने की अनुमति देता है जैसे कि वे डिस्क से, एप्लिकेशन फ़ोल्डर से थे)।
• ऐप की "पैचबिलिटी" को प्रभावित नहीं करता है। आईई: माइक्रोसॉफ्ट महत्वपूर्ण असेंबली को पैच करने में सक्षम होना चाहिए, भले ही वे सिस्टम स्तर पर कहीं और ओवरराइड प्रदान करके एम्बेडेड हों।

एम्बेडेड संसाधनों के रूप में असेंबली, एक अस्थायी फ़ोल्डर में निकाले और कॉपी किए गए Microsoft से एक आवश्यक समाधान नहीं है। इसे किसी भी ग्राहक द्वारा आसानी से लागू किया जा सकता है जिसे इसकी आवश्यकता है।

एक "सत्य" एकल फ़ाइल समाधान की आवश्यकता है और यह बहुत अधिक मूल्य प्रदान करेगा।

@jkotas आपकी टिप्पणी मेरे लिए सच है। कोरआरटी ​​पर स्विच करने के लिए मुझे अपनी कंपनी के .NET देव (एलओबी/बैकऑफ़िस/एकीकरण) को समझाने में मुश्किल होगी क्योंकि यह उनके लिए बहुत अधिक छलांग होगी (विशेष रूप से प्रायोगिक लेबल दिया गया है), लेकिन वे मूल्य देख सकते हैं a कोर के लिए अपेक्षाकृत सरल (उपयोग करने के लिए) समाधान जैसे यह धागा चर्चा कर रहा है। धन्यवाद

@ popcatalin81 मैं वास्तव में यहाँ आपकी बातों से दृढ़ता से असहमत हूँ।

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

भले ही हम किसी सेवा के स्टार्टअप समय में 30 सेकंड जोड़ दें, यह वास्तव में सेवाओं के लिए लंबे समय तक सार्थक नहीं है।
उपयोगकर्ता का सामना करने वाले अनुप्रयोगों के लिए, यह संभवतः एक हत्यारा होगा, लेकिन जब तक 3.0 बाहर नहीं हो जाता है, तब तक सभी कोरसीएलआर ऐप्स या तो कंसोल या सेवाएं हैं।

ऐसा नहीं है कि CoreCLR के पास पहले से ही एक ऐसा तरीका है जिसमें आप अपने आवेदन (स्वयं निहित परिनियोजन) के साथ ढांचे को बंडल कर सकते हैं।
हमारे मामले में (RavenDB), हम उस पर कई उद्देश्यों के लिए _rely_ करते हैं। सबसे पहले, हमारे स्वयं के ढांचे को चुनने की क्षमता चाहे जो कुछ भी हमारे उपयोगकर्ता उपयोग कर रहे हों। यह हमारे लिए एक _major_ लाभ है, क्योंकि इसका मतलब है कि हमें विश्व स्तर पर स्थापित ढांचे का उपयोग करने की आवश्यकता नहीं है और इस प्रकार जो कुछ भी व्यवस्थापक ने तय किया है वह ढांचा होगा (हम इस बात को ध्यान में रखते थे कि हम चल रहे होंगे .NET 4.0 कभी-कभी, 4.5 साल बाद भी, उदाहरण के लिए, और वह एक दर्द था)।
एक और महत्वपूर्ण पहलू यह है कि हम फ्रेमवर्क के _our own_ फोर्क के साथ चल सकते हैं। यह बहुत उपयोगी है अगर हम उन चीजों में भाग लेते हैं जिन्हें हमें बदलना चाहिए।

उसके हिस्से के रूप में, हम पैच साइकिल का स्वामित्व लेते हैं और नहीं चाहते कि कोई और उसके साथ खिलवाड़ करे।

मुझे _mind_ VFS नहीं लगता, लेकिन मुझे नहीं लगता कि इसकी आवश्यकता होगी। और मैं इस तरह से बंडल किए गए असेंबली/देशी डीएलएस/संसाधनों तक पहुंचने के लिए समर्पित एपीआई/कुछ हुप्स के माध्यम से कूदने के साथ पूरी तरह से ठीक हूं।

मुझे इस मुद्दे की ओर दो दिनों के लिए @briacht द्वारा इंगित किया गया था, इसलिए मुझे चर्चा में वास्तव में देर हो गई है।
बस मेरे 2-सेंट जोड़ना चाहते हैं!

सबसे पहले @morganbr के सवालों के मेरे जवाब:

1. विंडोज़ ऐप, डब्ल्यूपीएफ और विनफॉर्म को मिलाकर।
2. वर्तमान में नहीं
3. हां, असेंबली का उपयोग करना। विभिन्न रूपों में लोड करें
4. हां
5. यह निर्भर करता है कि क्या यह जुर्माना है जो हर स्टार्टअप पर है। हाँ अगर यह कुछ मिलीसेकंड है, लेकिन 5 सेकंड: नहीं। अगर यह एक बार है, तो 5 सेकंड कोई समस्या नहीं है।
6. 50MB पहले से ही <2MB की तुलना में काफी बड़ा है... लेकिन अगर इसका मतलब यह होगा कि डॉटनेट रनटाइम शामिल है... ठीक है। हो सकता है कि मैं साथ और बिना डाउनलोड प्रदान कर सकूं।
7. रिलीज का समय सीधे तौर पर मायने नहीं रखता है, लेकिन इसे लंबे समय तक सीपीयू का उपयोग करके सीआई प्रदाता को परेशान नहीं करना चाहिए।
8. हां!

मैं जिस एप्लिकेशन के बारे में बात करता हूं वह ग्रीनशॉट है, वर्तमान जारी संस्करण अभी भी .NET फ्रेमवर्क 2.0 (हां वास्तव में) को लक्षित कर रहा है लेकिन नवीनतम संस्करण (अच्छी पिछली संगतता) पर मुद्दों के बिना काम करता है! Zhe डाउनलोड, इंस्टॉलर सहित, लेकिन .NET फ्रेमवर्क के बिना, लगभग 1,7MB है। जिस निर्देशिका से इसे शुरू किया गया है उसमें 1 .exe और 4 .dll हैं, उप-निर्देशिका में 11 ऐड-ऑन भी हैं।

मैं पिछली टिप्पणियों के माध्यम से पढ़ रहा था, और उनमें से बहुत से ऐसा लगता है जैसे आप कार्यक्षमता के साथ कुछ चाहते हैं, मैं इसके लिए एक इंस्टॉलर का उपयोग करूंगा। यह कुछ हद तक समझ में आता है, क्योंकि वर्तमान में कोई मंच स्वतंत्र समाधान नहीं है।

मैं अगस्त में माइक्रोसॉफ्ट में कुछ लोगों के साथ वर्तमान विषय पर चर्चा कर रहा था, मेरा मुख्य ध्यान तैनाती के लिए आवेदन के आकार और जटिलता को कम करने और असेंबली लोडिंग को कम करने के लिए सब कुछ एक साथ जोड़ने के बारे में बात कर रहा था जिसमें स्टार्टअप के दौरान बहुत समय लगता है मेरे आवेदन का।

ग्रीनशॉट के अगले संस्करण के साथ, जो .NET Framework 4.7.1 और dotnet core 3.0 को साथ-साथ लक्षित करता है, dotnet core 3.0 के परिणामी डाउनलोड में वर्तमान में लगभग 103 dll (!!!), एक exe और 15 ऐड-ऑन हैं। . कुल आकार लगभग 37MB है और सबसे बड़ी फ़ाइल MahApps.Metro.IconPacks.dll (12MB !!) है जिसमें हमारे द्वारा उपयोग किए जाने वाले अधिकांश आइकन शामिल हैं, जो संभवतः फ़ाइल का लगभग 4% है। कई अन्य डीएलएस के साथ भी, मुझे लगता है कि सामान्य रूप से कोड उपयोग का 50% बहुत अधिक है!

यदि उपयोगकर्ता एप्लिकेशन इंस्टॉल नहीं करना चाहता है, तो बस एक .zip डाउनलोड करें और लगभग 118 फाइलों के बीच निष्पादन योग्य खोजें ... वास्तव में एक अच्छा अनुभव नहीं है! आकार लगभग 35MB (17x) बड़ा है, तो उपयोगकर्ता के लिए लाभ कहाँ है?

महीनों पहले डॉटनेट कोर 3.0 एक चीज थी, मैं Fody.Costura का उपयोग कर रहा था जो कि यहां वर्णित किया गया था। स्टार्टअप पर निर्माण और अनपैकिंग के दौरान पैकिंग! यहां तक ​​​​कि इसने एक भी निष्पादन योग्य बना दिया, बिना हैकिंग के संभव फाइलों को निकाले बिना। लेकिन इसने बहुत सारे मुद्दों को भी जन्म दिया, इसलिए यह मेरा पसंदीदा समाधान नहीं है।

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

Fody.Costury के समान समाधान होना निश्चित रूप से कुछ समय है जब मैं ग्रीनशॉट की तैनाती को सरल बनाने के लिए इमेजिंग कर सकता हूं, लेकिन यह सीधे आकार और लोडिंग समय को कम नहीं करता है। तो मुझे आशा है कि यहाँ भी कुछ समय व्यतीत होगा!

@ayende कृपया मुझे भी आपसे असहमत होने दें :)

हालांकि यह सच्ची सेवाएं हैं, वेब एप्लिकेशन और सामान्य तौर पर सर्वर आधारित लंबे समय तक चलने वाले ऐप्स एक बार की स्टार्टअप लागत से प्रभावित नहीं होते हैं, साथ ही ये एप्लिकेशन एकल फ़ाइल वितरण मॉडल से सबसे अधिक लाभ देखने वाले नहीं होते हैं। (रेवेन एक अपवाद है, आदर्श नहीं;))

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

अब सवाल यह है कि एम्बेडेड असेंबली का यह मॉडल अस्थायी फ़ोल्डरों में कॉपी किया गया है, अगर यह अत्यधिक लोकप्रिय हो जाता है तो क्या यह अच्छी तरह से काम करेगा?

मेरे विचार में वर्तमान मॉडल के लिए ये कुछ संभावित मुद्दे हैं:

• दर्जनों ऐप्स डुप्लीकेट असेंबली के साथ हजारों अस्थायी फ़ाइलें बनाते हैं। यहां गड़बड़ी की संभावना है। (उपयोगकर्ताओं द्वारा ध्यान नहीं दिया गया, लेकिन फिर भी एक गड़बड़ है)
• कोई संपीड़न नहीं, कोई लिंकर नहीं। यह FDD या ईवेंट ज़िपिंग की तुलना में छोटे उपयोगिता वाले ऐप्स के लिए एक नुकसान पैदा कर सकता है।
• यह वास्तव में सर्वर परिनियोजन को आसान बनाने के बजाय बाधित कर सकता है, इसका कारण यह है: टोकन प्रतिस्थापन के साथ पोस्ट परिनियोजन कॉन्फ़िगरेशन। (कॉन्फ़िगरेशन फ़ाइलों को अधिलेखित करने के लिए आप अस्थायी फ़ोल्डर को खोजने के लिए कहाँ जाते हैं? क्या आप सेवा को अपने स्वयं के फ़ोल्डर में कॉन्फ़िग फ़ाइल बनाने के लिए पहुँच प्रदान करते हैं? यह एक सुरक्षा संख्या-नहीं है)

मैं यहां यह कहने के लिए नहीं हूं कि यह मॉडल सभी प्रकार के ऐप्स के लिए उप-इष्टतम है। मैंने इसे सफलतापूर्वक कार्यान्वित किया है और इसे अतीत में full.Net Framework के लिए स्वयं उपयोग किया है, और यह कुछ ऐप्स के लिए उपयुक्त है।

मुझे लगता है कि इष्टतम कार्यान्वयन वह संस्करण है जहां एक लिंकर सभी असेंबली को एक फ़ाइल में विलय करता है।

@popcatalin81 एकल दृष्टिकोण वाली दुनिया गरीब है। और मैं इतना अहंकारी नहीं हूं कि यह सोचूं कि मेरा परिनियोजन मॉडल वहां एकमात्र है।

मेरे मन में जो मामला है वह डाउनलोड और डबल क्लिक परिदृश्य है।
अभी, हमें खोलने के लिए शेल स्क्रिप्ट को खोलना और क्लिक करना है, क्योंकि 100 फाइलों के साथ एक निर्देशिका में जाना और सही खोजना एक घर का काम है।

अस्थायी फ़ाइलों में कॉन्फ़िगरेशन के बारे में। मैं इसके बहुत खिलाफ होगा। कॉन्फिग फाइलें अन्य उपयोगकर्ता दृश्य सामग्री हैं _must_ वास्तविक फ़ाइल के ठीक बगल में रहती हैं जिसका उपयोग किया जा रहा है, कहीं छुपा नहीं है।
हम पहले ही देख चुके हैं कि IsolatedStorage फ़ाइलों के साथ यह कितना बुरा था जब उपयोगकर्ताओं को उनकी आवश्यकता थी।

रेवेनडीबी के पिछले संस्करणों में, हमने एक सरल निर्देशिका लेआउट के लिए और दृश्यमान फाइलों की संख्या को कम करने के लिए बहुत सी चीजों को शामिल किया, और इसने हमारे सॉफ़्टवेयर के उपयोग के लिए एक गंभीर प्रभाव डाला।

क्या यह सुविधा ILMerge का उपयोग करेगी? यदि नहीं, तो क्यों नहीं? अगर कोई नुकसान है तो मैं खुद को शिक्षित करना चाहता हूं।

मुझे प्रस्तावित "पैक एंड एक्सट्रैक्ट" दृष्टिकोण पसंद नहीं है, विशेष रूप से वह हिस्सा जहां डिस्क पर फाइलें निकालेगा। यह आसान है, लेकिन इसमें बहुत सी समस्याएं हैं। यह सभी डिस्क को निकाले बिना "मेमोरी में" से काम करना चाहिए।

मुझे लगता है कि यह कोरर्ट देशी कंपाइलर या कॉस्टुरा.फोडी जैसा कुछ होना चाहिए।

वैकल्पिक रूप से इसे बाइनरी आकार को कम करने का भी प्रयास करना चाहिए (अप्रयुक्त संदर्भों को हटा दें, मृत आईएल)।

पुनः

महीनों पहले डॉटनेट कोर 3.0 एक चीज थी, मैं Fody.Costura का उपयोग कर रहा था जो कि यहां वर्णित किया गया था। स्टार्टअप पर निर्माण और अनपैकिंग के दौरान पैकिंग!

ध्यान दें कि कॉस्टुरा नहीं (डिफ़ॉल्ट रूप से) "डिस्क पर अनपैक करें"। यह संसाधनों से एम्बेडेड असेंबली को निकालता है (स्मृति में) और उन्हें बाइट्स के माध्यम से लोड करता है

संदर्भ के लिए धन्यवाद @SimonCropp हम डिस्क से अनपैक करने और स्ट्रीम से लोड करने के दोनों विकल्पों की खोज कर रहे हैं। शुद्ध आईएल के लिए एक स्ट्रीम से लोडिंग को कवर करना हमारे पहले पुनरावृत्ति में संभव हो सकता है।

@jeffschwMSFT btw मूल रूप से विलय करने वाली असेंबली (और वैकल्पिक पेड़ हिलाने) का फीचर सेट कुछ ऐसा है जिसे मैं प्रथम श्रेणी के नागरिक के रूप में देखना पसंद करूंगा। कॉस्टुरा मेरी अधिक लोकप्रिय परियोजनाओं में से एक है, लेकिन यह भी एक है कि समर्थन के लिए महत्वपूर्ण समय लगता है। इसलिए यदि/जब एमएस एक विकल्प (बीटा के रूप में भी) के साथ आता है, तो मुझे बताएं और मैं इसकी समीक्षा करने में कुछ समय बिताऊंगा और कॉस्टुरा रीडमी और नगेट विवरण में कुछ "एक एमएस विकल्प है" जोड़ूंगा

जबकि संभावना नहीं है, अगर आपको एक अलग लाइसेंस के तहत कॉस्टुरा में किसी भी कोड को जारी करने की आवश्यकता है, तो बस मुझे बताएं।

धन्यवाद @SimonCropp जैसे ही हम मोनो/इलिंकर को .NET कोर टूल चेन में एकीकृत करना शुरू करते हैं, हम आपको समीक्षा के आपके प्रस्ताव पर ले जाएंगे।

ध्यान दें कि कॉस्टुरा नहीं (डिफ़ॉल्ट रूप से) "डिस्क पर अनपैक करें"। यह संसाधनों से एम्बेडेड असेंबली को निकालता है (स्मृति में) और उन्हें बाइट्स के माध्यम से लोड करता है

इससे भी बेहतर, मेरा मानना ​​​​है कि यह AppDomain.AssemblyResolve ईवेंट का उपयोग करके ऑन-डिमांड लोड करता है, इसलिए स्टार्टअप को बहुत अधिक प्रभावित नहीं किया जाना चाहिए क्योंकि यह जब भी आवश्यक हो केवल असेंबली (मेमोरी में) लोड करेगा।

यहाँ बातचीत के लिए देर हो चुकी है। क्षमा करें यदि यह पहले ही कवर किया जा चुका है।

क्या हम मान सकते हैं कि यहाँ की कलाकृति नियतात्मक होगी? इसलिए एक ही निर्माण हमेशा एक ही बाइनरी का उत्पादन करेगा? बाइट-फॉर-बाइट। एक कैनोनिकल के साथ एक बाइनरी वितरित करने में सक्षम होने के साथ-साथ चेकसम भी सहायक होगा।

@morganbr यहां बहुत कुछ पढ़ना आवश्यक है। क्या अब तक किए गए निर्णयों को लॉग करना संभव होगा?

@edblackburn हम प्रतिक्रिया के आधार पर एक अद्यतन डिज़ाइन को एक साथ खींच रहे हैं। @ स्वरूप-श्रीधर अब डिजाइन चला रहे हैं।

क्या यह सुविधा ILMerge का उपयोग करेगी? यदि नहीं, तो क्यों नहीं? अगर कोई नुकसान है तो मैं खुद को शिक्षित करना चाहता हूं।

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

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

आईएल को मर्ज करना उन ऐप्स के लिए एक उपयोगी विशेषता है जो इसे अनुकूलित कर सकते हैं - यह इस मुद्दे से बस एक अलग विशेषता है।

एक डिज़ाइन समीक्षा https://github.com/dotnet/designs/pull/52 . पर पोस्ट की गई है
आइए अब से पीआर पर चर्चा जारी रखें।

मेरे पास उन लोगों के लिए कुछ प्रश्न हैं जो सिंगल-फाइल का उपयोग करना चाहते हैं। आपके उत्तर हमें अपने विकल्पों को सीमित करने में मदद करेंगे:

1. आप किस प्रकार के ऐप के साथ इसका उपयोग करने की संभावना रखते हैं? (उदाहरण के लिए विंडोज़ पर डब्ल्यूपीएफ? एएसपी.नेट एक लिनक्स डॉकर कंटेनर में? कुछ और?)
2. क्या आपके ऐप में (गैर-.NET) C++/मूल कोड शामिल है?
3. क्या आपका ऐप प्लगइन्स या अन्य बाहरी डीएलएस लोड करेगा जिन्हें आपने मूल रूप से अपने ऐप बिल्ड में शामिल नहीं किया था?
4. क्या आप सुरक्षा सुधारों को शामिल करने के लिए अपने ऐप का पुनर्निर्माण और पुनर्वितरण करने के इच्छुक हैं?
5. यदि आपका ऐप 200-500 ms अधिक धीमी गति से शुरू होता है तो क्या आप इसका उपयोग करेंगे? 5 सेकंड के बारे में क्या?
6. आप अपने ऐप के लिए स्वीकार्य सबसे बड़ा आकार क्या मानेंगे? 5 एमबी? 10? 20? 50? 75? 100?
7. क्या आप आकार और/या स्टार्टअप समय को अनुकूलित करने के लिए एक लंबा रिलीज़ बिल्ड समय स्वीकार करेंगे? आप सबसे लंबे समय तक क्या स्वीकार करेंगे? 15 सेकंड? 30 सेकंड? 1 मिनट? 5 मिनट?
8. क्या आप अतिरिक्त काम करने के इच्छुक होंगे यदि यह आपके ऐप के आकार को आधा कर देगा?

1. हमारा dotnet/coreclr#1 अब तक का उपयोग केस कंसोल ऐप्स है जो उपयोगिताओं हैं। हम विंडोज़ या लिनक्स के लिए एक प्रकाशन करना चाहते हैं और एक निष्पादन योग्य प्राप्त करने के लिए --single-file निर्दिष्ट करना चाहते हैं। विंडोज़ के लिए हम उम्मीद करेंगे कि यह .exe में समाप्त हो, लिनक्स के लिए, यह एक निष्पादन योग्य बाइनरी होगा।
2. आमतौर पर नहीं, लेकिन यह हमारे लिए अज्ञात NuGet पैकेज के माध्यम से हो सकता है
3. शुरुआत में नहीं, लेकिन यह भविष्य की एक बेहतरीन विशेषता होगी
4. हां
5. हां
6. जो कुछ भी काम करता है
7. हां, अगर यह निष्पादन योग्य के परिणामी आकार को अनुकूलित करता है। आदर्श रूप से, --optimizing-level=5 . का उपयोग करके अनुकूलन स्तर सेट करने के लिए ध्वज हो सकता है
8. हां, एक सीमा तक

धन्यवाद @BlitzkriegSoftware।
मुझे लगता है कि यहां प्रस्तावित डिजाइन आपके उपयोग-मामले को कवर करता है। कृपया डिज़ाइन पर एक नज़र डालें -- हम आपकी प्रतिक्रिया का स्वागत करते हैं।

मेरे पास उन लोगों के लिए कुछ प्रश्न हैं जो सिंगल-फाइल का उपयोग करना चाहते हैं। आपके उत्तर हमें अपने विकल्पों को सीमित करने में मदद करेंगे:

1. आप किस प्रकार के ऐप के साथ इसका उपयोग करने की संभावना रखते हैं? (उदाहरण के लिए विंडोज़ पर डब्ल्यूपीएफ? एएसपी.नेट एक लिनक्स डॉकर कंटेनर में? कुछ और?)
2. क्या आपके ऐप में (गैर-.NET) C++/मूल कोड शामिल है?
3. क्या आपका ऐप प्लगइन्स या अन्य बाहरी डीएलएस लोड करेगा जिन्हें आपने मूल रूप से अपने ऐप बिल्ड में शामिल नहीं किया था?
4. क्या आप सुरक्षा सुधारों को शामिल करने के लिए अपने ऐप का पुनर्निर्माण और पुनर्वितरण करने के इच्छुक हैं?
5. यदि आपका ऐप 200-500 ms अधिक धीमी गति से शुरू होता है तो क्या आप इसका उपयोग करेंगे? 5 सेकंड के बारे में क्या?
6. आप अपने ऐप के लिए स्वीकार्य सबसे बड़ा आकार क्या मानेंगे? 5 एमबी? 10? 20? 50? 75? 100?
7. क्या आप आकार और/या स्टार्टअप समय को अनुकूलित करने के लिए एक लंबा रिलीज़ बिल्ड समय स्वीकार करेंगे? आप सबसे लंबे समय तक क्या स्वीकार करेंगे? 15 सेकंड? 30 सेकंड? 1 मिनट? 5 मिनट?
8. क्या आप अतिरिक्त काम करने के इच्छुक होंगे यदि यह आपके ऐप के आकार को आधा कर देगा?

1. डब्ल्यूपीएफ। कोर 3.0 ऐप
2. शायद एक नगेट पैकेज में
3. नहीं
4. हां
5. हाँ अधिकतम 200-500ms के लिए
6. महत्वपूर्ण नहीं है क्योंकि यह मूल प्रकाशित फ़ोल्डर के आकार से 2 या 3 गुना बड़ा नहीं है
7. यह उत्पादन के लिए है इसलिए वास्तव में महत्वपूर्ण नहीं है
8. हां, लेकिन ऐसा नहीं करने की संभावना है, यह उपयोगी हो सकता है यदि कार्य किसी तीसरे पक्ष के पुस्तकालय से संबंधित है

आपको जो फीडबैक मिला वह मुख्य रूप से 2019 से पहले विकास के लिए था, जो आमतौर पर वेबसर्विसेज, कंसोल एप्लिकेशन और बैकग्राउंड में लॉन्च की गई अन्य सेवाएं हैं। लेकिन अब .net core 3.0 के साथ, हमें wpf और UI ऐप्स के लिए समाधान चाहिए। .Net Framework 4.8 .Net Standard 2.1 का समर्थन नहीं करेगा और हमें ILMerge को बदलने के लिए एक समाधान की आवश्यकता है जिसे हम अब तक wpf अनुप्रयोगों के लिए उपयोग करते थे क्योंकि हमें अपने ऐप्स को .net फ्रेमवर्क (डेड फ्रेमवर्क) से .net कोर में अपग्रेड करना होता है।

इस तरह के कार्यक्रमों के लिए पहले अन्य टिप्पणियों में बताए गए अनुसार एक स्व-निकालने वाला पैकेज स्पष्ट रूप से एक अच्छा समाधान नहीं है।

1. ज्यादातर सीएलआई ऐप्स। छोटी विंडोज़ सेवाएं और सामयिक डब्ल्यूपीएफ ऐप भी दिलचस्प हैं। वेब सामग्री के लिए, एकल फ़ाइल वितरण मूल रूप से अप्रासंगिक लगता है। इस कारण से, इसका शेष भाग अधिकतर विंडोज़-उन्मुख है; हमारी Linux .NET मुख्य रुचि वेब सामग्री के आसपास है।
2. कभी - कभी। जब ऐसा होता है, तो यह लगभग हमेशा संपीड़न पुस्तकालयों के लिए होता है। यदि देशी सामान पैक नहीं किया जाता, तो यह दुनिया का अंत नहीं होता। शुद्ध प्रबंधित सामग्री के लिए एक अच्छा समाधान जिसके लिए एक अलग डीएल के रूप में मूल निर्भरता की तैनाती की आवश्यकता होती है, उसके पास अभी भी मूल्य होगा।
3. नहीं, उन मामलों में नहीं जहां हम एकल फ़ाइल की परवाह करते हैं।
4. हां।
5. सीएलआई शुरू करने के लिए चीजों को परेशान करने से पहले 200ms मोटे तौर पर सीमा है। > 1 सेकंड और हम लगभग निश्चित रूप से .NET फ्रेमवर्क (ILMerge + ngen) से चिपके रहेंगे या अन्य भाषाओं को देखेंगे जो किसी भी आवश्यक रनटाइम के साथ एक देशी बाइनरी को संकलित करते हैं जो स्थिर रूप से जुड़े हुए हैं। कई मामलों में हम सामान के बारे में बात कर रहे हैं सी # में लागू किया गया था क्योंकि एक ilmerged, ngen-ed C# ऐप वास्तव में यथोचित रूप से जल्दी से शुरू होता है। इनमें से कुछ चीजें जटिलता-वार, स्क्रिप्टिंग भाषा में लागू करने के लिए उचित हैं, लेकिन उनमें महत्वपूर्ण स्टार्टअप लागतें होती हैं, खासकर यदि आपको मॉड्यूल के समूह को खींचने की आवश्यकता होती है।
6. निर्भर करता है। हैलो वर्ल्ड के लिए 10 एमबी से अधिक की बिक्री कठिन होगी। विशाल निष्पादन योग्य भी गैर-तुच्छ स्टार्टअप लागत रखते हैं। भले ही ओएस सैद्धांतिक रूप से पूरी चीज को पढ़े बिना निष्पादन शुरू करने में सक्षम है, कम से कम विंडोज़ पर, लगभग हमेशा कुछ ऐसा होता है जो पहले कुछ सुरक्षा-आश उद्देश्य के लिए हैश प्राप्त करना चाहता है। जिसके बारे में बोलते हुए, यह अन-पैक बायनेरिज़ टू टेम्प चीज़ का एक गुच्छा AV (डिफेंडर बिल्कुल शामिल) नट्स को चलाने वाला है, संसाधन उपयोग के संदर्भ में अगर कुछ और नहीं तो स्कैनिंग।
7. ज़रूर। मुझे रिलीज़ बिल्ड में एक मिनट या अधिक जोड़ने में खुशी होगी अगर इसका मतलब कुछ ऐसा हो जो उचित आकार का हो और जल्दी से निष्पादन शुरू हो जाए।
8. निश्चित रूप से।

प्रस्ताव को पढ़ते हुए, यह हमारे पास मौजूद किसी भी परिदृश्य को संबोधित नहीं करता है और हम इसका उपयोग नहीं करेंगे। हो सकता है कि कोई ऐसा व्यक्ति हो जिसके लिए यह किसी समस्या का समाधान करता हो, लेकिन वह हम नहीं हैं।

ऐसा लगता है कि हमारे जैसे परिदृश्यों के लिए बहुत सारी प्रासंगिक चीजें हैं, जिस पर काम किया जा रहा है, बस एक टूलचेन में एक साथ नहीं आया है जो वास्तव में प्रयोग करने योग्य/काम करना जारी रखने की संभावना है। हो सकता है कि यह मेरी ओर से सिर्फ अज्ञानता है, लेकिन मैं ध्यान देने की कोशिश करता हूं और यह मेरे लिए स्पष्ट नहीं है। ILLink, Microsoft.Packaging.Tools.Trimming, CoreRT, .NET नेटिव और इस मुद्दे में जो कुछ भी होता है, के बीच ऐसा लगता है कि एक पेड़ को हिलाने, त्वरित शुरुआत (संभवतः एओटी?), उचित आकार के बाइनरी प्राप्त करने का कोई तरीका होना चाहिए। .NET कोर से बाहर (और UWP के लिए नहीं)।

1. एकल फ़ाइल वितरण https://github.com/AvaloniaUI/Avalonia (Windows, Linux, MacOS) और WPF (Windows) ऐप्स के लिए बहुत उपयोगी होगा। उदाहरण के लिए सिंगल एक्सई होने से ऑटोअपडेट्स आसान हो जाते हैं, और सामान्य तौर पर सौ डीएलएस की तुलना में सिंगल फाइल रखना अधिक सुविधाजनक होता है।
2. हां (इस अर्थ में कि यह स्क्लाइट और स्की जैसे देशी libs को प्रीबिल्ड करता है)
3. नहीं
4. हां
5. 200ms शायद ठीक है। GUI ऐप के लिए 5s स्टार्टअप समय ठीक नहीं है।
6. वास्तव में कोई फर्क नहीं पड़ता
7. वास्तव में कोई फर्क नहीं पड़ता। हम केवल उत्पादन परिदृश्यों के लिए एकल फ़ाइल बना सकते हैं।
8. हां

कृपया पैक एंड एक्सट्रेक्ट अप्रोच के साथ न जाएं। हम इसे पहले से ही आर्काइव टूल का उपयोग करके प्राप्त कर सकते हैं।

कृपया पैक एंड एक्सट्रेक्ट अप्रोच के साथ न जाएं। हम इसे पहले से ही आर्काइव टूल का उपयोग करके प्राप्त कर सकते हैं।

मैं और अधिक सहमत नहीं हो सकता। ऐसा करने के लिए पहले से ही कई टूल उपलब्ध हैं।

प्रतिक्रिया के लिए धन्यवाद @Safirion , @mattpwhite , @x2bool , @thegreatco।
इनमें से, मुझे कई उपयोग परिदृश्य (कंसोल ऐप्स, डब्ल्यूपीएफ, जीयूआई ऐप्स इत्यादि) दिखाई देते हैं, लेकिन समग्र आवश्यकताएं समान लगती हैं:

• निर्माण समय के बजाय निष्पादन/स्टार्टअप समय पर ध्यान दें।
• आगे रिलीज/पैच के लिए ऐप्स को फिर से बनाने की क्षमता
• बंडल से सीधे चलने की क्षमता (विशेषकर शुद्ध-प्रबंधित घटकों के लिए)।

मेरा मानना ​​है कि ये वे आवश्यकताएं हैं जिन्हें हमने डिज़ाइन दस्तावेज़ में संबोधित करने का प्रयास किया है।

कृपया पैक एंड एक्सट्रेक्ट अप्रोच के साथ न जाएं

हां, जैसा कि इस स्टेजिंग डॉक में बताया गया है, लक्ष्य फ़ाइल निष्कर्षण पर निर्भरता को उत्तरोत्तर कम करना है।

प्रस्ताव को पढ़ते हुए, यह हमारे पास मौजूद किसी भी परिदृश्य को संबोधित नहीं करता है और हम इसका उपयोग नहीं करेंगे।

@mattpwhite , यह स्पष्ट करना चाहता था कि क्या आपको लगता है कि यह समाधान आपके आधार पर काम नहीं करता है:

• इस कार्य-मद में पहले प्रस्तावित स्व-निष्कर्षण आधारित दृष्टिकोण, या
• इस दस्तावेज़ में नोट किया गया डिज़ाइन
  मेरा मानना ​​​​है कि बाद का दस्तावेज़ आपके द्वारा विस्तृत परिदृश्य को संबोधित करने का प्रयास करता है। धन्यवाद।

ऐसा लगता है कि हमारे जैसे परिदृश्यों के लिए बहुत सारी प्रासंगिक चीजें हैं, जिस पर काम किया जा रहा है, बस एक टूलचेन में एक साथ नहीं आया है जो वास्तव में प्रयोग करने योग्य/काम करना जारी रखने की संभावना है।

@mattpwhite , ILLink (ट्री-शेकिंग), क्रॉसजेन (रेडी-टू-रन नेटिव कोड जनरेट करना), और सिंगल-फाइल बंडलिंग पहलुओं को .net कोर 3 के लिए एक सुव्यवस्थित फैशन में msbuild/dotnet CLI में एकीकृत करने के लिए काम चल रहा है। एक बार यह किया जाता है, इन उपकरणों का उपयोग करके आसानी से पूरा किया जा सकता है (उदा: कुछ एमएसबिल्ड गुण सेट करना)।

ये सभी उपकरण, ट्रेडऑफ़ के साथ आते हैं। उदाहरण के लिए, क्रॉसजेन समय से पहले देशी कोड उत्पन्न करता है जिससे स्टार्टअप को मदद मिलती है, लेकिन बायनेरिज़ के आकार को बढ़ाने की प्रवृत्ति होती है। एकल-फ़ाइल विकल्प का उपयोग करके, ऐप्स को एकल-फ़ाइल में प्रकाशित किया जा सकता है, लेकिन यह स्टार्टअप को धीमा कर सकता है, क्योंकि देशी-बायनेरिज़ डिस्क पर फैल जाते हैं, आदि।

@ स्वरूप-श्रीधर, प्रतिक्रिया देने के लिए समय निकालने के लिए धन्यवाद।

स्पष्ट करना चाहता था कि क्या आपको लगता है कि यह समाधान आपके आधार पर काम नहीं करता है?

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

ये सभी उपकरण, ट्रेडऑफ़ के साथ आते हैं। उदाहरण के लिए, क्रॉसजेन समय से पहले देशी कोड उत्पन्न करता है जिससे स्टार्टअप को मदद मिलती है, लेकिन बायनेरिज़ के आकार को बढ़ाने की प्रवृत्ति होती है।

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

@ स्वरूप-श्रीधर वर्तमान में स्वीकृत प्रस्ताव के साथ मेरी सबसे बड़ी चिंता यह कदम है

शेष 216 फाइलें स्टार्टअप पर डिस्क पर निकाली जाएंगी।

इस तथ्य के अलावा कि "हैलो वर्ल्ड" को चलाने के लिए 216 फाइलों की आवश्यकता होती है, उन्हें किसी स्थान पर डिस्क पर निकालने से एक साधारण कमांड लाइन एप्लिकेशन को हटाना मुश्किल हो जाता है। जब लोग किसी ऐसे टूल को हटाते हैं जो इंस्टॉलर के माध्यम से नहीं आया है, तो वे इसे पूरी तरह से हटाने के लिए अन्य फ़ाइलों की खोज करने की आवश्यकता नहीं रखते हैं।

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

मेरा dotnet/coreclr#1 उपयोग का मामला कमांड लाइन उपयोगिताओं है, एक फ़ाइल, कोई निष्कर्षण मेरी प्राथमिकता नहीं होगी। लेकिन मैं यह बताना चाहूंगा कि कमांड के हिस्से के रूप में एक विकल्प देना ऑल-इन-वन बनाम ऑल-इन-वन-सेल्फ-एक्सट्रैक्टिंग के लिए स्विच करता है। स्वयं निकालने के मामले में इसमें undo शामिल होना चाहिए जो अनपॅक की गई फ़ाइलों को साफ़ करता है। पहले मामले में, उपयोगिता को हटाने का अर्थ है एक फ़ाइल को हटाना जो इसे सामान्य उपयोगिताओं के एक फ़ोल्डर में रहने के लिए उपयुक्त बनाता है, जहां-दूसरे मामले में, इंस्टॉल का अपना फ़ोल्डर होना चाहिए ताकि सफाई को आसान बनाया जा सके, और इससे बचा जा सके परिदृश्य जहां अनइंस्टॉल साझा की गई फ़ाइलों को हटा देता है। बस कुछ विचार। जैसा कि मैंने कहा, एक फ़ाइल उपयोगिता (कोई इंस्टॉल की आवश्यकता नहीं), मेरा प्राथमिक उपयोग मामला है क्योंकि मैं परियोजनाओं के लिए उपयोगिताओं (एक उपकरण-स्मिथ के रूप में) अक्सर बनाता हूं। लेकिन मैं दोनों परिदृश्यों के लिए उपयोग का मामला देख सकता हूं। लेकिन वे अलग हैं।

मेरे पास उन लोगों के लिए कुछ प्रश्न हैं जो सिंगल-फाइल का उपयोग करना चाहते हैं। आपके उत्तर हमें अपने विकल्पों को सीमित करने में मदद करेंगे:

1. आप किस प्रकार के ऐप के साथ इसका उपयोग करने की संभावना रखते हैं? (उदाहरण के लिए विंडोज़ पर डब्ल्यूपीएफ? एएसपी.नेट एक लिनक्स डॉकर कंटेनर में? कुछ और?)
2. क्या आपके ऐप में (गैर-.NET) C++/मूल कोड शामिल है?
3. क्या आपका ऐप प्लगइन्स या अन्य बाहरी डीएलएस लोड करेगा जिन्हें आपने मूल रूप से अपने ऐप बिल्ड में शामिल नहीं किया था?
4. क्या आप सुरक्षा सुधारों को शामिल करने के लिए अपने ऐप का पुनर्निर्माण और पुनर्वितरण करने के इच्छुक हैं?
5. यदि आपका ऐप 200-500 ms अधिक धीमी गति से शुरू होता है तो क्या आप इसका उपयोग करेंगे? 5 सेकंड के बारे में क्या?
6. आप अपने ऐप के लिए स्वीकार्य सबसे बड़ा आकार क्या मानेंगे? 5 एमबी? 10? 20? 50? 75? 100?
7. क्या आप आकार और/या स्टार्टअप समय को अनुकूलित करने के लिए एक लंबा रिलीज़ बिल्ड समय स्वीकार करेंगे? आप सबसे लंबे समय तक क्या स्वीकार करेंगे? 15 सेकंड? 30 सेकंड? 1 मिनट? 5 मिनट?
8. क्या आप अतिरिक्त काम करने के इच्छुक होंगे यदि यह आपके ऐप के आकार को आधा कर देगा?

1. सीएलआई (विंडोज़, लिनक्स, मैकोज़), डब्ल्यूपीएफ और विनफॉर्म।
2. कभी - कभी।
3. हां, कई बार और मुझे लगता है कि इस परिदृश्य को संबोधित किया जाना चाहिए कि एक प्लगइन मुख्य एप्लिकेशन से साझा लाइब्रेरी का पुन: उपयोग कर सकता है!
4. हां।
5. 200-500ms ठीक हैं!
6. कई निर्भरताओं के बिना एक साधारण सीएलआई आवेदन के लिए, 10 एमबी पर्याप्त (संपीड़ित) है!
7. हाँ निश्चित रूप से! बिल्ड टाइम (विशेषकर रिलीज़ बिल्ड के लिए!) कोई फर्क नहीं पड़ता! संपीड़न आकार और/या एकल फ़ाइल प्रकाशित करने के लिए स्विच वैकल्पिक होना चाहिए!
8. हाँ जैसे कोरआरटी!

आईएमएचओ, हमें गोलंग के समान प्रकाशित अनुभव को लक्षित करना चाहिए।

@thegreatco : हां, सिंगल-फाइल ऐप्स बनाने के लिए देशी कोड का पूर्ण संकलन एक अच्छा विकल्प है। GO जैसी भाषाएं उनके प्राथमिक मॉडल के रूप में समय से पहले (AOT) संकलन के साथ बनाई गई हैं - जो JIT संकलन के माध्यम से प्राप्त गतिशील भाषा सुविधाओं पर कुछ सीमाओं के साथ आती है।

CoreRT AOT संकलित ऐप्स के लिए .Net Core समाधान है। हालाँकि, जब तक CoreRT उपलब्ध नहीं है, हम इस मुद्दे में अन्य माध्यमों से एकल-फ़ाइल ऐप्स प्राप्त करने का प्रयास कर रहे हैं।

इस तथ्य के अलावा कि "हैलो वर्ल्ड" को चलाने के लिए 216 फाइलों की आवश्यकता होती है,

हैलोवर्ल्ड के लिए आवश्यक फाइलों की संख्या को कम करने के लिए कुछ विकल्प उपलब्ध हैं"

• एक फ्रेमवर्क-डिपेंडेंट ऐप बनाएं, जिसमें केवल 3-4 फाइलों की जरूरत हो
• यदि हमें स्व-निहित एप्लिकेशन बनाने की आवश्यकता है, तो फ़ाइल निर्भरता की संख्या को कम करने के लिए ILLinker का उपयोग करें

उन्हें किसी स्थान पर डिस्क पर निकालने से एक साधारण कमांड लाइन एप्लिकेशन को निकालना मुश्किल हो जाता है।

• जैसे-जैसे सिंगल-फाइल फीचर का विकास आगे के चरणों में जाता है, डिस्क पर स्पिल्ड फाइलों की संख्या कम हो जाएगी, और आदर्श रूप से अधिकांश ऐप्स के लिए शून्य हो जाएगी। लेकिन शुरुआती चरणों में, कई फाइलें (जिनमें मूल कोड होता है) को गिराना होगा।
• डिस्क पर गिराई गई फ़ाइलों का स्थान हमेशा नियतात्मक और विन्यास योग्य होता है। तो, स्पिल्ड फाइलों को एक सीधी स्क्रिप्ट के साथ साफ किया जा सकता है। लेकिन मैं मानता हूं कि यह आदर्श नहीं है।

स्पष्टीकरण @mattpwhite के लिए धन्यवाद।

हां, फीचर डेवलपमेंट के बाद के चरणों तक, स्व-निहित ऐप्स डिस्क से निकाली गई फ़ाइलों को देखेंगे। आप उपरोक्त टिप्पणी में मेरे द्वारा लिखी गई कुछ तकनीकों का उपयोग करने में सक्षम हो सकते हैं ताकि आपके ऐप्स की स्थिति में सुधार हो सके।

आपकी प्रतिक्रिया के लिए धन्यवाद @BlitzkriegSoftware।

लेकिन मैं यह बताना चाहूंगा कि कमांड के हिस्से के रूप में एक विकल्प देना ऑल-इन-वन बनाम ऑल-इन-वन-सेल्फ-एक्सट्रैक्टिंग के लिए स्विच करता है

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

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

यहाँ समझ यह है: SingleFileExtract=Never को संकलित करते समय, यदि ऐप में ऐसी फ़ाइलें हैं जिन्हें केवल निष्कर्षण (मूल बायनेरिज़) के माध्यम से नियंत्रित किया जा सकता है, तो एकल-फ़ाइल में प्रकाशित करना विफल हो जाएगा।

स्वयं निकालने के मामले में इसमें एक पूर्ववत शामिल होना चाहिए जो अनपॅक की गई फ़ाइलों को साफ़ करता है।

उचित लगता है। निष्कर्षण का सटीक स्थान (यदि कोई हो) नियतात्मक और विन्यास योग्य है। इसलिए, हमारे पास एक ऐप और उसकी सभी निकाली गई निर्भरताओं को हटाने के लिए एक स्क्रिप्ट हो सकती है।

आपकी प्रतिक्रिया के लिए धन्यवाद @DoCode। आपका परिदृश्य दिलचस्प है कि यह प्लगइन्स का उपयोग करता है।
यदि प्लगइन्स की कुछ निर्भरताएँ हैं (जो मुख्य ऐप के साथ साझा नहीं की जाती हैं), तो क्या आपको प्लगइन को एकल-फ़ाइल के रूप में भी प्रकाशित करना चाहिए/पसंद करना होगा (निर्भरता एम्बेडेड के साथ)? धन्यवाद।

हाँ @ स्वरूप-श्रीधर, यही लक्ष्य है। हमें लगता है कि इस मामले में प्लगइन को उनकी निर्भरताएं एम्बेड करनी चाहिए। केवल साझा निर्भरताएँ एकल-फ़ाइल मुख्य ऐप से बाहर रहनी चाहिए थीं।

आज, @madskristensen ने विजुअल स्टूडियो और लोकप्रिय Newtonsoft.Json NuGet पैकेज के साथ एक अच्छा स्पष्टीकरण साझा किया।

हम एक ही स्थिति में एक ही स्थिति में कभी कभी!

धन्यवाद @DoCode। एक बार सिंगल-फाइल ऐप्स लागू होने और स्थिर होने के बाद, हम सिंगल-फाइल प्लगइन्स की सुविधा के पते की योजना बनाते हैं। डिज़ाइन दस्तावेज़ यहाँ प्लगइन्स के बारे में बात करता है।

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

1. आप किस प्रकार के ऐप के साथ इसका उपयोग करने की संभावना रखते हैं? (उदाहरण के लिए विंडोज़ पर डब्ल्यूपीएफ? एएसपी.नेट एक लिनक्स डॉकर कंटेनर में? कुछ और?)
   - कमांड लाइन उपयोगिताओं (कंसोल ऐप्स)
2. क्या आपके ऐप में (गैर-.NET) C++/मूल कोड शामिल है?
   -- नहीं
3. क्या आपका ऐप प्लगइन्स या अन्य बाहरी डीएलएस लोड करेगा जिन्हें आपने मूल रूप से अपने ऐप बिल्ड में शामिल नहीं किया था?
   -- आमतौर पर नहीं
4. क्या आप सुरक्षा सुधारों को शामिल करने के लिए अपने ऐप का पुनर्निर्माण और पुनर्वितरण करने के इच्छुक हैं?
   -- हां
5. यदि आपका ऐप 200-500 ms अधिक धीमी गति से शुरू होता है तो क्या आप इसका उपयोग करेंगे? 5 सेकंड के बारे में क्या?
   -- <1 सेकंड मेरी प्राथमिकता होगी
6. आप अपने ऐप के लिए स्वीकार्य सबसे बड़ा आकार क्या मानेंगे? 5 एमबी? 10? 20? 50? 75? 100?
   -- आकार महत्वपूर्ण नहीं है
7. क्या आप आकार और/या स्टार्टअप समय को अनुकूलित करने के लिए एक लंबा रिलीज़ बिल्ड समय स्वीकार करेंगे? आप सबसे लंबे समय तक क्या स्वीकार करेंगे? 15 सेकंड? 30 सेकंड? 1 मिनट? 5 मिनट?
   -- 30 सेकंड
8. क्या आप अतिरिक्त काम करने के इच्छुक होंगे यदि यह आपके ऐप के आकार को आधा कर देगा?
   - निश्चित रूप से अगर इसे स्क्रिप्ट या कॉन्फ़िगर किया जा सकता है

1 - आप किस तरह के ऐप के साथ इसका इस्तेमाल कर सकते हैं? (उदाहरण के लिए विंडोज़ पर डब्ल्यूपीएफ? एएसपी.नेट एक लिनक्स डॉकर कंटेनर में? कुछ और?)

• खेल
• कमांड लाइन टूल्स

2 - क्या आपके ऐप में (गैर-.NET) C++/मूल कोड शामिल है?

हां

3 - क्या आपका ऐप प्लगइन्स या अन्य बाहरी डीएलएस लोड करेगा जिन्हें आपने मूल रूप से अपने ऐप बिल्ड में शामिल नहीं किया था?

हां, लेकिन पहले से ही ज्ञात प्रतीकों के साथ, मैं प्रतिबिंब पर भरोसा नहीं करता क्योंकि यह धीमा है

4 - क्या आप सुरक्षा सुधारों को शामिल करने के लिए अपने ऐप का पुनर्निर्माण और पुनर्वितरण करने के इच्छुक हैं?

हां

5 - यदि आपका ऐप 200-500 ms अधिक धीमी गति से शुरू होता है तो क्या आप इसका उपयोग करेंगे? 5 सेकंड के बारे में क्या?

नहीं, यह पहले से ही थोड़ा धीमा है

6 - सबसे बड़ा आकार क्या है जिसे आप अपने ऐप के लिए स्वीकार्य मानेंगे? 5 एमबी? 10? 20? 50? 75? 100?

परियोजना पर निर्भर करता है, लेकिन एक साधारण कमांड लाइन उपकरण के लिए, मुझे उम्मीद नहीं है कि यह एकल अंक एमबी से बड़ा होगा

7 - क्या आप आकार और/या स्टार्टअप समय को अनुकूलित करने के लिए एक लंबा रिलीज बिल्ड समय स्वीकार करेंगे? आप सबसे लंबे समय तक क्या स्वीकार करेंगे? 15 सेकंड? 30 सेकंड? 1 मिनट? 5 मिनट?

जब तक यह विकास/पुनरावृत्ति समय को प्रभावित नहीं करता है, मैं लंबे समय तक रिलीज बिल्ड टाइम के साथ ठीक हूं
लेकिन याद रखें, .net कोर ऐप्स पहले से ही पारंपरिक .net फ्रेमवर्क ऐप्स की तुलना में अधिक लंबे होते हैं

हर साल धीमे सॉफ़्टवेयर की वह प्रवृत्ति स्वीकार्य नहीं है, हमारे पास बेहतर हार्डवेयर है, उस धीमेपन का कोई कारण नहीं है

8 - यदि आप अपने ऐप के आकार को आधा कर दें तो क्या आप अतिरिक्त काम करने को तैयार होंगे?

हां!

मैं वास्तव में किसी दिन कोरआरटी ​​के साथ एओटी संकलन की उम्मीद करता हूं ताकि हम गोलंग और जंग और अन्य एओटी संकलित लैंग जैसे मूल रूप से संकलित अनुप्रयोग प्राप्त कर सकें। इसी तरह यूनिटी3डी इसे IL2CPP के साथ कैसे करता है।

@morganbr यहां मेरे और उन लोगों से कुछ इनपुट है जिनके साथ मैं काम करता हूं। मैं बहुत सी भाषाओं का उपयोग करता हूं, लेकिन मुख्य रूप से सी #, गो और पायथन।

आप किस प्रकार के ऐप के साथ इसका उपयोग करने की संभावना रखते हैं? (उदाहरण के लिए विंडोज़ पर डब्ल्यूपीएफ? एएसपी.नेट एक लिनक्स डॉकर कंटेनर में? कुछ और?)

ASP.NET कोर और कंसोल प्रोग्राम, अधिकतर Linux पर, संभावित रूप से कुछ Windows वर्कलोड, इस पर निर्भर करता है कि ML.NET हमारी आवश्यकताओं को पूरा करता है या नहीं।

क्या आपके ऐप में (गैर-.NET) C++/मूल कोड शामिल है?

इस बिंदु पर संभावना नहीं है।

क्या आपका ऐप प्लगइन्स या अन्य बाहरी डीएलएस लोड करेगा जिन्हें आपने मूल रूप से अपने ऐप बिल्ड में शामिल नहीं किया था?

निर्भर करता है। वर्तमान में हम अपनी सभी निर्भरताओं को पैकेज के रूप में खींच सकते हैं, लेकिन मुझे ऐसी स्थिति दिखाई दे रही है जहां हम एक वाणिज्यिक पुस्तकालय के लिए भुगतान करते हैं, जिसका अर्थ बाहरी डीएलएल का उपयोग करना हो सकता है।

क्या आप सुरक्षा सुधारों को शामिल करने के लिए अपने ऐप का पुनर्निर्माण और पुनर्वितरण करने के इच्छुक हैं?

बिल्कुल। यह हमारे लिए सर्वोच्च प्राथमिकता है।

यदि आपका ऐप 200-500 ms अधिक धीमी गति से शुरू होता है तो क्या आप इसका उपयोग करेंगे? 5 सेकंड के बारे में क्या?

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

आप अपने ऐप के लिए स्वीकार्य सबसे बड़ा आकार क्या मानेंगे? 5 एमबी? 10? 20? 50? 75? 100?

छोटा बेहतर है, ज्यादातर वितरण उद्देश्यों के लिए। वितरण उपयोगकर्ता द्वारा डाउनलोड की गई बायनेरिज़, बाइनरी के साथ कंटेनर इमेज आदि हो सकता है।

क्या आप आकार और/या स्टार्टअप समय को अनुकूलित करने के लिए एक लंबा रिलीज़ बिल्ड समय स्वीकार करेंगे?

निश्चित रूप से, जब तक यह सी/सी ++ और जावा से तेज़ है, तब तक यह स्वीकार्य होना चाहिए।

आप सबसे लंबे समय तक क्या स्वीकार करेंगे? 15 सेकंड? 30 सेकंड? 1 मिनट? 5 मिनट?

संभावित रूप से 30-90 सेकेंड आदर्श होंगे, लेकिन 3 मिनट से कम कुछ भी स्वीकार्य हो सकता है। छोटी/मध्यम परियोजनाओं के लिए 3 मिनट से अधिक (1k-500k LOC) थोड़ा अधिक होगा। बहुत बड़ी परियोजनाओं के लिए 5 मिनट (1M LOC) स्वीकार्य हो सकते हैं।

क्या आप अतिरिक्त काम करने के इच्छुक होंगे यदि यह आपके ऐप के आकार को आधा कर देगा?

निर्भर करता है। यदि अतिरिक्त काम बॉयलरप्लेट कोड जोड़ रहा है जिसे टेम्प्लेट किया जा सकता है, तो यह ठीक है। यदि यह अस्पष्ट है, तो सीधा काम नहीं है, संभावित रूप से नहीं।

प्रतिक्रिया के लिए धन्यवाद @mxplusb , @dark2201 , @RUSshy , @BlitzkriegSoftware

मेरा मानना ​​​​है कि शुद्ध एओटी संकलन के अभाव में वर्तमान डिज़ाइन आपके परिदृश्यों को सर्वोत्तम संभव सीमा तक संबोधित करता है। यदि आपको डिज़ाइन के बारे में कोई चिंता है, तो कृपया इसे बेझिझक सामने लाएं।

कम स्टार्टअप समय और संकलन समय होने के संबंध में:
फ्रेमवर्क पर निर्भर ऐप्स का स्टार्टअप समय काफी कम होगा (कम से कम फीचर के शुरुआती चरणों में)। संकलन समय भी छोटा है (क्योंकि कम फाइलों को एम्बेड करने की आवश्यकता है)।
जैसे ही फीचर डेवलपमेंट का पहला पुनरावृत्ति पूरा होगा, मैं स्टार्टअप-टाइम, संकलन थ्रूपुट और फ़ाइल आकार माप के साथ आपके पास वापस आऊंगा।

@ स्वरूप-श्रीधर उसके लिए समयरेखा क्या है?

@ayende पहला पुनरावृत्ति सक्रिय विकास के अधीन है, मुझे लगता है कि हमारे पास कुछ हफ्तों में परिणाम होंगे।

@स्वरूप-श्रीधर

मेरा मानना ​​​​है कि शुद्ध एओटी संकलन के अभाव में वर्तमान डिज़ाइन आपके परिदृश्यों को सर्वोत्तम संभव सीमा तक संबोधित करता है। यदि आपको डिज़ाइन के बारे में कोई चिंता है, तो कृपया इसे बेझिझक सामने लाएं।

भागो: HelloWorld.exe

बंडल किए गए ऐप और कॉन्फ़िगरेशन फ़ाइलों को सीधे बंडल से संसाधित किया जाता है।
शेष 216 फाइलें स्टार्टअप पर डिस्क पर निकाली जाएंगी।

क्या होगा अगर मुझे केवल पढ़ने के लिए fs से चलाने की आवश्यकता है, यह IoT के लिए सामान्य है, या यदि exe एक ro कंटेनर के अंदर चल रहा है? इसे सीधे exe से चलाने का विकल्प क्यों नहीं है?

@etherealjoy इस खंड में दिखाया गया उदाहरण इस सुविधा को विकसित करने के चरण 2 के अनुसार स्व-निहित हैलोवर्ल्ड के लिए अपेक्षित आउटपुट है (जैसा कि इस खंड में बताया गया है)। इस स्तर पर, केवल वही ऐप जो सीधे EXE से चल सकते हैं, वे हैं फ्रेमवर्क पर निर्भर शुद्ध-प्रबंधित ऐप।

यदि हम स्टेज 4 या स्टेज 5 में हैं, तो उपरोक्त स्व-निहित ऐप सीधे बंडल से निष्पादित हो सकता है।

आप किस प्रकार के ऐप के साथ इसका उपयोग करने की संभावना रखते हैं? (उदाहरण के लिए विंडोज़ पर डब्ल्यूपीएफ? एएसपी.नेट एक लिनक्स डॉकर कंटेनर में? कुछ और?)

मूल रूप से उपरोक्त सभी। कंसोल यूटिलिटीज, डब्ल्यूपीएफ, एएसपीनेट, गेम्स

क्या आपके ऐप में (गैर-.NET) C++/मूल कोड शामिल है?

हां। स्क्लाइट एक अच्छा उदाहरण है।

क्या आपका ऐप प्लगइन्स या अन्य बाहरी डीएलएस लोड करेगा जिन्हें आपने मूल रूप से अपने ऐप बिल्ड में शामिल नहीं किया था?

संभवतः नहीँ।

क्या आप सुरक्षा सुधारों को शामिल करने के लिए अपने ऐप का पुनर्निर्माण और पुनर्वितरण करने के इच्छुक हैं?

हां।

यदि आपका ऐप 200-500 ms अधिक धीमी गति से शुरू होता है तो क्या आप इसका उपयोग करेंगे? 5 सेकंड के बारे में क्या?

net.core पहले से ही थोड़ा धीमा है। लेकिन कुछ सेकंड की वृद्धि स्वीकार्य है। 5 सेकंड - निश्चित रूप से नहीं।

आप अपने ऐप के लिए स्वीकार्य सबसे बड़ा आकार क्या मानेंगे? 5 एमबी? 10? 20? 50? 75? 100?

कोई बात नहीं आजकल

क्या आप आकार और/या स्टार्टअप समय को अनुकूलित करने के लिए एक लंबा रिलीज़ बिल्ड समय स्वीकार करेंगे? आप सबसे लंबे समय तक क्या स्वीकार करेंगे? 15 सेकंड? 30 सेकंड? 1 मिनट? 5 मिनट?

5 मिनट तक का फील स्वीकार्य है। UWP के लिए 15-20 मिनट की रिलीज़ बिल्ड सभी को पागल कर रही है।

क्या आप अतिरिक्त काम करने के इच्छुक होंगे यदि यह आपके ऐप के आकार को आधा कर देगा?

ज़रूर।

धन्यवाद @mjr27

चरण 1 कार्यान्वयन अब पूरा हो गया है, और 3.0.100-पूर्वावलोकन5-011568 के रूप में उपलब्ध है।

PublishSingleFile संपत्ति को true पर सेट करके ऐप्स को एक फ़ाइल में प्रकाशित किया जा सकता है जैसा कि यहां बताया गया है।

इस संस्करण में, सभी एम्बेडेड फाइलों को पहले रन पर डिस्क पर निकाला जाता है, और बाद के रन में पुन: उपयोग किया जाता है, जैसा कि यहां बताया गया है।

संकलन थ्रूपुट
समय में कोई महत्वपूर्ण अंतर नहीं है कि क्या फाइलें प्रकाशित निर्देशिका में अलग-अलग फाइलों के रूप में लिखी जाती हैं या एक फाइल के रूप में।

फ़ाइल का आकार और स्टार्टअप
निम्न तालिका एकल-फ़ाइल के रूप में निर्मित कुछ ऐप्स के प्रदर्शन को दिखाती है।

• कंसोल: एक हैलो वर्ल्ड ऐप। रिपोर्ट किया गया समय ऐप को चलाने का समय है, जिसे क्लॉक टिक के माध्यम से मापा जाता है।
• डब्ल्यूपीएफ ऐप: एमएसिक्स-कैटलॉग ऐप। रिपोर्ट किया गया समय स्टॉपवॉच के माध्यम से मापा गया प्रारंभिक स्क्रीन पर स्टार्टअप का समय है।
• एफडब्ल्यू: फ्रेमवर्क-निर्भर बिल्ड
• स्व: स्व-निहित बनाता है।
  सभी रन समयबद्ध थे जब बाहरी कारकों के प्रभाव को कम करने के लिए एंटी-वायरस जांच बंद कर दी गई थी।

मापन | कंसोल एफडब्ल्यू | कंसोल सेल्फ | डब्ल्यूपीएफ एफडब्ल्यू | डब्ल्यूपीएफ सेल्फ
-- | -- | -- | -- | --
फ़ाइल का आकार (एमबी) | 0.32 | 66.5 | 20.69 | 118.9
सामान्य रन (सेकंड) | 0.123 | 0.127 | 3.32 | 3.24
सिंगल-एक्सई फर्स्ट रन (सेकंड) | 0.127 | 0.565 | 3.67 | 4.14
सिंगल-एक्सई बाद के रन (सेकंड) | 0.124 | 0.128 | 3.30 | 3.29

विकास के बाद के चरणों में कार्यान्वयन आगे बढ़ने पर मैं संख्याओं को अद्यतन करता रहूंगा।

उत्कृष्ट खबर। शुक्रिया

क्या स्टेजिंग डॉक में उल्लिखित सभी चरणों को 3.0 आरटीएम के लिए पूरा किया जाएगा? या हमें उन्हें लागू करने के लिए 3.0 के बाद इंतजार करना होगा?

जैसा कि यहां बताया गया है, .net core 3.0 के चरण 2 को लागू करने की उम्मीद है, ताकि फ्रेमवर्क पर निर्भर शुद्ध एमएसआई ऐप सीधे बंडल से चल सकें। आगे की रिलीज के लिए शेष चरणों पर विचार किया जाएगा।

जैसा कि यहां बताया गया है, .net core 3.0 के चरण 2 को लागू करने की उम्मीद है, ताकि फ्रेमवर्क पर निर्भर शुद्ध एमएसआई ऐप सीधे बंडल से चल सकें। आगे की रिलीज के लिए शेष चरणों पर विचार किया जाएगा।

:( उम्मीद कर रहा था कि यह इसे आरटीएम में ला सकता है।

@cup मैंने सोचा था कि आप इसे dotnet publish -o out /p:PublishSingleFile=true /p:RuntimeIdentifier=win-x64 के साथ कर सकते हैं। मैंने अभी एक वेनिला कंसोल ऐप बनाकर और उस कमांड को चलाकर परीक्षण किया है। इसने सफलतापूर्वक काम किया।

आप dotnet publish -o out /p:PublishSingleFile=true /p:RuntimeIdentifier=win-x64 /p:IncludeSymbolsInSingleFile=true . के साथ .pdb फ़ाइल में बंडल करके और भी आगे जा सकते हैं

विस्तृत नोट्स के लिए धन्यवाद @seesharprun । हाँ @cup , कमांड-लाइन सिंगल-फाइल प्रकाशन के लिए अनुशंसित विधि कमांड लाइन से PublishSingleFile प्रॉपर्टी सेट करना है।

@etherealjoy coreclr रनटाइम रेपो ज्यादातर एक या एक महीने में wrt फीचर काम को बंद कर दिया जाएगा। मुझे नहीं लगता कि सभी चरणों के लिए पर्याप्त समय है। मैं उम्मीद कर रहा हूं कि अगले चरण अगली रिलीज में आएंगे।

मुझे यह आज काम कर रहा है लेकिन ऐसा प्रतीत होता है कि निष्कर्षण आधार डीआईआर को बदलना काम नहीं कर रहा है। इस खंड के अनुसार। एप्लिकेशन को निकाले जाने वाले स्थान को बदलने के लिए मुझे ExtractBaseDir नामक रनटाइम कॉन्फिग में एक एप्लिकेशन स्विच जोड़ने में सक्षम होना चाहिए।

मेरे पास एक रनटाइम config.template.json है जो इस तरह दिखता है

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

उत्पादित app.runtimeconfig.json इस तरह दिखता है:

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

हालांकि उत्पादित exe हालांकि चल रहा है, हालांकि यह अभी भी tmp फ़ोल्डर में फैलता है।

मुझे लगता है कि यह सुविधा पूर्वावलोकन 5 में अभी तैयार नहीं है, लेकिन मैं यह सुनिश्चित करना चाहता था क्योंकि यह स्पष्ट नहीं है कि "ExtractBaseDir" को रनटाइमकॉन्फिग.जेसन में जाना है और कोई उदाहरण नहीं है।

@ igloo15 इसे लाने के लिए धन्यवाद।

वर्तमान पूर्वावलोकन में, केवल पर्यावरण चर DOTNET_BUNDLE_EXTRACT_BASE_DIR सक्षम है। ऐसा इसलिए है क्योंकि कार्यान्वयन के वर्तमान चरण में - runtimeconfig.json सहित - सभी फाइलों को संसाधित होने से पहले डिस्क पर निकाल दिया जाता है।

मैं अगले पूर्वावलोकन में ExtractBaseDir के लिए समर्थन जोड़ने पर काम कर रहा हूं।

क्या ASP.NET कोर प्रोजेक्ट्स के साथ यह काम करने के बारे में कुछ मार्गदर्शन है? क्या मेरे सिस्टम प्रकार कहां से लोड हो रहे हैं और उस निर्देशिका से संबंधित मेरे IHostingEnvironment ContentRootPath और WebRootPath को सेट करने के लिए प्रतिबिंब का उपयोग करने के लिए अनुशंसित दृष्टिकोण क्या होगा?

@keithwill आप उस स्थान को प्राप्त करने के लिए AppContext.BaseDirectory का उपयोग कर सकते हैं जहां app.dll और अन्य सभी फाइलें डिस्क पर निकाली जाती हैं। तो, आप इसे ContentRootPath के रूप में उपयोग कर सकते हैं।

@ igloo15 : मैं उत्सुक हूं कि क्या आप इस विकल्प का उपयोग करने के लिए अपने परिदृश्य को साझा कर सकते हैं।

• क्या आप इसे डिबगिंग या उत्पादन-तैनाती परिदृश्य के लिए उपयोग करने का प्रयास कर रहे हैं?
• क्या इस मामले में पर्यावरण चर पर्याप्त होगा, या क्या आपको runtimeconfig.json सेटिंग की आवश्यकता है?

मैं अन्य डेवलपर्स से भी सुनने के लिए उत्सुक हूं, अगर इस सेटिंग के लिए विशिष्ट उपयोग-मामले हैं।

@स्वरूप-श्रीधर

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

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

1.) यह एक उत्पादन परिनियोजन परिदृश्य है
2.) पर्यावरण चर मुश्किल होगा क्योंकि सॉफ्टवेयर चलाने वाला कंप्यूटर लगातार अलग होता है और नष्ट/रीमेड किया जा रहा है

@cup मैं वास्तव में सहमत नहीं हूं कि यह विषय डिज़ाइन दस्तावेज़ को लागू करने के बारे में है और डिज़ाइन दस्तावेज़ विशेष रूप से कहता है ExtractBaseDir इस सुविधा के लिए काम करना चाहिए।

यदि यह समस्या इस डिज़ाइन दस्तावेज़ को लागू करने के बारे में नहीं है तो यह समस्या किस बारे में है?

स्पष्टीकरण के लिए धन्यवाद @ igloo15।

मैं कॉन्फ़िगरेशन विकल्प के बारे में पूछता हूं, क्योंकि ऐपहोस्ट कोड में कॉन्फ़िगरेशन फ़ाइलों को जल्दी पार्स करने की लागत है। वर्तमान में ऐपहोस्ट जेसन फाइलों को पार्स करने के लिए कोड से लिंक नहीं करता है (वे इसके बजाय hostfxr/hostpolicy द्वारा उपयोग किए जाते हैं)। वर्तमान में इस सुविधा को जोड़ने से AppHost थोड़ा बड़ा/जटिल हो जाएगा। हालाँकि एक बार कार्यान्वयन आगे के चरणों में (जहाँ सभी होस्टिंग और रनटाइम कोड एक साथ जुड़े हुए हैं), यह अब कोई समस्या नहीं है।

@ igloo15 डिजाइन डॉक इसका एक महत्वपूर्ण हिस्सा है, लेकिन इस मुद्दे का मूल फीचर ही है। ExtractBaseDir एक वैकल्पिक पैरामीटर है और मैं वैकल्पिक पैरामीटर के साथ फंसने के बजाय मुख्य विशेषता को "वर्तमान" रिलीज में पारित करना चाहता हूं।

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

@ कप @ स्वरूप-श्रीधर

कुछ बातें जो मैं पहले कहूंगा वह यह है कि यह सुविधा केवल स्टेज दस्तावेज़ के चरण 1 के लिए मायने रखती है। अन्य सभी चरण 2 - 5 बंडल के अंदर से डीएलएस चलाने और निकालने के बारे में नहीं हैं। तो 2-5 चरणों के लिए अर्क बेस डीआईआर का स्थान निर्धारित करने के लिए एक सेटिंग वास्तव में उपयोगी नहीं है। चूंकि नेटकोर 3.0 चरण 1 को विकसित करने का इरादा रखता है, मुझे उम्मीद है कि यह सुविधा वहां होगी क्योंकि यह केवल तभी उपयोगी होगा।

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

जहां तक ​​​​इसे लागू किया गया है, मुझे यकीन नहीं है, लेकिन मुझे लगता है कि रनटाइम पर कॉन्फ़िगरेशन से ExtractBaseDir को पढ़ने के बजाय हम बिल्ड समय पर बंडल एक्सई में शामिल नहीं हो सकते हैं? मैंने उस कोड को नहीं देखा है जो इस बंडल प्रक्रिया को काम करता है लेकिन मेरे दिमाग में इसके अंदर सभी डीएलएस आदि के साथ मूल एक्सई उत्पन्न/निर्माण करता है। क्या हम exe की पीढ़ी/निर्माण के दौरान बंडल किए गए ऐप्स रनटाइमकॉन्फ़िग फ़ाइल को ExtractBaseDir को बाहर नहीं निकाल सकते हैं और इसे मूल बंडल exe पर एक संपत्ति के रूप में सेट नहीं कर सकते हैं।

फिर यह रनटाइम पर एम्बेडेड रनटाइम कॉन्फिग को नहीं पढ़ रहा है बल्कि निष्कर्षण स्थान निर्धारित करने के लिए आंतरिक रूप से एक संपत्ति का लाभ उठा रहा है। यह संभावित रूप से बहुत तेज होना चाहिए।

@ igloo15 : बंडल की सामग्री को डिस्क पर निकालना चरण 2 के बाद के कुछ ऐप्स के लिए उपयोगी हो सकता है।
उदाहरण के लिए, यदि ऐप में बंडल में कस्टम नेटिव बायनेरिज़ हैं, तो उन्हें स्टेज 5 तक निकालने की आवश्यकता होगी। ऐप अज्ञात प्रकार की सामग्री फ़ाइलों को रनटाइम पर फ़ाइलों में निकालने के लिए बंडल करना चाह सकता है।

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

मैं मानता हूं कि रनटाइम कॉन्फिग विकल्प के बजाय निष्कर्षण स्थान को बिल्ड-टाइम सेटिंग (उदा: msbuild-property) बनाना आसान और अधिक कुशल wrt कार्यान्वयन है। धन्यवाद।

नमस्ते, इस विषय पर मेरे कुछ प्रश्न हैं:

मैं पैकेजिंग के लिए सिंगल-फाइल डिस्ट्रीब्यूशन फीचर का उपयोग करना चाहता हूं। नेट फ्रेमवर्क 4.7.2 (उदाहरण के लिए) अनुप्रयोगों को एक निष्पादन योग्य में। क्या यह इस सुविधा का इरादा है या यह केवल .NET कोर अनुप्रयोगों का समर्थन करने के लिए है?

मेरा दूसरा प्रश्न इस बात से संबंधित है कि पैकेजिंग कैसे की जाती है। जब निष्पादन योग्य बनाया जाता है तो क्या लक्ष्य ढांचे रनटाइम निष्पादन योग्य में बंडल हो जाएंगे? या इसे लक्ष्य मशीन पर पूर्व-स्थापित किया जाना चाहिए जो एप्लिकेशन चलाएगा?

@gaviriar मुझे नहीं लगता कि यह .NET Framework अनुप्रयोगों का समर्थन करता है। और हाँ यह .NET कोर रनटाइम को निष्पादन योग्य (तथाकथित "स्वयं निहित" प्रकाशित) में बंडल कर सकता है।

@ tomrus88 प्रतिक्रिया के लिए धन्यवाद। यह .NET Framework अनुप्रयोगों के संबंध में एक वास्तविक शर्म की बात है। क्या कोई तरीका है जिसकी आप अनुशंसा करेंगे जिसका उपयोग .NET Framework रनटाइम को निष्पादन योग्य में बंडल करने के लिए किया जा सकता है?

मुझे दस्तावेज़ के संबंधित कार्य अनुभाग में टूल की एक सूची दिखाई देती है। क्या कोई विशेष रूप से ऊपर प्रस्तावित मेरे उपयोग के मामले के लिए अनुशंसित किया जा सकता है?

@gaviriar .NET Framework विंडोज ओएस का हिस्सा है। इसे निष्पादन योग्य में बंडल करने का कोई समर्थित तरीका नहीं है।

@gaviriar रनटाइम को बंडल करने की आवश्यकता .NET कोर पर स्विच करने के प्रमुख कारणों में से एक है।

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

यह पुस्तकालय पर निर्भर करता है। .NET Framework को लक्षित करने वाले बहुत से पुस्तकालय .NET Core पर भी ठीक काम करते हैं। क्या आपने .NET कोर में पुस्तकालय का उपयोग करने की कोशिश की है? यदि आपने सत्यापित किया है कि यह काम नहीं करता है, तो आप तब तक स्विच नहीं कर सकते जब तक आपके पास इसका समाधान न हो।

मैंने वास्तव में इसकी कोशिश की है, लेकिन यह काम नहीं करता है क्योंकि हम पुस्तकालयों के बारे में बात कर रहे हैं जो विंडोज़ विशिष्ट हैं। मुझे लगता है कि मेरे पास .NET फ्रेमवर्क को लक्षित करने के अलावा और कोई विकल्प नहीं है और जैसा कि आप कहते हैं .NET कोर फन से चूक जाते हैं: /

@gaviriar यह विषय से हटकर है, लेकिन क्या आपने Windows संगतता NuGet पैकेज की कोशिश की है, यह .NET कोर के लिए विंडोज़ एपीआई प्रदान करता है, सटीक उद्देश्य के लिए आप Microsoft.Windows.Compatibility का वर्णन कर रहे हैं।

@gaviriar : कुछ और स्पष्टीकरण:

जब निष्पादन योग्य बनाया जाता है तो क्या लक्ष्य ढांचे रनटाइम निष्पादन योग्य में बंडल हो जाएंगे? या इसे लक्ष्य मशीन पर पूर्व-स्थापित किया जाना चाहिए जो एप्लिकेशन चलाएगा?

यह निर्माण पर निर्भर करता है। दोनों फ्रेमवर्क-निर्भर (रनटाइम लक्ष्य पर स्थापित है), और स्व-निहित (रनटाइम ऐप के साथ पैक किया गया है) ऐप्स को एकल-फ़ाइल के रूप में प्रकाशित किया जा सकता है - लेकिन केवल .net कोर 3.0 ऐप्स।

मुझे दस्तावेज़ के संबंधित कार्य अनुभाग में टूल की एक सूची दिखाई देती है। क्या कोई विशेष रूप से ऊपर प्रस्तावित मेरे उपयोग के मामले के लिए अनुशंसित किया जा सकता है?

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

@ इग्लू 15 और @ स्वरूप-श्रीधर मैं इन इनपुट्स की सराहना करता हूं क्योंकि वे विषय से बाहर हैं। हालाँकि मुझे आशा है कि किसी और को यह चर्चा किसी दिन पढ़ते समय उपयोगी लगेगी।

मैं आपके द्वारा मेरे साथ साझा किए गए विकल्पों का मूल्यांकन करूंगा और आपको बताऊंगा कि मेरे उपयोग के मामले के लिए सबसे अच्छा तरीका क्या है।

धन्यवाद!

शीघ्र नवीनीकरण!

मैंने इस सरल हैलो वर्ल्ड एप्लिकेशन का परीक्षण किया है। मैं निष्पादन योग्य एकल फ़ाइल को सफलतापूर्वक बना सकता हूं। हालाँकि, जैसा कि आप प्रोजेक्ट कॉन्फ़िगरेशन से देख सकते हैं, यह स्व-निहित होने के लिए है। लेकिन जब मैं इस निष्पादन योग्य को बिना किसी .NET कोर रनटाइम के नए विंडोज 7 इंस्टॉलेशन पर चलाने की कोशिश करता हूं तो मुझे निम्न त्रुटि दिखाई देती है:

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

मैं जो देख सकता हूं वह यह है कि ऐप को dotnet publish /p:PublishSingleFile=true या /p:PublishSingleFile=false के रूप में प्रकाशित करने से निष्पादन योग्य का आकार नहीं बदलता है। क्या यह अपेक्षित व्यवहार है?

प्रजनन के चरण

1. HelloWorld.exe . उत्पन्न करने के लिए प्रोजेक्ट प्रकाशित करें

2. निष्पादन योग्य को किसी भी .NET कोर रनटाइम के साथ विंडोज 7 इंस्टॉलेशन में कॉपी करें

3. HelloWorld.exe . चलाएँ

@gaviriar मैंने आपके द्वारा प्रकाशित उदाहरण की कोशिश की, और यह मेरे लिए ठीक काम किया।
यही है, इसने हैलोवर्ल्ड के लिए एक स्व-निहित एकल-एक्सई बनाया जो ठीक चलता है।

मैं जो देख सकता हूं वह यह है कि ऐप को डॉटनेट प्रकाशित/पी: पब्लिशसिंगलफाइल = सत्य या/पी: पब्लिशसिंगलफाइल = झूठी के रूप में ऐप को प्रकाशित करना निष्पादन योग्य का आकार नहीं बदलता है। क्या यह अपेक्षित व्यवहार है?

यह निश्चित रूप से अपेक्षित नहीं है। सिंगल-फाइल ऐप लगभग 70 एमबी (आपके गिटलैब पेज पर बताए गए डिबग बिल्ड के लिए) होना चाहिए। अन्यथा, यह एक सामान्य एपॉस्ट है, जिसके ठीक वैसे ही विफल होने की उम्मीद है जैसा आपने ऊपर बताया है। क्या आप एक स्वच्छ निर्देशिका से प्रकाशित कर रहे हैं?

आपकी प्रोजेक्ट फ़ाइल के बारे में एक अन्य नोट -- आपके पास $#$ IncludeSymbolsInSingleFile $#$ के बजाय IncludeSymbolsInFile के रूप में गलत तरीके से लिखी गई संपत्तियों में से एक है। लेकिन इसका आपके द्वारा रिपोर्ट की गई समस्या से कोई संबंध नहीं है।

@gaviriar आपका लक्षित रनटाइम पहचानकर्ता क्या है। यदि आप इसे सही ढंग से सेट नहीं करते हैं तो यह सही hostfxr.dll को बंडल नहीं करेगा। यह संभव है कि hostfxr.dll को एक विशिष्ट वीसी ++ पुनर्वितरण की आवश्यकता होती है जो आपके विंडोज 7 मशीन पर मौजूद नहीं है। आप जांच सकते हैं कि दिए गए पथ पर डीएलएल मौजूद है और यदि यह निर्भरता वॉकर टूल में लोड करने का प्रयास करता है तो यह देखने के लिए कि कोई डीएल मौजूद है या नहीं।

IL का विलय: ILMerge जैसे उपकरण कई असेंबली से IL को एक में मिलाते हैं, लेकिन इस प्रक्रिया में असेंबली पहचान खो देते हैं। यह एकल-फ़ाइल सुविधा के लिए एक लक्ष्य नहीं है।

विधानसभा की पहचान खोना

यह समस्या नहीं है।
मैं हमेशा सिंगल एक्सई स्वयं निहित सुविधा के लिए ज़िप/अनजिप या अन्य बंडल समाधान का उपयोग करने के खिलाफ हूं।
क्योंकि यह अगले मुद्दों का कारण होगा।
एकल exe फ़ाइल का आकार कैसे कम करें!?? या exe फ़ाइल इतनी बड़ी क्यों है लेकिन यह केवल एक हैलो वर्ल्ड है !??

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

वास्तव में, लोग वास्तव में एक EXE के प्रति इतने जुनूनी नहीं होते हैं।
exe(1)+dll(1-2) भी ठीक है, लेकिन 400 माउंट डीएलएस नहीं।
पीपीएल कोड को सर्वर डिस्क पर कभी भी निष्पादित नहीं करना चाहता है और इसे सर्वर मेमोरी लेना चाहता है।
लोग बस परिनियोजन की लागत कम करना चाहते हैं। (डिस्क, मेमोरी, बैंडविड्थ आदि...)

मैंने 3.0 मील का पत्थर हटा दिया, ताकि यह समस्या इस दस्तावेज़ में वर्णित चरणों के माध्यम से एकल-फ़ाइल सुविधा के कार्यान्वयन को ट्रैक करे, जो कि 3.0 रिलीज़ के दायरे से बाहर है।

@sgf , मैं मानता हूं कि फ़ाइल के आकार को कम करने के लिए काम करने की आवश्यकता है। आकार में कमी के अवसर दो रूपों के होते हैं, वे विशेष रूप से सिंगल-एक्सई से बंधे नहीं होते हैं:
1) प्रकाशित होने वाली सामग्री की मात्रा कम करें। उदाहरण के लिए:
* अनावश्यक बायनेरिज़, असेंबली के हिस्सों आदि को ट्रिम करने के लिए ILLinker जैसे टूल का उपयोग करें।
इस काम को डॉटनेट/कोरक्लर#24092 और मोनो/लिंकर#607 जैसे मुद्दों द्वारा अलग से ट्रैक किया जाता है।
* हम अन्य उपायों पर विचार कर सकते हैं जैसे "कम क्षमता" मोड होना जहां JITting को कम करने के लिए समर्थित नहीं है
2) सिंगल-फाइल पब्लिशिंग में कंप्रेशन फीचर जोड़ें।

उपरोक्त सुविधाएँ एकल-फ़ाइल (और गैर-एकल-फ़ाइल) ऐप्स के आकार को कम करने के लिए एक साथ काम कर सकती हैं:
उदाहरण के लिए, हैलोवर्ल्ड कंसोल ऐप के लिए,
सामान्य प्रकाशन आकार = 67.4 एमबी
छंटे हुए आकार = 27 एमबी
छंटनी, एकल फ़ाइल, संपीड़ित (प्रोटोटाइप के माध्यम से) = 12MB

@ स्वरूप-श्रीधर क्या आपके आवेदन के भीतर आपकी एकल फ़ाइल exe का पथ प्राप्त करने का कोई तरीका है?
Assembly.GetExecutingAssembly().Location का उपयोग करने से निष्कर्षण डीआईआर \AppData\Local\Temp.net में आउटपुट होगा।

@ chris3713 वर्तमान में exe स्थान तक पहुँचने का सबसे अच्छा तरीका PInvoke-ing से देशी एपीआई है। उदाहरण के लिए: GetModuleFileNameW (Null, <buffer>, <len>)

@ chris3713 वर्तमान में exe स्थान तक पहुँचने का सबसे अच्छा तरीका PInvoke-ing से देशी एपीआई है। उदाहरण के लिए: GetModuleFileNameW (Null, <buffer>, <len>)

धन्यवाद, मैं Process.GetCurrentProcess().MainModule.FileName का उपयोग कर समाप्त हुआ।

PublishSingleFile=true के साथ प्रकाशित विंडोज सेवा के रूप में asp .net कोर वर्कर/वेब एपीआई के साथ ठीक काम करता है।

जब मैं सेवा पंजीकृत करता हूं और इसे sc create testwk binPath="[...]/MyAspNetCoreWorker.exe" के माध्यम से चलाता हूं तो sc start testwk मुझे यह सफलता संदेश मिला है:

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

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

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

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

मैं स्टेज 2 को बंडल में चलाने के साथ देखने के लिए इंतजार नहीं कर सकता😀
वैसे, क्या स्टेज 2 को अभी भी .Net Core 3.0 का हिस्सा बनने की योजना बनाई जाएगी?

आपके काम के लिए धन्यवाद, .net कोर में प्रकाशन सेवा अब वास्तव में सरल है

कोरआरटी : (2.5 एमबी)

कोई ज़िप हैक नहीं, कोई छिपी हुई लागत नहीं , इंजन में केवल वही होता है जिसकी आवश्यकता होती है, और उपयोग नहीं की जाने वाली सुविधाओं को csproj config (प्रतिबिंब) का उपयोग करके अक्षम किया जाता है।

यह वही है जो डॉटनेट को चाहिए, यह जीओ के साथ प्रतिस्पर्धा करता है और यहां तक ​​​​कि आकार और पूर्णता दोनों के मामले में इसे पार करता है

रुचि रखने वाले किसी व्यक्ति के लिए, रेपो देखें:

https://github.com/dotnet/corert

मोनोगेम के लिए नमूने हैं:

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

प्रस्तावित समाधानों में से कोई भी इस परिणाम को प्राप्त नहीं कर सकता है, कोरआरटी ​​वास्तव में सबसे अच्छा है, एमएस इस पर ध्यान केंद्रित न करके बहुत बड़ी गलती कर रहा है

मैंने macOS पर dotnet-sdk-3.0.100-preview8-013656-osx-x64.tar.gz के साथ इस सुविधा का परीक्षण किया है। अगर हम डिबग से रिलीज या इसके विपरीत कॉन्फ़िगरेशन को स्विच करते हैं और फिर से निर्माण करते हैं, तो यह निष्पादन योग्य आकार में 10 एमबी जोड़ता है। जब तक हम bin निर्देशिका को हटा नहीं देते तब तक पुराने कॉन्फ़िगरेशन के साथ पुन: संकलन आकार में इस वृद्धि को पुनर्प्राप्त नहीं करता है।

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

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

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

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

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

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

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

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

बिल्ड कॉन्फ़िगरेशन को बदले बिना भी, यदि हम प्रारंभिक निर्माण के बाद बाद में पुनर्निर्माण लक्ष्य ( /t:Rebuild ) का आह्वान करते हैं, तो आउटपुट आकार बढ़ जाता है।

धन्यवाद @ am11 एक बार देखने के लिए। पुरानी बायनेरिज़ को बनाए रखना प्रकाशित करना एक ज्ञात समस्या है (cc @nguerrera)।

नेट कोर 3 पूर्वावलोकन 8 के बाद से, मैं अपनी एकल फ़ाइल प्रकाशित ऐप लॉन्च नहीं कर सकता।
घटना दर्शक में मुझे यह त्रुटि है:

मैं विंडोज सर्वर 2019 पर हूं

संपादित करें: यह त्रुटि .Net Core SDK Preview 7 से .Net Core SDK Preview 8 को अपडेट करने के बाद हुई है। सर्वर को रिबूट करने के बाद, मैं अपने एप्लिकेशन को फिर से सही तरीके से लॉन्च कर सकता हूं।

@Safirion हमने इन पूर्वावलोकनों के आसपास अंतर्निहित आंतरिक प्रारूप में बदलाव किया है। यह संभव है कि आपने एक पूर्वावलोकन से आउटपुट को स्ट्रैडल किया और दूसरे के साथ बनाया। पूर्वावलोकन 8 और 9 के बीच कोई विराम नहीं है।

लिनक्स पर डिफ़ॉल्ट निष्कर्षण पथ /var/tmp/.net प्रतीत होता है। एडब्ल्यूएस लैम्ब्डा पर /var पथ लिखने योग्य नहीं है, इसलिए उस फ़ोल्डर को बनाने में विफल रहता है। DOTNET_BUNDLE_EXTRACT_BASE_DIR को सेट किए बिना बॉक्स रनेबिलिटी से बाहर निकलने के लिए मैं इसे /tmp/.net में बदलने का प्रस्ताव करता हूं। या शायद सामान्य स्थानों पर कई प्रयास होने चाहिए (/ var/tmp,/tmp, बाइनरी के समान निर्देशिका, आदि)

@ stevemk14ebr उस मुद्दे की रिपोर्ट करने के लिए धन्यवाद। क्या आप उस कार्य को ट्रैक करने के लिए कोई नया मामला दर्ज कर सकते हैं? https://github.com/dotnet/core-setup

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

@jeffschwMSFT उसी त्रुटि को .Net Core P9 से RC1 तक पारित करने के साथ फेंक दिया गया था।

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

@Safirion इस मुद्दे की रिपोर्ट करने के लिए धन्यवाद। क्या आप इसे पुन: पेश करने के लिए एक अलग मुद्दा बना सकते हैं? https://github.com/dotnet/core-setup
सीसी @ स्वरूप-श्रीधर

@Safirion क्या आप कृपया रेप्रो निर्देश भेज सकते हैं? क्या यह विफलता नियतात्मक है?
जैसा कि @jeffschwMSFT ने ऊपर सुझाव दिया है, कृपया कोर-सेटअप रेपो में समस्या दर्ज करें।

मैंने इसे देखा और यह तभी होगा जब ऐप ऐसे वातावरण में चल रहा हो जहां अस्थायी निर्देशिका पहुंच योग्य नहीं है। उदाहरण के लिए यदि मैं ऐसा करता हूं:

set "TMP=wrong_path"
myapp.exe

यह विफल रहता है

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

ध्यान दें कि बंडल GetTempPath win32 API का उपयोग करके अस्थायी निर्देशिका की तलाश करता है। जो env का उपयोग करता है। चर TMP , उसके बाद TEMP और इसी तरह। यदि मान के साथ पहले में अमान्य पथ है, तो यह इस तरह विफल हो जाएगा।

आप या तो यह सुनिश्चित करके इसे ठीक कर सकते हैं कि अस्थायी पथ सही तरीके से सेट है, या आप स्पष्ट रूप से DOTNET_BUNDLE_EXTRACT_BASE_DIR को उस स्थान पर सेट कर सकते हैं जहां आप निष्कर्षण करना चाहते हैं।

@Safirion क्या आप कृपया रेप्रो निर्देश भेज सकते हैं? क्या यह विफलता नियतात्मक है?
जैसा कि @jeffschwMSFT ने ऊपर सुझाव दिया है, कृपया कोर-सेटअप रेपो में समस्या दर्ज करें।

मैं नेट कोर को RC1 में अपडेट करने और अपने सर्वर को पुनरारंभ करने के बाद इस समस्या को पुन: उत्पन्न करने में सक्षम नहीं हूं। (मैंने RC1 की स्थापना रद्द करने और RC1 में फिर से अपग्रेड करने के लिए पूर्वावलोकन 9 को फिर से स्थापित करने का प्रयास किया है लेकिन मेरा ऐप इस बार अच्छी तरह से लॉन्च हुआ)

यह त्रुटि SDK 3.0 P7 से SDK 3.0 P8 और SDK 3.0 P9 से SDK 3.0 RC1 तक जाने के साथ हुई है।
और दो मामलों में, सर्वर का एक साधारण पुनरारंभ समस्या को ठीक करता है।

जब मैंने RC1 में अपग्रेड किया है तो मैं एक .Net Core Windows सेवा (सिस्टम द्वारा लॉन्च होने के बाद से निकालने के लिए C:\Windows\Temp\.net फ़ोल्डर का उपयोग करने वाला कार्यकर्ता) और एक .Net Core WPF ऐप (उपयोगकर्ता स्टार्टअप सत्र स्क्रिप्ट द्वारा लॉन्च) का उपयोग करता हूं। हो सकता है कि यह त्रुटि .NET कोर एसडीके इंस्टॉल के दौरान चल रहे नेट कोर वर्कर के कारण हो, मुझे नहीं पता ...

ध्यान दें कि मैं एसडीके स्थापित करता हूं और रनटाइम नहीं क्योंकि मुझे एक ही समय में 3 कोर रनटाइम (एएसपीनेट कोर, डेस्कटॉप .नेट कोर और कोर) को तैनात करना पड़ता है और https://dot.net हमें "पूर्ण रनटाइम" नहीं देता है इंस्टॉलर" (मुझे डेस्कटॉप रनटाइम इंस्टॉलर भी नहीं मिला, कोई विकल्प नहीं) ...

अद्यतन: कोई बात नहीं, दस्तावेज़ीकरण मिला।

अरे वहाँ, आपकी कड़ी मेहनत के लिए धन्यवाद!

कॉन्फ़िगरेशन फ़ाइलें (उदाहरण के लिए App.config) कैसे वितरित की जानी चाहिए? मैंने अभी सटीक कमांड अनुक्रम के साथ RHEL 7.6 पर एक कंसोल ऐप बनाया है:

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

जहां SomeProj.csproj में <PublishTrimmed>true</PublishTrimmed> सक्षम है, और परिणाम के रूप में 2 फ़ाइलें मिली हैं: SomeProj.exe और SomeProj.pdb , लेकिन SomeProj.config नहीं

@catlion *.config फ़ाइलों के लिए डिफ़ॉल्ट व्यवहार करने के लिए, उन्हें बंडल से बाहर रखा जाना चाहिए। डिफ़ॉल्ट रूप से सभी गैर पीडीबी फाइलें बंडल में शामिल होती हैं।
निम्नलिखित एकल फ़ाइल से कॉन्फ़िगरेशन को बाहर कर देगा:

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

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

@morganbr

आप किस प्रकार के ऐप के साथ इसका उपयोग करने की संभावना रखते हैं? (उदाहरण के लिए विंडोज़ पर डब्ल्यूपीएफ? एएसपी.नेट एक लिनक्स डॉकर कंटेनर में? कुछ और?)

विंडोज़ के लिए हेडलेस और डब्ल्यूपीएफ ऐप्स

क्या आपके ऐप में (गैर-.NET) C++/मूल कोड शामिल है?

हां, हम विभिन्न प्रकार के देशी डीएलएस को पी/आमंत्रित करते हैं, कुछ तृतीय-पक्ष आइटम जिन पर हमारा कोई नियंत्रण नहीं है, कुछ अन्य टीमों से आंतरिक हैं।

क्या आपका ऐप प्लगइन्स या अन्य बाहरी डीएलएस लोड करेगा जिन्हें आपने मूल रूप से अपने ऐप बिल्ड में शामिल नहीं किया था?

हां, लेकिन हम उन्हें स्रोत से संकलित करने के लिए कंपाइलर सर्विसेज का उपयोग करते हैं।

क्या आप सुरक्षा सुधारों को शामिल करने के लिए अपने ऐप का पुनर्निर्माण और पुनर्वितरण करने के इच्छुक हैं?

हां

यदि आपका ऐप 200-500 ms अधिक धीमी गति से शुरू होता है तो क्या आप इसका उपयोग करेंगे? 5 सेकंड के बारे में क्या?

हां, हमारा ऐप आम तौर पर लंबे समय तक खुला रहता है।

क्या आप आकार और/या स्टार्टअप समय को अनुकूलित करने के लिए एक लंबा रिलीज़ बिल्ड समय स्वीकार करेंगे? आप सबसे लंबे समय तक क्या स्वीकार करेंगे? 15 सेकंड? 30 सेकंड? 1 मिनट? 5 मिनट?

हां, हम कई मिनट प्रतीक्षा कर सकते हैं।

क्या आप अतिरिक्त काम करने के इच्छुक होंगे यदि यह आपके ऐप के आकार को आधा कर देगा?

हां

धन्यवाद @ जॉन-कुलेन

निष्कर्षण के बिना सिंगल-फाइल ऐप्स चलाने के प्रोटोटाइप कार्यान्वयन के लिए कुछ पीआर को सिंगल-एक्सई शाखा से जोड़ना ( चरण 4 )।

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

मुझे @morganbr के लिए कुछ उत्तर भी दें :) मुझे नहीं पता कि क्या आप अभी भी इन्हें पढ़ते हैं :)

1. आप किस प्रकार के ऐप के साथ इसका उपयोग करने की संभावना रखते हैं? (उदाहरण के लिए विंडोज़ पर डब्ल्यूपीएफ? एएसपी.नेट एक लिनक्स डॉकर कंटेनर में? कुछ और?)

विभिन्न प्लेटफार्मों (लिनक्स, मैकओएस, विंडोज) पर चलने के लिए टेक्स्ट एडवेंचर्स (कंसोल ऐप्स)

1. क्या आपके ऐप में (गैर-.NET) C++/मूल कोड शामिल है?

नहीं।

1. क्या आपका ऐप प्लगइन्स या अन्य बाहरी डीएलएस लोड करेगा जिन्हें आपने मूल रूप से अपने ऐप बिल्ड में शामिल नहीं किया था?

वर्तमान में नहीं, लेकिन कुछ परिदृश्यों का समर्थन करने के लिए लंबे समय में यह बहुत अच्छा होगा।

1. क्या आप सुरक्षा सुधारों को शामिल करने के लिए अपने ऐप का पुनर्निर्माण और पुनर्वितरण करने के इच्छुक हैं?

हां।

1. यदि आपका ऐप 200-500 ms अधिक धीमी गति से शुरू होता है तो क्या आप इसका उपयोग करेंगे? 5 सेकंड के बारे में क्या?

हां।
(उपयोगकर्ता को कुछ हो रहा है यह सूचित करने के लिए कुछ टेक्स्ट आउटपुट या संदेश बॉक्स प्रदान करना बहुत अच्छा होगा)

1. आप अपने ऐप के लिए स्वीकार्य सबसे बड़ा आकार क्या मानेंगे? 5 एमबी? 10? 20? 50? 75? 100?

10-20 एमबी।

1. क्या आप आकार और/या स्टार्टअप समय को अनुकूलित करने के लिए एक लंबा रिलीज़ बिल्ड समय स्वीकार करेंगे? आप सबसे लंबे समय तक क्या स्वीकार करेंगे? 15 सेकंड? 30 सेकंड? 1 मिनट? 5 मिनट?

1+ मिनट ठीक है।

1. क्या आप अतिरिक्त काम करने के इच्छुक होंगे यदि यह आपके ऐप के आकार को आधा कर देगा?

संभवतः।

प्रतिक्रिया के लिए धन्यवाद, @lenardg।

यह समस्या .NET Core 3.0 एकल-फ़ाइल वितरण सुविधा पर प्रगति को ट्रैक करती है।
यहाँ सुविधा के लिए डिज़ाइन दस्तावेज़ और स्टेजिंग योजना है।

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

1. सशर्त रूप से एकल निष्पादन योग्य पैक करते समय संपीड़ित करना संभव है?
   यानी रैप को लॉजिक की तरह जोड़ें, इसलिए हमें अन्य टूल्स इंटीग्रेशन की जरूरत नहीं है।
   संपीड़ित और भी छोटे exe का उत्पादन करेगा।

2. Exe लॉन्च करते समय, यह अपनी सामग्री को एक अस्थायी फ़ोल्डर में विस्तारित करता है। हमारे उत्पाद के लिए, कुछ उपयोगकर्ता साइटों पर, क्लाइंट मशीनों को कसकर नियंत्रित किया जाता है और वे निष्पादन योग्य को अस्थायी फ़ोल्डर या यहां तक ​​कि %userprofile% स्थानों से लॉन्च करने की अनुमति नहीं देते हैं।

क्या यह निर्दिष्ट करना/नियंत्रित करना संभव है कि ".\extract" या ऐसे सबफ़ोल्डर में कहां से निकालना है या 'इन प्लेस एक्सट्रैक्ट' हो सकता है?
यह समूह नीतियों के अनुपालन के साथ-साथ एकल exe सुविधा का उपयोग करने की क्षमता की अनुमति देता है।

1. पैकिंग करने से पहले, क्या फ़ोल्डर पर हस्ताक्षर करना संभव है और फिर वह पैक करने के लिए फ़ाइलें चुनता है?
   हम एकल exe पर हस्ताक्षर कर सकते हैं, लेकिन फ़ाइलों को निकालने पर हस्ताक्षर नहीं किए जाते हैं, और इसलिए कुछ अन्य क्लाइंट स्थानों पर, यह निष्पादन की अनुमति नहीं देता है, जब तक कि बायनेरिज़ पर हस्ताक्षर नहीं किए जाते हैं।

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

बस आपको बताना चाहता था, मैंने आज @Safirion जैसा ही मुद्दा देखा। मेरे पास उबंटू को लक्षित एक डॉटनेटकोर 3.0 ऐप है, और इसे मेरे सिनोलॉजी सर्वर पर चलाने के लिए चला गया। यह नहीं निकालेगा - एक त्रुटि के साथ विफल रहता है "एक घातक त्रुटि का सामना करना पड़ा। बंडल की सामग्री को नहीं निकाला जा सका"। कई बार पुनर्निर्माण किया, लेकिन एक ही बात। होस्ट को रिबूट करने के बाद, इसने फिर से ठीक काम किया।

यह समझने में उपयोगी होगा कि यहां कोई फ़ाइल लॉक या कुछ है, और यदि इसे डीबग करने के बारे में कोई समय है।

@RajeshAKumar डॉटनेट /कोर-सेटअप#7940

मुझे यकीन नहीं है कि यह लिंक कैसे मदद करता है।
यह सिर्फ अस्थायी निकासी के बारे में बात करता है, मैंने ऊपर 3 अंक सूचीबद्ध किए हैं।

और मैंने आपको उनमें से एक के लिए समाधान दिया। मुझे अन्य 2 . के बारे में कोई जानकारी नहीं है

और मैंने आपको उनमें से एक के लिए समाधान दिया। मुझे अन्य 2 . के बारे में कोई जानकारी नहीं है

अस्थायी अर्क हमारे लिए काम नहीं करता है, इसलिए यह समाधान नहीं है। मेरा अनुरोध यह नियंत्रित करने की क्षमता थी कि यह सबफ़ोल्डर में कहां से निकालता है या जगह में निकाला जा सकता है।
हमारे कई क्लाइंट कंप्यूटरों पर आईटी व्यवस्थापक अस्थायी फ़ोल्डरों या उपयोगकर्ता प्रोफ़ाइल से निष्पादन योग्य (ओं) को चलाने की अनुमति नहीं देते हैं।
कृपया पोस्ट को फिर से पढ़ें https://github.com/dotnet/coreclr/issues/20287#issuecomment -542497711

@RajeshAKumar : आप आधार पथ को नियंत्रित करने के लिए DOTNET_BUNDLE_EXTRACT_BASE_DIR सेट कर सकते हैं जहां होस्ट बंडल की सामग्री को निकालता है।
कृपया अधिक विवरण यहां देखें: https://github.com/dotnet/designs/blob/master/accepted/single-file/extract.md#extraction -location

@RajeshAKumar : बंडल किए गए सिंगल-एक्सई का संपीड़न .net 5 के लिए विचाराधीन एक विशेषता है: https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md#compression

अभी के लिए, आपको उत्पन्न एकल-exe को संपीड़ित करने के लिए अन्य उपयोगिताओं का उपयोग करने की आवश्यकता होगी।

@RajeshAKumar , हस्ताक्षर करने के संबंध में, आप उन सभी फाइलों/बाइनरी पर हस्ताक्षर कर सकते हैं जो प्रकाशित हो जाती हैं और सिंगल-एक्सई में बंडल हो जाती हैं। जब होस्ट डिस्क पर एम्बेडेड घटकों को निकालता है, तो अलग-अलग फाइलों पर स्वयं हस्ताक्षर किए जाएंगे। जैसा कि आपने उल्लेख किया है, आप स्वयं निर्मित एकल-फ़ाइल पर भी हस्ताक्षर कर सकते हैं।

क्या यह आपकी आवश्यकताओं को पूरा करता है?

@Webreaper यदि आप समस्या को दोहरा सकते हैं, तो क्या आप कृपया ऐप को COREHOST_TRACE चालू करके चला सकते हैं ( COREHOST_TRACE पर्यावरण चर को 1 पर सेट करें) और जेनरेट किए गए लॉग को साझा करें? धन्यवाद।

@स्वरूप-श्रीधर
यह बहुत ही मस्त फीचर है। क्या आपके पास कोई लिंक है कि किस डॉटनेट रिलीज में विभिन्न चरण कब उपलब्ध होंगे?

@RajeshAKumar : आप आधार पथ को नियंत्रित करने के लिए DOTNET_BUNDLE_EXTRACT_BASE_DIR सेट कर सकते हैं जहां होस्ट बंडल की सामग्री को निकालता है।
कृपया अधिक विवरण यहां देखें: https://github.com/dotnet/designs/blob/master/accepted/single-file/extract.md#extraction -location

धन्यवाद स्वरूप-श्रीधर

@RajeshAKumar , हस्ताक्षर करने के संबंध में, आप उन सभी फाइलों/बाइनरी पर हस्ताक्षर कर सकते हैं जो प्रकाशित हो जाती हैं और सिंगल-एक्सई में बंडल हो जाती हैं। जब होस्ट डिस्क पर एम्बेडेड घटकों को निकालता है, तो अलग-अलग फाइलों पर स्वयं हस्ताक्षर किए जाएंगे। जैसा कि आपने उल्लेख किया है, आप स्वयं निर्मित एकल-फ़ाइल पर भी हस्ताक्षर कर सकते हैं।

क्या यह आपकी आवश्यकताओं को पूरा करता है?

मैं यह पता लगाने की कोशिश कर रहा हूं कि 'संकलन' को कैसे तोड़ा जाए और भागों को प्रकाशित किया जाए।
मैं वर्तमान में निम्न कमांड का उपयोग करता हूं, इसलिए यह मुझे हस्ताक्षर करने की क्षमता नहीं देता है।
publishargs सेट करें=-c रिलीज़/p:PublishSingleFile=True/p:PublishTrimmed=True/p:PublishReadyToRun=false
डॉटनेट पब्लिश -r win-x64 -o bin\Output\Win64 %publishargs%

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

@Webreaper यदि आप समस्या को दोहरा सकते हैं, तो क्या आप कृपया ऐप को COREHOST_TRACE चालू करके चला सकते हैं ( COREHOST_TRACE पर्यावरण चर को 1 पर सेट करें) और जेनरेट किए गए लॉग को साझा करें? धन्यवाद।

धन्यवाद। यह अब चला गया है क्योंकि मैंने रीबूट किया है, लेकिन यह नोट करना उपयोगी है कि यह फिर से होता है!

@RajeshAKumar आपको हस्ताक्षर को उस लक्ष्य पर टैग करना होगा जो बंडल करने से ठीक पहले चलता है।
चूंकि आप PublishReadyToRun और PublishTrimmed का उपयोग कर रहे हैं, इसलिए आप मानक Afterbuild या BeforePublish लक्ष्यों का उपयोग नहीं कर सकते।

आप एक लक्ष्य जोड़ सकते हैं जो BundlePublishDirectory से ठीक पहले चलता है और हस्ताक्षर करता है।

@स्वरूप-श्रीधर
यह बहुत ही मस्त फीचर है। क्या आपके पास कोई लिंक है कि किस डॉटनेट रिलीज में विभिन्न चरण कब उपलब्ध होंगे?

धन्यवाद @etherealjoy। बंडल से सीधे चलने वाली एकल-फ़ाइलों के लिए कार्य प्रगति पर है, मेरी सर्वोत्तम समझ के लिए .net 5 रिलीज़ को लक्षित करना।

@RajeshAKumar आपको हस्ताक्षर को उस लक्ष्य पर टैग करना होगा जो बंडल करने से ठीक पहले चलता है।
चूंकि आप PublishReadyToRun और PublishTrimmed का उपयोग कर रहे हैं, इसलिए आप मानक Afterbuild या BeforePublish लक्ष्यों का उपयोग नहीं कर सकते।

आप एक लक्ष्य जोड़ सकते हैं जो BundlePublishDirectory से ठीक पहले चलता है और हस्ताक्षर करता है।

धन्यवाद।
आपके द्वारा दिया गया लिंक MS Build कार्यों जैसा दिखता है।
मैं "BundlePublishDirectory" के लिए एक हैंडलर कैसे बनाऊं? क्या यह स्टूडियो/प्रोजेक्ट प्रॉप्स/बिल्ड इवेंट्स में है या क्या मुझे स्क्रैच से कुछ बनाना है।

@RajeshAKumar इस मामले में, आपको प्री-बिल्ड पोस्ट-बिल्ड इवेंट्स की तुलना में कुछ और बढ़िया चाहिए।
तो, मुझे लगता है कि आपको प्रोजेक्ट फ़ाइल को संपादित करना चाहिए और कुछ ऐसा जोड़ना चाहिए:

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

इसके साथ dotnet pack कमांड का अपेक्षित व्यवहार क्या है? मान लें कि हमारे पास सिंगल-एक्स आर्टिफैक्ट है जिसे स्थानीय नगेट रिपॉजिटरी में धकेल दिया गया है। अगर मैं इसे चॉकलेट के साथ स्थापित करने का प्रयास करता हूं, तो यह प्रोजेक्ट फ़ाइल में सूचीबद्ध सभी नगेट डिप्स को पुनर्स्थापित करने का प्रयास करता है। जो पहले अपेक्षित था, लेकिन मुझे संदेह है कि क्या यह व्यवहार SFD के लिए सही है।

क्या सिंगल-फाइल सेल्फ-निहित wpf एप्लिकेशन के निष्कर्षण के दौरान कुछ प्रगति पट्टी या लोडिंग इंडिकेटर जोड़ना संभव है, इसमें कुछ भी नहीं होने के साथ कुछ समय लग सकता है।
एक मूल स्व-निहित wpf ऐप 80Mo से अधिक है और निष्कर्षण में 5sec से अधिक समय लग सकता है। यह बहुत उपयोगकर्ता के अनुकूल नहीं है और मुझे अपने अंतिम उपयोगकर्ताओं से शिकायतें मिली हैं।

संपादित करें: लॉन्च के समय पुराने संस्करण को स्वचालित रूप से साफ करने का कोई तरीका?

@Safirion मैं नहीं देख सकता कि यह इस सुविधा के दायरे में कैसे हो सकता है। यदि आपको आवश्यकता है कि आपको अपना छोटा ऐप बनाकर सबसे अच्छी सेवा दी जाएगी जो स्प्लैश स्क्रीन दिखाता है और असली ऐप लॉन्च करता है, और फिर असली ऐप स्प्लैशस्क्रीन प्रोग्राम को शुरू होने पर रोक देता है।

@ProfessionalNihilist मुझे लगता है कि आप मेरी बात को नहीं समझते हैं।
संकलित होने पर एक खाली wpf ऐप स्वयं निहित 80mo डिस्क स्टोरेज का उपयोग करता है। फ्रेमवर्क पर निर्भर ऐप के रूप में संकलित किए बिना आपके पास 80mo से छोटा wpf ऐप नहीं हो सकता है
समस्या ऐप लॉन्च होने से पहले शामिल ढांचे के निष्कर्षण का समय है। तो यह .Net Core द्वारा किया जाना है और यह पूरी तरह से इस फीचर से संबंधित है।

हो सकता है कि एक png होने की क्षमता जोड़ें जो ऐप के डिकम्प्रेस्ड होने पर दिखाया जाएगा?

@Safirion @ayende स्टार्टअप के दौरान "यूआई फीडबैक" की कमी को यहां ट्रैक किया गया है: https://github.com/dotnet/core-setup/issues/7250

इसके साथ dotnet pack कमांड का अपेक्षित व्यवहार क्या है? मान लें कि हमारे पास सिंगल-एक्स आर्टिफैक्ट है जिसे स्थानीय नगेट रिपॉजिटरी में धकेल दिया गया है। अगर मैं इसे चॉकलेट के साथ स्थापित करने का प्रयास करता हूं, तो यह प्रोजेक्ट फ़ाइल में सूचीबद्ध सभी नगेट डिप्स को पुनर्स्थापित करने का प्रयास करता है। जो पहले अपेक्षित था, लेकिन मुझे संदेह है कि क्या यह व्यवहार SFD के लिए सही है।

@catlion PublishSingleFile संपत्ति केवल dotnet publish कमांड द्वारा समर्थित है। इसलिए, इसका dotnet pack पर कोई प्रभाव नहीं पड़ता है। क्या सिंगल-फाइल और पैकेजिंग दोनों का उपयोग करने की प्रेरणा है?

संपादित करें: लॉन्च के समय पुराने संस्करण को स्वचालित रूप से साफ करने का कोई तरीका?

@Safirion वर्तमान रिलीज में, सफाई मैनुअल है, होस्ट निकाली गई फ़ाइलों को हटाने का प्रयास नहीं करता है, क्योंकि भविष्य में चलने पर उन्हें संभावित रूप से पुन: उपयोग किया जा सकता है।

ठीक है, मैं अपना क्लीनर खुद बना लूँगी
आपके जवाब के लिए धन्यवाद।

@cup जो मोनो के बारे में कुछ खास नहीं है, यह सिर्फ एक मानक संकलन है, अब एक nuget संदर्भ जोड़ें और वह समाधान अब एक फ़ाइल नहीं है। मोनो के पास mkbundle है, हालांकि एकल फ़ाइल प्राप्त करने के लिए

@ सुचिमन क्या आप निश्चित हैं? उपरोक्त मेरा उदाहरण एक 3 केबी फ़ाइल उत्पन्न करता है। जबकि डॉटनेट न्यूनतम आकार 27 एमबी लगता है:

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

@कप हाँ

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

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

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


    Verzeichnis: C:\Users\Robin


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

@ सुचिमन क्या आप निश्चित हैं? उपरोक्त मेरा उदाहरण एक 3 केबी फ़ाइल उत्पन्न करता है। जबकि डॉटनेट न्यूनतम आकार 27 एमबी लगता है:

#24397 (टिप्पणी)

आपकी 3k फ़ाइल केवल इसलिए काम करती है क्योंकि मोनो पहले से स्थापित है। dotnetcore सिंगल फाइल डिस्ट्रीब्यूशन का पूरा बिंदु यह है कि आपको clr इंस्टॉल करने की आवश्यकता नहीं है, यह रनटाइम सहित एक स्टैंडअलोन सिंगल एक्सई है।

@Webreaper वास्तव में मेरा मानना ​​​​है कि यह केवल मोनो से संकलित करने के लिए एमसीएस का उपयोग करता है, क्योंकि उसने mono sun-mon.exe नहीं लिखा था, यह संभवतः .NET फ्रेमवर्क पर चलता था।

लेकिन .NET कोर रनटाइम को प्रीइंस्टॉल्ड परिदृश्य के साथ-साथ उर्फ ​​​​फ्रेमवर्क निर्भर परिनियोजन का समर्थन करता है। उस मामले में यह अभी भी काफी एकल फ़ाइल परिनियोजन नहीं है, हालांकि .NET कोर के लिए कुछ अतिरिक्त फ़ाइलें हैं जैसे .deps.json और .runtimeconfig.json

@ chris3713 वर्तमान में exe स्थान तक पहुँचने का सबसे अच्छा तरीका PInvoke-ing से देशी एपीआई है। उदाहरण के लिए: GetModuleFileNameW (Null, <buffer>, <len>)

ऐसा लगता है कि Environment.CurrentDirectory एक बेहतर समाधान है, हालांकि मैंने अभी तक विंडोज़ के अलावा किसी अन्य चीज़ पर दोनों दृष्टिकोणों की कोशिश नहीं की है।

संपादित करें: नहीं। वह पथ आवेदन में विभिन्न प्रवेश बिंदुओं पर परिवर्तन के अधीन है। अच्छा नहीं।

थोड़ा संबंधित नोट पर, मुझे मैक के लिए वीएस के नवीनतम पूर्वावलोकन में ब्लेज़र ऐप्स के एकल-फ़ाइल प्रकाशन में यह प्रतिगमन मिला: https://github.com/aspnet/AspNetCore/issues/17079 - मैंने इसकी रिपोर्ट की है इसके तहत AspNeCore/Blazor, लेकिन हो सकता है कि यह coreclr समूह के लिए अधिक प्रासंगिक हो - सुनिश्चित नहीं है। इसे आप लोगों के घूमने के लिए छोड़ देंगे!

@ सुचिमन सावधान, उस कंपाइलर में समस्याएं हैं:

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

@cup सिवाय इसके कि मेरे द्वारा नामित फ़ाइल पथ का उपयोग करके, आप C ++ में लिखे गए पुराने C# 5 कंपाइलर का उपयोग कर रहे हैं, जो कि roslyn नहीं है और वे शायद उस कारण से उस मुद्दे को बंद कर देंगे। लेकिन रोसलिन वही काम कर सकती है, बस एक अलग रास्ता...

थोड़ा संबंधित नोट पर, मुझे मैक के लिए वीएस के नवीनतम पूर्वावलोकन में ब्लेज़र ऐप्स के सिंगल-फाइल प्रकाशन में यह प्रतिगमन मिला: aspnet/AspNetCore#17079 - मैंने इसे AspNeCore/Blazor के तहत रिपोर्ट किया है, लेकिन यह हो सकता है कि यह coreclr समूह के लिए अधिक प्रासंगिक है - निश्चित नहीं। इसे आप लोगों के घूमने के लिए छोड़ देंगे!

@Webreaper इस मुद्दे की रिपोर्ट करने के लिए धन्यवाद, जो स्थिर संपत्तियों के संबंध में एएसपीनेट मुद्दे की तरह दिखता है। तो, इसे दर्ज करने के लिए यह सही जगह है।

* पोस्ट को अन्य मुद्दे से यहाँ स्थानांतरित करना।

@ स्वरूप-श्रीधर,

DotNet Core Single File wpf ऐप्स का स्टार्टअप समय मूल ILMerge-ed wpf एप्लिकेशन के .net 4.7 पर निर्मित होने की तुलना में बहुत धीमा है। क्या इसकी उम्मीद की जानी चाहिए या भविष्य में इसमें सुधार होगा?

बिल्ड मेरे इमेजऑप्टिमाइज़र से आते हैं: https://github.com/devedse/DeveImageOptimizerWPF/releases

| प्रकार | अनुमानित पहला स्टार्टअप समय | अनुमानित दूसरा स्टार्टअप समय | आकार | डाउनलोड लिंक |
| -- | -- | -- | -- | -- |
| .NET 4.7.0 + ILMerge | ~3 सेकंड | ~1 सेकंड | 39.3mb | लिंक |
| डॉटनेट पब्लिश -आर विन-एक्स 64 -सी रिलीज - सेल्फ-निहित = गलत / पी: पब्लिशसिंगलफाइल = सच | ~10 सेकंड | ~3 सेकंड | 49एमबी | |
| डॉटनेट प्रकाशित -r win-x64 -c रिलीज /p:PublishSingleFile=true | ~19 सेकंड | ~2 सेकंड | 201 एमबी | |
| डॉटनेट पब्लिश -आर विन-एक्स 64 -सी रिलीज / पी: पब्लिशसिंगलफाइल = ट्रू / पी: पब्लिश ट्रिम्ड = ट्रू | ~15 सेकंड | ~3 सेकंड | 136mb | लिंक |
| डॉटनेट पब्लिश-आर विन-एक्स64-सी रिलीज | ~2.5 सेकंड | ~1.5 सेकंड | exe के लिए 223kb (dll में +400mb) | |

@devedse , यह सुनिश्चित करने के लिए, "दूसरा स्टार्टअप" कई रनों का औसत है (पहले के अलावा)?
मैं उत्सुक हूं, लेकिन इस बात के लिए कोई स्पष्टीकरण नहीं है कि /p:PublishSingleFile=true /p:PublishTrimmed=true रन ` /p:PublishSingleFile=true रन से धीमा क्यों होना चाहिए।

इसलिए, जांच करने से पहले, मैं यह सुनिश्चित करना चाहता हूं कि "दूसरे स्टार्टअप" में संख्याएं स्थिर संख्याएं हैं और स्टार्टअप में अंतर प्रतिलिपि प्रस्तुत करने योग्य है,

साथ ही, यह मुद्दा सिंगल-फाइल प्लगइन्स के बारे में है, क्या आप कृपया पूर्ण चर्चा को एक नए मुद्दे पर ले जा सकते हैं, या dotnet/coreclr#20287 पर? धन्यवाद।

@ स्वरूप-श्रीधर, औसत होने के बारे में आपके प्रश्न के उत्तर में:
यह मेरे लिए बहुत सटीक समय के लिए थोड़ा कठिन है, इसलिए आवेदन शुरू होने के दौरान गिनती करके समय किया गया था और फिर यह देखने के लिए कुछ बार कोशिश कर रहा था कि स्टार्टअप समय में कोई महत्वपूर्ण अंतर है या नहीं। यदि आप एक बेहतर विधि के बारे में जानते हैं तो आप मेरे समाधान का निर्माण करके इसे आसानी से पुन: उत्पन्न कर सकते हैं: https://github.com/devedse/DeveImageOptimizerWPF

मेरा मुख्य प्रश्न इस बात से संबंधित है कि एक बंडल (एकल फ़ाइल) एप्लिकेशन के लिए एक अनबंडल .exe फ़ाइल की तुलना में शुरू होने में अधिक समय क्यों लगता है।

मैं यहां गलत हो सकता हूं लेकिन यह मेरे लिए समझ में आता है क्योंकि एक फाइल के साथ ओवरहेड है। अनिवार्य रूप से आपके पास एक ऐप है जो एक और ऐप शुरू कर रहा है। जबकि ILMerge सीधे शुरू हो रहा है। ILMerge ने केवल संदर्भित dll को exe में मर्ज किया है, इसने पूरी चीज़ को किसी अन्य परत में लपेटा नहीं है जो कि वर्तमान में PublishSingleFile के साथ किया जा रहा है।

@devedse डॉटनेट रन शुरू करने से पहले सिंगल फाइल अनिवार्य रूप से एक्सट्रेक्ट कर रही है, चेकसम आदि की जांच कर रही है।
लगता है इसीलिए इतना समय लगा।
अर्क "कैश्ड" है, इसलिए अगला रन, कोई IO ओवरहेड नहीं है।

@RajeshAKumar , हम्म वास्तव में इस परिदृश्य में जाने का रास्ता निकाल रहा है? क्या ILMerge के रास्ते पर जाना और वास्तव में DLL को एक ही बंडल में मिलाना बेहतर नहीं होगा?

विशेष रूप से बड़ी .exe फ़ाइलों के लिए आप सभी फ़ाइलों को दो बार संग्रहीत करने की डिस्क स्थान लागत को भी प्रेरित कर रहे हैं।

@devedse हम सभी इस सुविधा के अगले चरण (बंडल से चलाएँ) की प्रतीक्षा कर रहे हैं, लेकिन अभी के लिए, यह एकमात्र समाधान है। मैं

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

डेस्कटॉप में जेआईटी का उपयोग करने के लिए आपको यही मिलता है, धीमा स्टार्टअप, ऐसा लगता है कि केवल ऐप्पल ही इसे समझ गया है

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

कैसे मापें: हमने ट्रेसिंग (विंडोज़ पर ईटीडब्ल्यू) का उपयोग किया - ऐसी घटनाएं होती हैं जब प्रक्रिया शुरू होती है और फिर रनटाइम घटनाएं होती हैं जिनका उपयोग इसके लिए किया जा सकता है - हालांकि यह बिल्कुल आसान नहीं है।

जैसा कि @Safirion द्वारा उल्लेख किया गया है, हम सिंगल-फाइल के लिए अगले सुधार पर काम कर रहे हैं, जिसे सीधे .exe से अधिकांश प्रबंधित कोड चलाना चाहिए (डिस्क पर कोई अर्क नहीं)। हालांकि अभी रिलीज ट्रेन का वादा नहीं कर सकते।

जेआईटी: सभी ढांचे को रेडी 2 रन (कोरएफएक्स, डब्ल्यूपीएफ) के साथ पूर्व-संकलित किया जाना चाहिए, इसलिए स्टार्टअप पर केवल एप्लिकेशन कोड ही जेआईटीड होना चाहिए। यह सही नहीं है, लेकिन इससे बहुत फर्क पड़ना चाहिए। ~ 1-2 सेकंड के स्टार्टअप समय को देखते हुए मुझे लगता है कि यह पहले से ही सभी परीक्षणों में इसका उपयोग कर रहा है।

सभी का धन्यवाद, मुझे अगले चरण की योजना के बारे में पता नहीं था। यह स्पष्ट करता है।

पहली शुरुआत बहुत धीमी होने की उम्मीद है - यह ऐप को डिस्क पर निकालता है - बहुत सारे आईओ।

ऐसा कभी नहीं होना चाहिए था, आप उपयोगकर्ता के अनुभव को डिज़ाइन द्वारा भयानक बनाते हैं, भयानक विकल्प, इस तरह आप उपयोगकर्ताओं को उस तकनीक से नफरत करते हैं जो डेवलपर उनके लिए उपयोग कर रहा है

जैसा कि @Safirion द्वारा उल्लेख किया गया है, हम सिंगल-फाइल के लिए अगले सुधार पर काम कर रहे हैं, जिसे सीधे .exe से अधिकांश प्रबंधित कोड चलाना चाहिए (डिस्क पर कोई अर्क नहीं)। हालांकि अभी रिलीज ट्रेन का वादा नहीं कर सकते।

अगर यह जल्द ही बदलने वाला है तो इसे अभी आधिकारिक तौर पर क्यों जारी करें? पूर्वावलोकन/प्रयोगात्मक के रूप में चिह्नित किया जाना चाहिए

मेरी राय में यह समय और संसाधनों की बर्बादी है, एओटी संकलन और ट्री-शेकिंग पर ध्यान केंद्रित करें, अपने सभी संसाधनों को वहां रखें, हैक्स के साथ रुकें

@RUSshy इतनी नफरत क्यों? यदि आप पहली बार लॉन्च करते समय स्टार्टअप में देरी नहीं चाहते हैं तो सिंगल-फाइल परिनियोजन का उपयोग न करें।

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

+1 मेरे मामले में, हमारे पास एकल exe उत्पन्न करने वाला एक बिल्ड डॉकर है, और ऐप चलाने के लिए एक अलग डॉकर है (डॉटनेट के बिना नियमित अल्पाइन डॉकर छवि का उपयोग करके)। बुलिड स्टेप के बाद, हम रनटाइम कंटेनर को एक बार और docker-commit लेयर को हॉट-लोड करते हैं। इसके बाद, हमने ढांचे पर निर्भर परिनियोजन की तुलना में कोई प्रदर्शन प्रतिगमन नहीं देखा है। एक बार लोड-से-बंडल फ़ाइल तंत्र लागू और भेज दिया जाता है, तो हम मध्यवर्ती हॉट-लोडिंग चरण को हटा देंगे।

@ vitek-karas, क्या "बंडल से लोड रनटाइम संपत्ति" सुविधा को ट्रैक करने में कोई समस्या है? यह समझने में रुचि रखते हैं कि किस प्रकार की बाधाएं हैं। :)

@ am11 हम वर्तमान में विस्तृत योजना तैयार कर रहे हैं। आप https://github.com/dotnet/coreclr/tree/single-exe में किए गए प्रोटोटाइप को देख सकते हैं। वास्तविक कार्यान्वयन शायद बहुत अलग नहीं होगा (जाहिर है बेहतर फैक्टरिंग और इसी तरह, लेकिन मूल विचार ध्वनि प्रतीत होता है)।

@Webreaper वेब ऐप्स के लिए, यह कोई समस्या नहीं है, लेकिन हो सकता है क्योंकि .Net Core 3 को अब wpf/WinForm विकास के लिए अनुशंसित किया गया है, और डेस्कटॉप एप्लिकेशन साझा करना .exe सौ में खो गया है। डीएलएल एक विकल्प नहीं है तो मैं कुल मिलाकर इस सुविधा के पहले चरण से संबंधित निराशा को समझें।
;)

और कोई भी उपयोगकर्ता आज exe पर फिर से क्लिक करने से पहले 10sec (या 3sec से अधिक) प्रतीक्षा नहीं करता है। तथ्य यह है कि कोई लोडिंग संकेतक नहीं है, इस सुविधा का दूसरा बड़ा मुद्दा है। दुर्भाग्य से, ऐसा लगता है कि लोडिंग इंडिकेटर नेट कोर 3.1 का हिस्सा नहीं होगा, इसलिए उपयोगकर्ताओं को धैर्य रखना होगा...

डेस्कटॉप डेवलपर्स वास्तव में चरण 2 की प्रतीक्षा कर रहे हैं, और मुझे उम्मीद है कि यह .Net 5 का हिस्सा होगा क्योंकि वास्तव में, .Net Core में डेस्कटॉप विकास अंतिम उपयोगकर्ताओं के लिए वास्तव में एक बुरा अनुभव है।

@RUSshy इतनी नफरत क्यों? यदि आप पहली बार लॉन्च करते समय स्टार्टअप में देरी नहीं चाहते हैं तो सिंगल-फाइल परिनियोजन का उपयोग न करें।

यह नफरत नहीं है, यह रचनात्मक और ईमानदार प्रतिक्रिया है, मुझे सी # और नेट की परवाह है, मैं हर रोज दोनों का उपयोग करता हूं, मैं नहीं चाहता कि इसे जीओ या कुछ और से बदला जाए

अभी अभी:
https://old.reddit.com/r/golang/comments/e1xri3/choosing_go_at_american_express/
https://old.reddit.com/r/golang/comments/ds2z51/the_stripe_cli_is_now_available_and_its_write/

नकारात्मक प्रतिक्रिया सकारात्मक प्रतिक्रिया की तरह ही सहायक होती है, लेकिन यदि आप इसे "नफरत" के रूप में लेते हैं तो मैं आपकी मदद नहीं कर सकता

.नेट समुदाय मौन, निष्क्रिय और पक्षपाती होने का रास्ता है, व्यवधान ही जाने का एकमात्र तरीका है

.NET इन दिनों अधिकांश अनुप्रयोगों के लिए वस्तुनिष्ठ रूप से सबसे अच्छा मंच है। काश और लोगों को यह एहसास होता।

जावा, गो, रस्ट, नोड, ... जैसे अन्य प्लेटफार्मों से मैं युद्ध की कहानियां सुनता हूं, स्पष्ट रूप से परेशान करने वाली हैं। ये प्लेटफॉर्म उत्पादकता हत्यारे हैं।

मेरी राय में यह समय और संसाधनों की बर्बादी है, एओटी संकलन और ट्री-शेकिंग पर ध्यान केंद्रित करें, अपने सभी संसाधनों को वहां रखें, हैक्स के साथ रुकें

मैं सहमत हूं। .Net में एक बेहतरीन टाइप सिस्टम है। कई बार प्रतिबिंब का उपयोग करके इसे दरकिनार कर दिया जाता है। टूलिंग को एओटी पर ध्यान देने की जरूरत है लेकिन प्रतिबिंब को कम करने पर भी। https://github.com/dotnet/corert/issues/7835#issuecomment -545087715 एक बहुत अच्छी शुरुआत होगी। नल की अरब डॉलर की गलती को अब कम किया जा रहा है; प्रतिबिंब-मुक्त कोड (या अन्यथा लिंकर या कोरर्ट संगत कोड) के लिए सेटिंग या मार्कर के साथ प्रतिबिंब के साथ भी ऐसा ही किया जाना चाहिए।

प्रतिबिंब को खत्म करना कमाल का होगा। यदि चिंतन पर प्रतिबंध लगा दिया जाए तो इतनी पीड़ा से बचा जा सकता है। मेरी सबसे हाल की डरावनी कहानी यह खोज रही थी कि मैं घटना कोड को इधर-उधर नहीं कर सकता क्योंकि इस्तेमाल किए गए ढांचे (सर्विस फैब्रिक एसडीके) ने बिना किसी ओवरराइड के सीरियलाइज़र कार्यान्वयन के असेंबली नाम में सीरियलाइज्ड बाइट्स को बाँधना विवेकपूर्ण पाया।

चिंतन को हतोत्साहित करने की दिशा में कोई प्रगति प्रगति होगी।

बीटीडब्ल्यू बंडल आकार और लोड समय को कम करने के लिए असेंबली को मर्ज करने का तरीका ढूंढ रहा था, पूरे प्रोग्राम ऑप्टिमाइज़ेशन की अनुमति देता है। मुझे लगता है कि यह मुद्दा वास्तव में उस पर लक्षित नहीं है।

संपादित करें: चूंकि इस पोस्ट ने स्पष्ट करने के लिए कुछ प्रतिक्रियाएं एकत्र की हैं। मेरा मानना ​​​​है कि मेटा प्रोग्रामिंग डिज़ाइन-टाइम पर होनी चाहिए, जहां कोड डेटा है, और यह मेरे नियंत्रण में है।

वे प्रकार जिन्हें मैं इनवेरिएंट को लागू करने के लिए उपयोग करना पसंद करता हूं जिन पर मैं भरोसा कर सकता हूं। रनटाइम प्रतिबिंब उस विश्वास को तोड़ देता है।

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

इस क्षेत्र के ग्राहकों को टैग करना: @swaroop-sridhar
यदि आप सदस्यता लेना चाहते हैं तो danmosemsft को सूचित करें।

इस दस्तावेज़ में सिंगल-फाइल फीचर डिज़ाइन है: https://github.com/dotnet/designs/blob/master/accepted/2020/single-file/design.md
इस मुद्दे में सिंगल-फाइल ऐप्स की ट्रैकिंग प्रगति: https://github.com/dotnet/runtime/issues/36590।
इस मुद्दे पर आपकी प्रतिक्रिया और सुझावों के लिए सभी को धन्यवाद।