Aws-lambda-dotnet: .NET कोर 3.1 (LTS) जारी किया गया है

यह एक एलटीएस है और इसका समर्थन किया जाएगा। लैम्ब्डा के लिए .NET Core 3.1 तैयार होने और तैनात होने में अभी कुछ समय लगेगा।

यह एक एलटीएस है और इसका समर्थन किया जाएगा। लैम्ब्डा के लिए .NET Core 3.1 तैयार होने और तैनात होने में बस कुछ समय लगेगा।

अगर मैं मदद करने के लिए कुछ कर सकता हूं, तो कृपया मुझे बताएं।

क्या ठंड शुरू होने के समय में तेजी आएगी?

.NET Core 3.1 में कुछ विशेषताएं हैं जैसे AOT कंपाइल

• PublishReadyToRun
• प्रकाशित छंटनी

@normj क्या लोगों को अपडेट के लिए इस मुद्दे की सदस्यता

हम अपडेट को ट्रैक करने के लिए इस समस्या का उपयोग कर सकते हैं। दुर्भाग्य से जब तक यह समाप्त नहीं हो जाता, तब तक मैं शायद अधिक स्थिति अपडेट प्रदान नहीं कर पाऊंगा।

क्या ठंड शुरू होने के समय में तेजी आएगी?

.NET Core 3.1 में कुछ विशेषताएं हैं जैसे AOT कंपाइल

• PublishReadyToRun
• प्रकाशित छंटनी

यदि उत्तर टिप्पणी के लिए हाँ है, तो क्या स्थानीय वातावरण से 'संकलित लैम्ब्डा' को चलाना और परीक्षण करना संभव होगा? मैं उत्सुकता से इसके लिए एक लिनक्स वातावरण स्थापित करूंगा :)

यहां कोई अपडेट?

@rati-dzidzigur

जैसा कि @normj . से ऊपर है

हम अपडेट को ट्रैक करने के लिए इस समस्या का उपयोग कर सकते हैं। दुर्भाग्य से जब तक यह समाप्त नहीं हो जाता, तब तक मैं शायद अधिक स्थिति अपडेट प्रदान नहीं कर पाऊंगा।

@beeradmoore
मेरा सवाल ईटीए के बारे में था। इसके लिए ईटीए जानना मददगार होगा क्योंकि हम उसके अनुसार तैयारी कर सकते हैं।

@rati-dzidziguri जब रिलीज की बात आती है तो अमेज़ॅन शायद ही कभी अपने ईटीए का खुलासा करता है।

@rati-dzidziguri मैं समझता हूं और आपकी सराहना करता हूं कि आप एक ईटीए चाहते हैं ताकि आप उसके अनुसार योजना बना सकें। वास्तव में यही कारण है कि हम आम तौर पर ईटीए नहीं देते हैं क्योंकि हम वादे नहीं करने के लिए वास्तव में कड़ी मेहनत करते हैं कि हम 100% सुनिश्चित नहीं हैं कि हम रख सकते हैं। मैं आपको एक ईटीए देने से नफरत करता हूं और आप उसके आधार पर अपना रोडमैप बनाते हैं और फिर हमें वह ईटीए याद आती है जिसकी आपने उम्मीद की थी कि आप अपनी सभी योजनाओं को अस्त-व्यस्त कर देंगे।

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

@normj एक कारण ने मुझे यह तय कर दिया कि मैं 'लैम्ब्डाएंट्री' वर्ग के साथ कस्टम रनटाइम सुविधा का उपयोग नहीं कर सकता, कार्यान्वयन दृष्टिकोण का 'मोनोलिथिक आर्किटेक्चरल' पहलू है। प्रत्येक एपीआई अनुरोध केवल एक प्रविष्टि लैम्ब्डा के माध्यम से आता है और एएसपी .net प्रोजेक्ट के नियंत्रकों को 'वितरित' किया जाता है, जो कस्टम रनटाइम संरचना का इरादा है, जो निश्चित रूप से सुविधाजनक है लेकिन इसमें मेरे जैसे मामलों के लिए संरचनात्मक नकारात्मक पक्ष शामिल है। मैं चाहता हूं कि प्रत्येक आदेश/क्वेरी प्रत्येक लैम्ब्डा बनने का अनुरोध करे। तब से मैं परिनियोजन पैकेजों के प्रबंधन पर एक मापनीयता प्राप्त कर सकता हूं कि मैं कुछ कार्यों को विभाजित कर सकता हूं और जब भी मैं चाहता हूं कोड प्रबंधित कर सकता हूं।
यही कारण है कि मैं आधिकारिक रनटाइम के समर्थित होने की प्रतीक्षा कर रहा हूं कि मैं 'रनटाइम: .netcore 3.1' कॉन्फिग के साथ टेम्पलेट में लिखे एसएएम का उपयोग करके 'सिंगल पर्पस लैम्ब्डा' का एक बंडल बना सकता हूं।

अगर मैं गलत हो रहा हूं तो कृपया मुझे सलाह दें :)

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

मेरे पास 16 लैम्ब्डा का एक सूट है जो एक "मोनोलिथ" के बजाय एक एप्लिकेशन से तैनात किया गया है।

यह ब्लॉग पोस्ट के नमूना कोड में दिखाए गए हार्ड-कोडेड वन-टू-वन मैपिंग के बजाय रनटाइम पर उपयोग करने के लिए विधि चुनने के लिए _handler पर्यावरण चर का उपयोग करके प्राप्त किया जाता है।

मैं इसे एक कंसोल ऐप के रूप में सोचता हूं जो एक स्विच प्राप्त करता है जो यह बताता है कि शुरू होने पर "बनने" के लिए क्या क्रिया है।

@मार्टिनकोस्टेलो
नेक सुझाव के लिए धन्यवाद! मैं समझ सकता हूं कि आपका मामला कैसा दिख सकता है। हो सकता है कि आपने स्विच लॉजिक को मेन या स्टार्टअप क्लास में रखा हो ताकि यह निर्धारित किया जा सके कि रनटाइम के पहले चरण में इसकी कार्यक्षमता है। और यह निश्चित रूप से 'एकमात्र-अखंड' मुद्दे को हल कर सकता है। बहुत चालाक दृष्टिकोण :)

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

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

इसे रिलीज करने के लिए आगे कुछ अच्छी तारीखें, 25 दिसंबर, 1 जनवरी याद आ रही हैं;)

सभी को छुट्टियाँ मुबारक, काश मैं आप सभी को क्रिसमस के लिए .NET Core 3.1 लैम्ब्डा रनटाइम दे पाता लेकिन मुझे लगता है कि 2020 आपके लिए .NET और AWS के लिए रोमांचक होने वाला है।

सभी को छुट्टियाँ मुबारक, काश मैं आप सभी को क्रिसमस के लिए .NET Core 3.1 लैम्ब्डा रनटाइम दे पाता लेकिन मुझे लगता है कि 2020 आपके लिए .NET और AWS के लिए रोमांचक होने वाला है।

कोई चिंता नहीं, छुट्टियों का आनंद लें! यह देखने के लिए इंतजार नहीं कर सकता कि आपके पास 2020 में हमारे लिए क्या है! :)

.NetCore3.1 पर लैम्ब्डा देशी समर्थन की प्रतीक्षा कर रहा है

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

क्या इस बारे में कोई अनुमान है कि हम इसे कब जारी किए जाने की उम्मीद कर सकते हैं?

हम नेट कोर 3.1 में अपग्रेड होने की प्रतीक्षा कर रहे हैं जब तक कि इसके लिए मूल समर्थन न हो।

क्या इस बारे में कोई अनुमान है कि हम इसे कब जारी किए जाने की उम्मीद कर सकते हैं?

हम नेट कोर 3.1 में अपग्रेड होने की प्रतीक्षा कर रहे हैं जब तक कि इसके लिए मूल समर्थन न हो।

यदि आप वापस जाते हैं और उत्तर पढ़ते हैं, तो आप मानक से पढ़ेंगे कि वे कोई अनुमान नहीं देंगे।

यदि आप वापस जाते हैं और उत्तर पढ़ते हैं, तो आप मानक से पढ़ेंगे कि वे कोई अनुमान नहीं देंगे।

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

मुझे कुछ समय पहले याद है जब एडब्ल्यूएस ने 2.1 देशी छवियों को तैयार करने में काफी समय बिताया था। उन्होंने इस आशय के लिए कुछ कहा कि उन्होंने भविष्य के संस्करणों की तैनाती को आसान और तेजी से स्टैंड-अप करने के लिए प्रक्रिया को फिर से डिजाइन किया। NetCore 3.1 और लगभग दो महीने बाद दर्ज करें और यह अभी भी उपलब्ध नहीं है :(

आप जानते हैं कि Azure के पास पहले दिन यह 3.1 छवि उपलब्ध थी। मैं यह देखना शुरू कर रहा हूँ कि अमेरिकी सरकार Azure को JEDI के लिए अपने क्लाउड प्रदाता के रूप में क्यों चुनती है।

AWS को बैकअप के रूप में छोड़कर हमें अपने प्राथमिक प्रदाता के रूप में Azure को लक्षित करना शुरू करने के लिए हमारे हितधारकों से हरी बत्ती मिली है। इस तरह की मूर्खतापूर्ण देरी के साथ, मुझे यकीन है कि हम अकेले नहीं हैं।

मुझे कुछ समय पहले याद है जब एडब्ल्यूएस ने 2.1 देशी छवियों को तैयार करने में काफी समय बिताया था। उन्होंने इस आशय के लिए कुछ कहा कि उन्होंने भविष्य के संस्करणों की तैनाती को आसान और तेजी से स्टैंड-अप करने के लिए प्रक्रिया को फिर से डिजाइन किया। NetCore 3.1 और लगभग दो महीने बाद दर्ज करें और यह अभी भी उपलब्ध नहीं है :(

आप जानते हैं कि Azure के पास पहले दिन यह 3.1 छवि उपलब्ध थी। मैं यह देखना शुरू कर रहा हूँ कि अमेरिकी सरकार Azure को JEDI के लिए अपने क्लाउड प्रदाता के रूप में क्यों चुनती है।

AWS को बैकअप के रूप में छोड़कर हमें अपने प्राथमिक प्रदाता के रूप में Azure को लक्षित करना शुरू करने के लिए हमारे हितधारकों से हरी बत्ती मिली है। इस तरह की मूर्खतापूर्ण देरी के साथ, मुझे यकीन है कि हम अकेले नहीं हैं।

मैं आपसे सहमत हूं। मेरा संगठन कस्टम रनटाइम की अनुमति नहीं देता है और हम 2.1 के साथ फंस गए हैं। जब स्थानिक संचालन के साथ-साथ EF और Postgres की बात आती है, तो यह बहुत अधिक दर्द होता है। हम इसके पूरा होने का इंतजार कर रहे हैं। यह बहुत बुरा है कि यह अभी तक नहीं किया गया है।

मुझे कुछ समय पहले याद है जब एडब्ल्यूएस ने 2.1 देशी छवियों को तैयार करने में काफी समय बिताया था। उन्होंने इस आशय के लिए कुछ कहा कि उन्होंने भविष्य के संस्करणों की तैनाती को आसान और तेजी से स्टैंड-अप करने के लिए प्रक्रिया को फिर से डिजाइन किया। NetCore 3.1 और लगभग दो महीने बाद दर्ज करें और यह अभी भी उपलब्ध नहीं है :(

आप जानते हैं कि Azure के पास पहले दिन यह 3.1 छवि उपलब्ध थी। मैं यह देखना शुरू कर रहा हूँ कि अमेरिकी सरकार Azure को JEDI के लिए अपने क्लाउड प्रदाता के रूप में क्यों चुनती है।

AWS को बैकअप के रूप में छोड़कर हमें अपने प्राथमिक प्रदाता के रूप में Azure को लक्षित करना शुरू करने के लिए हमारे हितधारकों से हरी बत्ती मिली है। इस तरह की मूर्खतापूर्ण देरी के साथ, मुझे यकीन है कि हम अकेले नहीं हैं।

क्या JEDI यह अनुमान लगाने के लिए .NET Core का उपयोग करता है कि सरकार Azure के साथ क्यों गई?

हेलो सब लोग,

मैं लैम्ब्डा में .NET कोर 3.1 के लिए समर्थन लाने पर सक्रिय रूप से काम कर रहा हूं। इसमें कुछ समय लगता है क्योंकि Microsoft द्वारा रनटाइम बनाने के तरीके में बहुत काम किया गया था। मैं आपको एक मूल रनटाइम लाने के लिए इन परिवर्तनों को शामिल करने पर काम कर रहा हूं।

@assyad धन्यवाद! मैं नहीं मानता कि देरी "मूर्खतापूर्ण" है; वास्तव में, मैं इसके बजाय एक ठोस कार्यशील संस्करण की प्रतीक्षा करूंगा। मुझे पसंद है कि एडब्ल्यूएस लैम्ब्डा .NET कोर का समर्थन करता है और मैं सराहना करता हूं कि आप वादे के अनुसार इसका समर्थन करना जारी रख रहे हैं।

मैं आग्रह नहीं समझता। ऐसा नहीं है कि हमारे पास अभी एलटीएस वातावरण नहीं है।

जाहिर है हम नए खिलौनों का उपयोग करना चाहते हैं लेकिन एडब्ल्यूएस में .NET टीम के पास केवल एक निश्चित मात्रा में संसाधन हैं और वे सब कुछ एक साथ नहीं कर सकते हैं।

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

आपके लिए अच्छा है @Kralizek लेकिन आपकी स्थिति आपकी है और दूसरों का प्रतिनिधित्व नहीं करती है। यह वास्तव में अब "नए खिलौने" नहीं है। .NET Core 3.x (और ASP.NET Core) में विभिन्न तरीकों से 2.x से अधिक महत्वपूर्ण सुधार हुए हैं और शुरुआती अपनाने वाले अपनाने और लाभ उठाने के इच्छुक हैं। जैसा कि @JamesQMurphy कहते हैं, हम यह भी पसंद करेंगे कि रिलीज़ ठोस हो।

मैं आपके काम @assyad को देखने के लिए उत्सुक हूं।

"मैं आग्रह को नहीं समझता।"

हम .NET कोर 2.1 लैम्ब्डा फ़ंक्शन में साझा .NET कोर 3.1 का उपयोग नहीं कर सकते हैं, वास्तव में हम .NET कोर 2.1 लैम्ब्डा फ़ंक्शन में साझा किए गए .NET कोर 2.2 कोड का उपयोग भी नहीं कर सकते हैं, इसलिए हमें हाल ही में अपने को डाउनग्रेड करना पड़ा फंक्शन में समर्थित होने के लिए घटकों को .NET Core 2.1 में साझा किया।

क्या आपके साझा घटकों को netstandard20 में संकलित किया जा सकता है? फिर आप उन्हें netcore2&3 . में साझा कर सकते हैं

जबकि यह धागा .NET 3.1 के लिए विशिष्ट है, मुझे यकीन है कि यह सटीक बातचीत फिर से चलाई जाएगी जब .NET 5 आएगा (या 6 अगर वह अगला एलटीएस होने जा रहा है)।

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

इस समय हम बस उस बिंदु पर होते हैं जहां नवीनतम रिलीज _भी होता है_ एक एलटीएस रिलीज होने के लिए, जो अमेज़ॅन से इसे "एएसएपी" की आवश्यकता बना रहा है, यह बहुत अधिक "तत्काल" लगता है कि यह था, कहते हैं, बिल्ट-इन 2.2 या 3.0 सपोर्ट।

अंततः लैम्ब्डा पर प्रयोग करने योग्य नई सुविधाओं के बीच एक व्यापार-बंद किया जाना है बनाम विकास प्रयासों को Paa समाधानों के साथ रखने की आवश्यकता है।

.NET Core 3.1 Microsoft की Azure ऐप सेवा के रिलीज़ होने के 2-3 सप्ताह बाद तक उपलब्ध नहीं था।

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

सब कुछ के साथ, एक संतुलन और एक व्यापार-बंद है, और अंतर्निहित समर्थन के लिए वास्तविक रूप से हमेशा उपलब्धता के लिए अंतराल होने वाला है क्योंकि सॉफ़्टवेयर में समय लगता है।

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

बस मेरे विचार जोड़ रहे हैं। मैं समझता हूं कि यह रिलीज कैसे बहुत महत्वपूर्ण है और मुझे यह बताने के लिए मैं आपकी सराहना करता हूं। मैं उस प्रतिक्रिया का उपयोग हमारी ओर से तात्कालिकता को आगे बढ़ाने के लिए करता हूं। जैसा कि @martincostello ने उल्लेख किया है कि जब .NET Core 3.1 बाहर आया था, तो छुट्टियों के कारण बहुत अच्छा नहीं था, बल्कि रीइन्वेंट के दौरान भी।

मैं वह व्यक्ति था जिसने अतीत में 2.1 के लिए उल्लेख किया था कि मुझे आशा है कि हमने जो स्वचालन रखा है वह भविष्य में रिलीज को गति देगा। ऑटोमेशन जो @assyad ने डाला है, उसने वास्तव में हमारी मदद की है लेकिन दुर्भाग्य से जैसे-जैसे सॉफ्टवेयर जाता है चीजें बहुत बदल गई हैं जब से हमने .NET Core 2.1 किया है। इसका एक हिस्सा यह है कि MS कैसे .NET Core बनाता है और दूसरा हिस्सा यह है कि कैसे लैम्ब्डा सेवा Amazon Linux 2 में जाने के साथ काम करती है।

तो कृपया मुझ पर विश्वास करें कि .NET Core 3.1 @assyad है , मैं और कई अन्य लोगों को सर्वोच्च प्राथमिकता देना है।

बस जाँच करने के लिए, क्या Microsoft द्वारा अंतिम रिलीज़ की प्रतीक्षा करने के बजाय पूर्व-रिलीज़ रिलीज़ होने के बाद इसे शामिल करने का कार्य शुरू हो जाता है? यह संभवतः क्रिसमस के प्रभाव को कम करेगा और अंतिम रिलीज के बाद इसे जल्द से जल्द वितरित करने की अनुमति देगा क्योंकि इसे केवल परीक्षण की आवश्यकता होगी।

मैं उस प्रतिक्रिया का उपयोग हमारी ओर से तात्कालिकता को आगे बढ़ाने के लिए करता हूं

इसके लिए धन्यवाद @normj। यहाँ मेरा $0.02 है, उम्मीद है कि यह आपके इंजीलवाद में भी मदद करेगा।

जैसा कि @martincostello ने उल्लेख किया है कि जब .NET Core 3.1 बाहर आया था, तो छुट्टियों के कारण बहुत अच्छा नहीं था, बल्कि रीइन्वेंट के दौरान भी।

जैसा कि @mungojam ने संकेत दिया है, .NET Core 3.1 पूर्वावलोकन के रूप में 15 अक्टूबर से, रिलीज से एक महीने पहले उपलब्ध था। साथ ही, यह मूल रूप से 3.0 की बग फिक्स रिलीज है - मैं आपके टूल्स नहीं जानता लेकिन मुझे लगता है कि खोजपूर्ण कार्य 3.0 का उपयोग करना शुरू कर सकता था, जिसे 23 सितंबर को जारी किया गया था और पूरे वर्ष पूर्वावलोकन में

.NET Core 3.1 Microsoft की Azure ऐप सेवा के रिलीज़ होने के 2-3 सप्ताह बाद तक उपलब्ध नहीं था।

.NET Core 3.1, पूर्वावलोकन 1 जारी होने के दो दिन बाद, 17 अक्टूबर को Azure Functions पर उपलब्ध था।

आप कह सकते हैं कि किसी भी कंपनी के लिए 3.1 की तुरंत आवश्यकता के बारे में आप क्या कहेंगे, चाहे वह "ब्लीडिंग एज", कस्टम रनटाइम विकल्प आदि हो, लेकिन यह वास्तव में एक बड़ी तस्वीर का हिस्सा है कि AWS कितनी गंभीरता से हमारा समर्थन करना चाहता है। NET ग्राहक। अगर एडब्ल्यूएस - नॉर्म की टीम नहीं, लेकिन कुल मिलाकर एडब्ल्यूएस - ने इसे प्राथमिकता दी थी, तो मुझे लगता है कि वे इसके सामने बाहर हो सकते थे, यह सुनिश्चित कर लें कि वे एज़ूर के साथ प्रतिस्पर्धा कर रहे थे।

व्यक्तिगत रूप से, मैं वास्तव में क्लाउड पेशकशों के बीच विकल्पों को महत्व देता हूं जिन्हें मैं कॉर्पोरेट हठधर्मिता के बजाय योग्यता के आधार पर चुन सकता हूं, और मुझे यह देखना अच्छा लगेगा कि AWS .NET समर्थन में सुधार के लिए अगला कदम उठाए।

धन्यवाद @normj , @assyadh , और आपके प्रयासों के लिए इस पर काम करने वाले किसी भी अन्य।

यह संभव है कि AWS की .NET टीम ने 3.0 पूर्वावलोकन जारी होने पर .NET 3.1 LTS के लिए तैयारी की अपनी यात्रा बहुत अच्छी तरह से शुरू कर दी हो। बात यह है कि, एडब्ल्यूएस पर्दे के पीछे वे क्या काम कर रहे हैं, इस बारे में चुस्त-दुरुस्त रहते हैं। पारदर्शिता की यह कमी अनुमानों को जन्म देती है। मुझे लगता है कि किसी प्रकार का रोडमैप होने से कोई दिक्कत नहीं होगी, भले ही यह अस्थायी हो और तिथियां परिवर्तन के अधीन हों, आदि।

मुझे लगता है कि मुद्दा यह है कि AWS टीम किसी भी प्रकार का ETA नहीं करना चाहती है और इसलिए डेवलपर्स को अंधेरे में रखा जाता है। @normj का कहना है कि ऐसा इसलिए है क्योंकि वह नहीं चाहता कि कोई या कोई कंपनी उन ईटीए के आधार पर भविष्य की योजना बनाए। क्या सामान्य समझ नहीं है कि ईटीए सिर्फ एक अनुमान है और किसी भी कंपनी को किसी अन्य कंपनी के अनुमानों के आधार पर गंभीर योजना नहीं बनानी चाहिए और अगर उन्होंने किया भी, तो कंपनी एडब्ल्यूएस को दोष नहीं दे सकती है या ईटीए को खोने के लिए नाराज नहीं हो सकती है?

एक ईटीए भी एक विशिष्ट दिन नहीं है। यह एक महीना हो सकता है। चोथाई। और हमें किसी भी ईटीए के साथ ठीक होना चाहिए और अगर यह छूट गया तो ठीक होना चाहिए।

को देखते हुए
https://docs.aws.amazon.com/lambda/latest/dg/runtime-support-policy.html
ऐसा लगता है कि एडब्ल्यूएस उस रनटाइम संस्करण के जीवन के अंत के तुरंत बाद रनटाइम को हटा देता है।

क्योंकि .NET कोर एलटीएस संस्करण 3 वर्षों के लिए समर्थित हैं, हम पहले से ही हैं
"समय व्यतीत करके हम .NET Core 3.1 लैम्ब्डा का उपयोग कर सकते हैं"।
इसलिए, मैं समझता हूं कि लोग लैम्ब्डा पर .NET कोर 3.1 प्राप्त करने के लिए रोगी हैं।
BTW, मैं रॉक सॉलिड रिलीज़ को भी प्राथमिकता दूंगा, फिर कुछ जल्दी हो गया।

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

एक और बात यह है कि OSS के इस समय में: क्या .NET समुदाय मदद कर सकता है? हम जीथब पर बात कर रहे हैं।
क्या यह "अंतर्निहित" रनटाइम कुछ बंद कोड है?

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

@normj और टीम:
AWS पर .NET कोर को बेहतरीन बनाने के लिए धन्यवाद

बस मेरे विचार जोड़ रहे हैं। मैं समझता हूं कि यह रिलीज कैसे बहुत महत्वपूर्ण है और मुझे यह बताने के लिए मैं आपकी सराहना करता हूं। मैं उस प्रतिक्रिया का उपयोग हमारी ओर से तात्कालिकता को आगे बढ़ाने के लिए करता हूं।

अपने पक्ष में तात्कालिकता को आगे बढ़ाने के लिए कृपया इस पोस्ट का उपयोग करें। इस बात को ध्यान में रखते हुए, यहाँ मेरे दो पैसे हैं।

बस जाँच करने के लिए, क्या Microsoft द्वारा अंतिम रिलीज़ की प्रतीक्षा करने के बजाय पूर्व-रिलीज़ रिलीज़ होने के बाद इसे शामिल करने का कार्य शुरू हो जाता है?

प्रश्‍न : क्‍या हमें इस प्रश्‍न का ईमानदार उत्‍तर मिलेगा?

ऐसा लगता है कि उत्तर स्वतः स्पष्ट है। ऐसा लगता है कि .NET के लिए प्राथमिकता "शौक-स्तर" है न कि "उद्यम-स्तर" जैसा कि होना चाहिए।

मैंने कहीं सुना है कि 1) संपूर्ण नेट कोर सामग्री को ओपन-सोर्स बना दिया गया है, और 2) कुछ शुरुआती अपनाने वाले कार्यक्रम मौजूद हैं जो आपको वास्तविक रिलीज पर "ग्राउंड रनिंग हिट" करने की अनुमति देते हैं। (विवरण के लिए Google देखें।)

मैं यहाँ मज़ाक कर रहा हूँ, लेकिन सच्चाई यह है कि .NET का अनुसरण करने वाला हर कोई यह जानता है, इसलिए यह उस आत्म-साक्ष्य को जोड़ता है जिसमें मैं बोलता हूँ।

ईमानदारी से, रिलीज में 2.1 की देरी के बाद, मुझे उम्मीद थी कि उस समय किए गए परिवर्तनों का मतलब था कि इस बार (3.1) के आसपास हमें वास्तविक रिलीज से दो सप्ताह से अधिक नए ढांचे के लिए समर्थन मिलेगा। मेरा मतलब है कि रिलीज के कुछ घंटों के भीतर आदर्श होगा, लेकिन अंतिम स्पर्श/पॉलिश के लिए कुछ जगह देना, दो सप्ताह के भीतर सही लगता है।

लेकिन यहाँ हम लगभग दो महीने बाहर हैं और यह सिर्फ "शौक-स्तर-ईश" लगता है।

@rati-dzidziguri मैं समझता हूं और आपकी सराहना करता हूं कि आप एक ईटीए चाहते हैं ताकि आप उसके अनुसार योजना बना सकें। वास्तव में यही कारण है कि हम आम तौर पर ईटीए नहीं देते हैं क्योंकि हम वादे नहीं करने के लिए वास्तव में कड़ी मेहनत करते हैं कि हम 100% सुनिश्चित नहीं हैं कि हम रख सकते हैं।

यह "शौक-स्तर" की सोच है, जैसा कि @abukres बहुत सुंदर ढंग से कहता है:

मुझे लगता है कि मुद्दा यह है कि AWS टीम किसी भी प्रकार का ETA नहीं करना चाहती है और इसलिए डेवलपर्स को अंधेरे में रखा जाता है। @normj का कहना है कि ऐसा इसलिए है क्योंकि वह नहीं चाहता कि कोई या कोई कंपनी उन ईटीए के आधार पर भविष्य की योजना बनाए। क्या सामान्य समझ नहीं है कि ईटीए सिर्फ एक अनुमान है और किसी भी कंपनी को किसी अन्य कंपनी के अनुमानों के आधार पर गंभीर योजना नहीं बनानी चाहिए और अगर उन्होंने किया भी, तो कंपनी एडब्ल्यूएस को दोष नहीं दे सकती है या ईटीए को खोने के लिए नाराज नहीं हो सकती है?

एक ईटीए भी एक विशिष्ट दिन नहीं है। यह एक महीना हो सकता है। चोथाई। और हमें किसी भी ईटीए के साथ ठीक होना चाहिए और अगर यह छूट गया तो ठीक होना चाहिए।

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

@normj , @martincostello , और एडब्ल्यूएस में वहां मौजूद बाकी कार्यकर्ता, एक ठोस .NET पेशकश प्रदान करने के लिए वास्तव में कड़ी मेहनत कर रहे हैं, कृपया समझें कि ये (समुदाय) शिकायतें आपके साथ नहीं हैं, बल्कि संस्कृति/राजनीति से अधिक हैं जो .NET के संबंध में आपको दिए गए प्राथमिकता अधिदेश को निर्देशित करता है। कृपया "उद्यम-स्तर" समर्थन प्राप्त करने में सहायता के लिए इस पोस्ट का उपयोग करें।

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

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

फिर से, जैसा कि @ VagyokC4 कहता है, यह वास्तविक काम करने वाले कर्मचारियों के खिलाफ व्यक्तिगत नहीं है, बल्कि ऊपरी AWS प्रबंधन के लिए एक वेक-अप कॉल है।

.NET Core 3.1 लैम्ब्डा करने वाले सभी लोग IL ट्रिमिंग को सक्षम करने पर विचार कर सकते हैं। सबसे अधिक संभावना है कि आप अपनी ज़िप फ़ाइलों का आकार कम करने जा रहे हैं।
https://www.hanselman.com/blog/MakingATinyNETCore30EntirelySelfcontainedSingleExecutable.aspx

.NET कोर लैम्ब्डा 3.1 रनटाइमएपीआई का उपयोग करके बनाया गया है?
खुले में, जीथब पर?
यदि नहीं, तो क्यों नहीं?

ऑल आई वांट फॉर.... वैलेंटाइन्स डे लैम्ब्डा है .net कोर 3.1 सपोर्ट

ऑल आई वांट फॉर.... वैलेंटाइन्स डे लैम्ब्डा है .net कोर 3.1 सपोर्ट

जीभ से बिल्कुल लुढ़कता नहीं है, लेकिन यह विनम्र है:

मुझे क्रिसमस वेलेंटाइन डे के लिए बहुत कुछ नहीं चाहिए
बस एक ही चीज़ है जो मुझे चाहिए
मुझे उपहारों की परवाह नहीं है
एडब्ल्यूएस पेड़ के नीचे
मैं इसे सिर्फ अपने लिए चाहता हूं
जितना आप कभी भी जान सकते हैं उससे अधिक
मेरी इच्छा पूरी करो ओह
वैलेंटाइन्स डे के लिए मुझे केवल .NET Core 3.1 supooooort चाहिए ...

मुस्कराहट:

Microsoft अपने पूर्वावलोकन चक्र के अंत में गो लाइव लाइसेंस शामिल करता है, जब वे कोई ब्रेकिंग परिवर्तन पेश नहीं करेंगे। उस समय तक वे उस आगामी रिलीज के लिए उत्पादन समर्थन प्रदान करते हैं। मेरी सिफारिश तब तक प्रतीक्षा की जाएगी जब तक वे गो लाइव लाइसेंस के साथ रिलीज नहीं करते और फिर टूलिंग पर काम करना शुरू नहीं करते। .NET Core 3.1 के साथ यह प्रीव्यू 3 में आया जो 11/14 को जारी किया गया था। इस मामले में आरटीएम 3 सप्ताह बाद भी 12/3 पर नहीं था, लेकिन फिर भी आप सुविधाओं को रोल आउट करने के करीब होंगे जब आरटीएम हिट होगा और ग्राहक उम्मीदों का निर्माण करना शुरू करेंगे।

बस मेरा $0.02

ऑल आई वांट फॉर.... वैलेंटाइन्स डे लैम्ब्डा है .net कोर 3.1 सपोर्ट

जीभ से बिल्कुल लुढ़कता नहीं है, लेकिन यह विनम्र है:

मुझे ~क्रिसमस ~ वेलेंटाइन डे के लिए बहुत कुछ नहीं चाहिए
बस एक ही चीज़ है जो मुझे चाहिए
मुझे उपहारों की परवाह नहीं है
एडब्ल्यूएस पेड़ के नीचे
मैं इसे सिर्फ अपने लिए चाहता हूं
जितना आप कभी भी जान सकते हैं उससे अधिक
मेरी इच्छा पूरी करो ओह
वैलेंटाइन्स डे के लिए मुझे केवल .NET Core 3.1 supooooort चाहिए ...

मैं

+1 :)

लैम्ब्डा के लिए .NET कोर 3.1 रनटाइम पर कोई अपडेट?

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

<Rant>
यह निराशाजनक है कि एडब्ल्यूएस लैम्ब्डा रनटाइम समर्थन नीति 30 दिन की खिड़की के बारे में बहुत सख्त है, जब इस तरह की सुविधाओं को 30 दिनों से अधिक समय के लिए कहा जाता है। फिर जादुई रूप से एक दिन AWS इस सुविधा को लागू करेगा और बाकी सभी को .NET Core 3.1 पर स्विच करने के लिए हाथापाई करनी होगी। यह अधिकांश संगठनों को खराब स्थिति में डालता है क्योंकि कई बार उत्पादन वातावरण में कुछ ठीक करने, परीक्षण करने और तैनात करने में एक महीने से अधिक समय लगता है। मैं व्यक्तिगत रूप से इस नीति से थोड़ा परेशान रहा हूं। एक बार (क्योंकि संसाधन की कमी और अन्य उच्च प्राथमिकताएं) एक कंपनी जिसे मैं इस समय फिसल गया था। 3 महीने बाद तक हम अपने लैम्बडास को .NET Core 2.1 में अपग्रेड नहीं कर सके। एक बार जब हमने CloudFront के साथ एक विशेष लैम्ब्डा को तैनात करने की कोशिश की, तो कुछ बुरा (क्या? कौन जानता है क्योंकि CF लॉग कचरा है) हुआ और इसे रोलबैक करने की आवश्यकता थी। सिवाय इसके कि रोलबैक करने के लिए कोई रनटाइम नहीं था। इस प्रकार यह LOCKED परिनियोजन। हमने तुरंत एक टिकट खोला। 24 घंटे बाद हमें हमारी पहली प्रतिक्रिया मिली जो "पूरे स्टैक को हटा दें और फिर से शुरू करें"। जो पूरी तरह से अज्ञानी प्रतिक्रिया है, यह देखते हुए कि यह हमारे डायनेमोडीबी टेबल को "डिलीट" ऑपरेशन के साथ ले जाएगा। हम उस रोलबैक में ढाई सप्ताह से अधिक समय तक बंद रहे। आखिरकार हमें एक सपोर्ट इंजीनियर मिला जो कंटेनर तकनीकों को समझता था और रोलबैक में हमारी मदद करता था और तब तक लाइन पर रहता था जब तक कि हमारा CloudFormation सफल नहीं हो जाता। जो इसने ठीक किया, पहले प्रयास में कोई बदलाव नहीं किया। यही कारण है कि अब मैं सीएफ से नफरत करता हूं, क्योंकि यह उपयोग करने के लिए बहुत ही मनमौजी है।
</Rant>

टीएल; डॉ; AWS लैम्ब्डा रनटाइम सपोर्ट पॉलिसी के साथ काम करना अप्रिय है और यह आपको गर्म पानी में डाल सकती है।
https://docs.aws.amazon.com/lambda/latest/dg/runtime-support-policy.html

@CraigHead आपके निराशाजनक अनुभव के लिए खेद है, लेकिन स्पष्ट होने के बावजूद कि लैम्ब्डा पर .NET Core 3.1 कब जारी किया गया है, Microsoft समर्थन चक्र के आधार पर .NET Core 2.1 रनटाइम कम से कम 21 अगस्त, 2021 तक लैम्ब्डा में समर्थित होगा। 2.1 फंक्शंस को 3.1 में बदलने के लिए जल्दबाजी करने की जरूरत नहीं होगी। मुझे लगता है कि आपका पिछला अनुभव .NET Core 2.0 के साथ था जो लैम्ब्डा के लिए एक विसंगति थी क्योंकि यह लैम्ब्डा में जाने वाला एकमात्र गैर एलटीएस संस्करण था। यह केवल .NET Core 1.0 के साथ कुछ प्रमुख मुद्दों के कारण किया गया था।

हाँ, यह .NET Core 2.0 से आगे .NET Core 2.1 में माइग्रेशन था। शेख़ी के लिए खेद है। हम में से कुछ के लिए 30 दिन थोड़े तंग हैं। समग्र लंबाई को देखते हुए एक लैम्ब्डा महत्वपूर्ण रखरखाव और अतिरिक्त क्यूए के बिना संभावित रूप से चल सकता है।

इस बीच, यह सर्वर रहित के Azure पक्ष पर हो रहा है
https://visualstudiomagazine.com/articles/2020/01/30/azure-functions-3-0-runtime.aspx

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

मंगलवार, 11 फरवरी 2020 को 18:22 बजे, रति दिज़िदज़िगुरी नोटिफिकेशन @github.com
लिखा था:

इस बीच, यह सर्वर रहित के Azure पक्ष पर हो रहा है

https://visualstudiomagazine.com/articles/2020/01/30/azure-functions-3-0-runtime.aspx

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/aws/aws/aws-lambda-dotnet/issues/554?email_source=notifications&email_token=AAAZVJXAAYET4F7PFFOTO3LRCLUETA5CNFSM4JU5UTJKYY3PNVW71WK3WTUL52HS4DFVREXG43VMVH84MBHJ#TGODNMV
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AAAZVJQK3NBVXBZALM4V5KLRCLUETANCNFSM4JU5UTJA
.

मेरी बात भद्दी टिप्पणी करने की नहीं थी, बल्कि यह बताने के लिए थी कि MS ने हाल ही में 3.1 के लिए GA उपलब्धता की घोषणा की थी, इसलिए मुझे उम्मीद है कि AWS जल्द ही 3.1 समर्थन पर अपने काम को अंतिम रूप देगी।
.

इस बीच, यह सर्वर रहित के Azure पक्ष पर हो रहा है
https://visualstudiomagazine.com/articles/2020/01/30/azure-functions-3-0-runtime.aspx

इसकी एक एमएस भाषा को ध्यान में रखते हुए यह आश्चर्य की बात नहीं है कि Azure ने इसका समर्थन करने के लिए एडब्ल्यूएस को हराया।

इस धागे को करीब से देख रहा हूं - मेरे सी # लैम्बडास को अपग्रेड करने के लिए उत्सुक हूं।

डॉटनेट कोर 3.1.0 2019-12-03 जारी किया गया था
https://dotnet.microsoft.com/download/dotnet-core/3.1

यह 2020-01-23 . को Azure में उपलब्ध था
https://azure.microsoft.com/en-us/updates/azure-functions-runtime-30-is-now-available/

हम Azure की तुलना में एक अतिरिक्त महीने से थोड़ा कम हैं

BTW, सभी .NET कोर विकास खुले में github पर किया जाता है
तो, "MS language" होने का ज्यादा प्रभाव नहीं होना चाहिए।
या आप सुझाव देते हैं कि डॉटनेट का उपयोग करने वाले एडब्ल्यूएस क्लाइंट एज़ूर: पी पर बेहतर हैं?

वैसे भी, AWS पर सुनने वाले किसी के लिए भी:
हम लैम्ब्डा पर 3.1 की प्रतीक्षा कर रहे हैं, यह हमारे लिए महत्वपूर्ण है।

BTW, सभी .NET कोर विकास खुले में github पर किया जाता है
तो, "MS language" होने का ज्यादा प्रभाव नहीं होना चाहिए।
या आप सुझाव देते हैं कि डॉटनेट का उपयोग करने वाले एडब्ल्यूएस क्लाइंट एज़ूर: पी पर बेहतर हैं?

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

मुझे लगता है कि AWS अपने .Net समर्थन के साथ अच्छा कर रहे हैं, विशेष रूप से विकास पैकेजों के साथ जो उनकी सेवाओं जैसे CloudWatch + ILogging और उनके SSM पैरामीटर कॉन्फ़िगरेशन टाई में हुक करते हैं। इससे हमें बहुत मदद मिली है।

हालांकि जल्द ही 3.1 रिलीज देखने की उम्मीद है :)

मेरी इच्छा है कि ILogger बेहतर क्लाउडवॉच ठोस कार्यान्वयन हो। लैम्ब्डा एसडीके का उपयोग करते समय इसे ServiceCollection / ServiceProvider में बेहतर ढंग से एकीकृत किया जाएगा। वर्तमान संस्करण जो अनुरोध संदर्भ और स्थिर लैम्ब्डालॉगर वर्ग में प्रदान किया गया है, मूल रूप से यूनिट परीक्षण / लॉग आउटपुट को सत्यापित करना और डिफ़ॉल्ट .netcore ConsoleLogProvider परिणामों को गड़बड़ क्लाउडवॉच लॉग में जोड़ना असंभव है।

मेरी इच्छा है कि ILogger बेहतर क्लाउडवॉच ठोस कार्यान्वयन हो।

क्या आपने https://github.com/aws/aws-logging-dotnet#aspnet -core-logging की कोशिश की है?

आप क्या चाहते हैं कि आपके लॉग @CraigHead की तरह दिखें?

हमने अतीत में सेरिलोग और https://github.com/structured-log/structured-log का उपयोग अच्छे कंसोल लॉग और JSON आधारित लॉग को आउटपुट करने के लिए किया है जो Seq में आयात किए गए थे। https://datalust.co/ हमारे लिए केंद्रीय लॉग को वास्तव में अच्छे प्रारूप में प्राप्त करने का सबसे अच्छा तरीका था।

@CraigHead Amazon.Lambda.Logging.AspNetCore लैम्ब्डा के लॉगिंग को IServiceCollection में एकीकृत करने के लिए हमारा कार्यान्वयन है। क्या वह पुस्तकालय आपके काम नहीं आता।

मैं लैम्ब्डा के लिए ttps: //github.com/aws/aws-logging-dotnet#aspnet -core-logging से AWS.Logger.AspNetCore पैकेज की अनुशंसा नहीं करूंगा। क्लाउडवॉच लॉग में लॉग को पुश करने के लिए वह लाइब्रेरी बैकग्राउंड थ्रेड का उपयोग करती है। उस तरह के बैकग्राउंड थ्रेड का उपयोग करना लैम्ब्डा के साथ अच्छा नहीं खेलता है जो लैम्ब्डा कंप्यूट वातावरण को फ्रीज कर देता है जैसे ही फंक्शन हैंडलर रिटर्न करता है, जिसका अर्थ है कि बैकग्राउंड थ्रेड को कतारबद्ध संदेशों को फ्लश करने का मौका नहीं मिल सकता है।

मुझे इस बारे में पता नहीं था। टिप के लिए धन्यवाद!
मैं एसडीके में Amazon.Lambda.Core.LambdaLogger बात कर रहा था।
मैं निश्चित रूप से उस पैकेज ( Amazon.Lambda.Logging.AspNetCore ) की जांच करूंगा।

https://docs.aws.amazon.com/lambda/latest/dg/csharp-logging.html

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

कृपया इस धागे को अन्य जरूरतों के लिए हाईजैक न करें।
यह थ्रेड कुछ जानकारी देने के लिए बनाया गया था जब AWS लैम्ब्डा पर .NET Core 3.1 उपलब्ध होगा।
और एडब्ल्यूएस को यह बताने के लिए कि हम वहां हैं और प्रतीक्षा कर रहे हैं।

क्या लैम्ब्डा टेस्ट टूल को 3.1 रिलीज में शामिल किया जाएगा? https://github.com/aws/aws-lambda-dotnet/tree/master/Tools/LambdaTestTool

यही मेरा इरादा है। मॉक-टेस्टटूल-31 में काम चल रहा है। 3.1 शाखा में बड़ा सुधार यह है कि उपयोगकर्ता लैम्ब्डा कोड अब एक अलग असेंबलीलोडकॉन्टेक्स्ट में चल रहा है, जो कि वर्तमान संस्करण के साथ उपयोगकर्ताओं के बहुत सारे संस्करण संघर्षों को ठीक करना चाहिए। मैं असेंबली लोड कॉन्टेक्स्ट सुविधा को 2.1 संस्करण में वापस पोर्ट कर रहा हूं।

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

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

इस बिंदु पर कुछ भी ब्लेज़र एक अच्छा विचार है, विशेष रूप से हममें से उन लोगों के लिए जो डॉटनेट को रॉक कर रहे हैं!

"नंगे हड्डी UI" - यह कोई अन्य ऐप है, जो .NET Core 3.1 लैम्ब्डा से जुड़ा नहीं है?
BTW, मुझे ब्लेज़र की बिल्कुल भी परवाह नहीं है

@petarrepac यह AWS .NET मॉक लैम्ब्डा टेस्ट टूल के संदर्भ में था जिसे हमने डिबग .NET Core 2.1 लैम्ब्डा फ़ंक्शंस में मदद करने के लिए भेजा था। यहाँ संदर्भ के लिए पोस्ट है https://aws.amazon.com/blogs/developer/debugging-net-core-aws-lambda-functions-using-the-aws-net-mock-lambda-test-tool/

मैं .NET Core 3.1 के लिए टूल को अपडेट करने की प्रक्रिया में हूं।

@normj
आह, वह नहीं मिला, धन्यवाद
यह दिलचस्प विचार है, कि हमें ऐसे टूल की कभी आवश्यकता नहीं थी

हमारे दृष्टिकोण से लैम्ब्डा एक नंगे हड्डी AspNetCore HttpApi है जिसे आप स्थानीय रूप से कॉल कर सकते हैं और स्थानीय रूप से परीक्षण कर सकते हैं
केवल अंतर प्रवेश बिंदु फ़ाइल/वर्ग है जो कोड की 50 पंक्तियों के अंतर्गत है
साथ ही, एडब्ल्यूएस में तैनात होने पर बहुत सी चीजों का ठीक से परीक्षण किया जा सकता है:

• अनुमतियां
• प्राप्त JSON ईवेंट और संदर्भ का आकार
• ...
  तो, का एक संयोजन:
• अच्छी इकाई/एकीकरण परीक्षण स्थानीय रूप से चल रहे हैं
• स्थानीय http परीक्षण
• एडब्ल्यूएस पर्यावरण का परीक्षण करने के लिए तैनात करना आसान है
  बहुत दूर जा सकते हैं

या मुझे कुछ स्पष्ट परिदृश्य याद आ रहा है?

@petarrepac ASP.NET कोर ब्रिज का उपयोग करने के बड़े लाभों में से एक यह है कि स्थानीय रूप से चलाना वास्तव में आसान है। मैं मानता हूं कि यूनिट/एकीकरण परीक्षण का उपयोग करना सबसे अच्छा अभ्यास है, लेकिन अक्सर एप्लिकेशन लॉजिक के त्वरित तदर्थ परीक्षण की आवश्यकता होती है और यही वह उपकरण है जिसके लिए यह अच्छा है।

धन्यवाद @normj। ब्लेज़र के संबंध में, यह एक अच्छा स्पर्श हो सकता है। हमारी टीम के उपयोग के मामले में कम से कम शायद इसका उपयोग कम हो जाएगा।

हम केवल यूआई में एक पेलोड भेजने के लिए पर्याप्त हैं, फिर वीएस में कोड के माध्यम से कदम उठा रहे हैं।

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

मेरे पास 16 लैम्ब्डा का एक सूट है जो एक "मोनोलिथ" के बजाय एक एप्लिकेशन से तैनात किया गया है।

यह ब्लॉग पोस्ट के नमूना कोड में दिखाए गए हार्ड-कोडेड वन-टू-वन मैपिंग के बजाय रनटाइम पर उपयोग करने के लिए विधि चुनने के लिए _handler पर्यावरण चर का उपयोग करके प्राप्त किया जाता है।

मैं इसे एक कंसोल ऐप के रूप में सोचता हूं जो एक स्विच प्राप्त करता है जो यह बताता है कि शुरू होने पर "बनने" के लिए क्या क्रिया है।

@मार्टिनकोस्टेलो

मुझे आपके स्पष्टीकरण के आधार पर इसे दूर करने में कुछ परेशानी हो रही है। मेरे Functions.cs में लगभग 20 लैम्ब्डा फ़ंक्शन हैं जो मेरे serverless.template में संबंधित परिभाषाओं से बंधे हैं। मैं समझता हूं कि आप प्रत्येक परिभाषा के साथ एक पर्यावरण चर पारित कर रहे होंगे ताकि यह इंगित किया जा सके कि किस फ़ंक्शन को कॉल करना है। इनमें से अधिकांश कार्य हस्ताक्षर के हैं:

सार्वजनिक APIGatewayProxyResponse ThisLambdaFunction(APIGatewayProxyRequest अनुरोध, ILambdaContext प्रसंग)
{

विभिन्न लैम्ब्डा फ़ंक्शन हस्ताक्षरों के लिए समर्थन कैसे जोड़ें, यदि मेरे पास अन्य फ़ंक्शन हैं जो अलग-अलग तर्क लेते हैं (APIGatewayProxyRequest के अलावा) और विभिन्न रिटर्न प्रकार?

कृपया धागे को पटरी से न उतारें।

@twopointzero मैंने .NET Core 3.1 कस्टम रनटाइम प्रोजेक्ट का उपयोग करके कई लैम्ब्डा फ़ंक्शंस चलाने के समाधान के लिए Google खोज में दिन बिताए हैं। इंटरनेट पर कोई और प्रासंगिक सूत्र नहीं है और मैं एक मौजूदा पोस्ट का जवाब दे रहा हूं जिसने आशा की एक किरण प्रदान की है कि मेरी समस्या का समाधान है।

AWS में नेटिव .NET Core 3.1 सपोर्ट न होना जीवन को कठिन बना रहा है। नवीनतम EntityFramewore Core 3.1.2 में अपग्रेड करने के लिए हमें 3.1 में अपग्रेड करने की आवश्यकता है, जो ऑरोरा (PostgresSQL) में कनेक्शन पूलिंग के साथ हमारे द्वारा देखी जा रही समस्याओं को ठीक करता है।

@normj मैं पूरी तरह से नो ईटीए रुख को समझता हूं, लेकिन क्या आप मुझे बता सकते हैं कि क्या हम करीब हैं? <30 दिन?

@antsaia सम्मान के साथ, आपकी टिप्पणी कस्टम रनटाइम समर्थन का उपयोग करते हुए एक वितरित मोनोलिथ की तैनाती के संबंध में थी, न कि .NET कोर 3.1 के लिए AWS लैम्ब्डा समर्थन के संबंध में। यदि आपको इंटरनेट पर अधिक प्रासंगिक सूत्र नहीं मिल रहा है, तो मैं आपसे अनुरोध करूंगा कि आप इसे पटरी से उतारने के बजाय एक बनाएं।

ताकि मैं स्वयं इस सूत्र को पटरी से न उतार दूं, इस मामले पर यह मेरी अंतिम टिप्पणी है।

@normj क्या कोई संसाधन उपलब्ध है (ब्लॉग, फोरम, आदि) जहां हम .net कोर 3.1 समर्थन कार्यान्वयन की स्थिति के बारे में जानकारी प्राप्त कर सकते हैं?

मैं कोई भी नई जानकारी प्राप्त करने की आशा के साथ प्रतिदिन इस पृष्ठ पर जाता हूं लेकिन स्पष्ट रूप से पर्याप्त जानकारी नहीं है (क्योंकि यह उस उपयोग के लिए अभिप्रेत नहीं है)। यदि हमारे पास किसी प्रकार का बुनियादी अपडेट होता तो यह बहुत आसान हो जाता ताकि हम आगे की योजना बना सकें।

यहां कई लोगों की तरह सुविधाओं को वितरित करने की हमारी योजनाएं बहुत हद तक इस बात पर निर्भर करती हैं कि हम 3.1 का उपयोग कर सकते हैं या यदि हमें 2.1 का उपयोग करके इसे विकसित करना है। मेरे मामले में 3.1 सिस्टम के लिए समर्थन प्रदान करेगा। ड्रा और इसका उस सुविधा पर एक बड़ा प्रभाव पड़ता है जिस पर मुझे काम करना है।

ऑल आई वांट फॉर .... सेंट पैट्रिक डे लैम्ब्डा है .net कोर 3.1 सपोर्ट

@ liam-sage सभी मुझे अमेज़ॅन फोरम पर कुछ पोस्ट मिल सकते हैं जो यह संकेत देते हैं कि यह Q1 2020 में तैयार होगा। https://forums.aws.amazon.com/thread.jspa?threadID=313806

@ liam-sage सभी मुझे अमेज़ॅन फोरम पर कुछ पोस्ट मिल सकते हैं जो यह संकेत देते हैं कि यह Q1 2020 में तैयार होगा। https://forums.aws.amazon.com/thread.jspa?threadID=313806

इसका मतलब है कि इसे मार्च में लाइव होना चाहिए। मैं इंतज़ार कर रहा हूँ।

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

और विंसेंट, हम इसे वहां कैसे होस्ट करते हैं? कस्टम रनटाइम का उपयोग करना?
गुरु, 5 मार्च, 2020 को शाम 7:40 बजे विन्सेंट वैन डेर वॉल्ट <
सूचनाएं@github.com> ने लिखा:

नमस्ते, मुझे पता है कि यह पूरी तरह से उपयुक्त नहीं है, लेकिन आप अपना स्वयं का लैम्ब्डा प्राप्त कर सकते हैं
डॉटनेटकोर 3.1 में अपडेट किया गया। इस बीच जब आप प्रतीक्षा करेंगे तो मैं सुझाव दूंगा
यदि आप अपना खुद का डॉटनेटकोर टेम्पलेट लिखने के लिए बहुत सारे लैम्ब्डा बनाते हैं। मैंने किया
कि मेरे लिए। मैं यह सुनिश्चित करना चाहता था कि मुझे घंटों बर्बाद न करना पड़े
बॉयलरप्लेट कोड। टेम्पलेट का एक उदाहरण यहां पाया जा सकता है
https://github.com/vincentvanderwalt/aws-lambda-dotnetcore-3-template ।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
कॉम
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AGIDH4PLKFSDLNBX2QVMG63RF62V3ANCNFSM4JU5UTJA
.

हाँ यह कस्टम रनटाइम का उपयोग करता है।

आप इसे स्थानीय रूप से अपनी मशीन पर चला सकते हैं या एडब्ल्यूएस पर तैनात कर सकते हैं।

स्थानीय के लिए F5 और aws . पर परिनियोजन के लिए dotnet lambda deploy-serverless

रीडमी बताता है कि टेम्पलेट को अपनी स्थानीय मशीन पर कैसे स्थापित करें (यह एक डॉटनेटकोर टेम्पलेट है)

कस्टम रनटाइम अच्छे हैं, लेकिन मैं अभी भी .Net Core 3.1 के लिए पूर्ण AWS समर्थन की प्रतीक्षा कर रहा हूं ताकि लैम्ब्डा उत्पादन वातावरण में उनका उपयोग कर सकें

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

शुक्र है, कम से 07:13 मार्च 6, 2020 पर bartoszsiekanski [email protected]
लिखा था:

कस्टम रनटाइम अच्छे हैं, लेकिन मैं अभी भी पूर्ण AWS समर्थन की प्रतीक्षा कर रहा हूं
लैम्ब्डा के लिए .नेट कोर 3.1 के लिए उन्हें उत्पादन वातावरण में उपयोग करने के लिए

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/aws/aws/aws-lambda-dotnet/issues/554?email_source=notifications&email_token=AAVUT3SNDR4L2ZL5J4KQYDDRGDSHBA5CNFSM4JU5UTJKYY3PNVWWK3TUL52HS4DFVREXG43VMVJ95W
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AAVUT3TBH3NIBMGB54EFCR3RGDSHBANCNFSM4JU5UTJA
.

कृपया .NET Core 3.1 समर्थन पर चर्चा करने के अलावा किसी और चीज के लिए अलग मुद्दे बनाएं। क्या हम इस मुद्दे को तब तक बंद कर सकते हैं जब तक हमारे पास @normj की और खबरें न आ

@ hounddog22030 मुझे नहीं पता था कि मैं धागे को 'अपहरण' कर रहा था। मैं सुझाव दे रहा था कि लगातार यह पूछने के बजाय कि क्या यह तैयार है, वैकल्पिक दृष्टिकोण हैं यदि लोग डॉटनेटकोर 3.1 में जाने के लिए बेताब हैं। आधिकारिक गैर-कस्टम-रनटाइम समर्थन तैयार होने पर तैयार हो जाएगा। लोगों को बस थोड़ा और धैर्य रखना होगा या वैकल्पिक दृष्टिकोण की तलाश करनी होगी।

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

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

आपने अभी लैम्ब्डा कस्टम रनटाइम फीचर का वर्णन किया है

@aussiearf यह वास्तव में अच्छी तरह से काम करता है, लेकिन स्वयं निहित पैकेज में .Net Core ही शामिल है, जो आम तौर पर वेबसाइट के लिए कम से कम 40 एमबी (ज़िप्ड) जोड़ता है - आवेदन और निर्भरताओं के लिए ज्यादा जगह नहीं छोड़ता है।

.NET कोर के समान संस्करण का उपयोग करते समय, कस्टम रनटाइम भी देशी रनटाइम की तुलना में धीमा (ठंडा प्रारंभ) होता है। 3.1 बहुत सारे प्रदर्शन सुधार जोड़ता है, इसलिए आप 3.1 कस्टम पूरी तरह से अनुकूलित और 2.1 मूल के बीच समान स्तर के प्रदर्शन की उम्मीद कर सकते हैं। मुझे आशा है कि 3.1 मूल निवासी महत्वपूर्ण सुधार लाएंगे।

Q1 4 दिनों में समाप्त हो जाएगा, लेकिन ऐसा लगता है कि हम लैम्ब्डा में 3.1 नहीं देखेंगे।
मुझे उम्मीद है कि टीम के सभी सदस्य इस महामारी के समय में सुरक्षित हैं और इस रिलीज को दूसरी तिमाही में देखने की उम्मीद करते हैं।

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

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

यह शानदार खबर है। धन्यवाद @normj

ब्लॉग पोस्ट और रिलीज की प्रतीक्षा कर रहे हैं।

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

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

इस सूत्र में रवैए के सामने आपका धैर्य प्रभावशाली से परे है। इस पर काम करने के लिए धन्यवाद!

@normj किसी भी परीक्षण के साथ सहायता करने के लिए खुश है

जाने के लिए 2 और दिन और उंगलियां पार हो गईं।

और क्वार्टर में 13 घंटे बचे हैं

https://aws.amazon.com/blogs/compute/announcing-aws-lambda-supports-for-net-core-3-1/

आपके धैर्य के लिए सभी को धन्यवाद। @raRaRa मैं आपको इस मुद्दे को बंद करने का सम्मान छोड़ दूंगा।

महान

मंगलवार, 31 मार्च 2020, 20:06 नॉर्म जोहानसन, नोटिफिकेशन @github.com ने लिखा:

और क्वार्टर में 13 घंटे बचे हैं

https://aws.amazon.com/blogs/compute/announcing-aws-lambda-supports-for-net-core-3-1/

आपके धैर्य के लिए सभी को धन्यवाद। @raRaRa https://github.com/raRaRa
मैं आपको इस मुद्दे को बंद करने का सम्मान छोड़ दूंगा।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/aws/aws-lambda-dotnet/issues/554#issuecomment-606785798 ,
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AGUX3OUR6LN5CERIBTDHXP3RKIWLVANCNFSM4JU5UTJA
.

धन्यवाद!!!!

और.... अनसब्सक्राइब :-)

शामिल सभी को धन्यवाद!!!

धन्यवाद!

और क्वार्टर में 13 घंटे बचे हैं

https://aws.amazon.com/blogs/compute/announcing-aws-lambda-supports-for-net-core-3-1/

आपके धैर्य के लिए सभी को धन्यवाद। @raRaRa मैं आपको इस मुद्दे को बंद करने का सम्मान छोड़ दूंगा।

अच्छा काम!

वह एडब्ल्यूएस बेबी है। वह एडब्ल्यूएस है !!!
चाहे कुछ भी हो जाए, अंत में वे इसे पूरा करते हैं।

बहुत बहुत धन्यवाद, टीम !!!

अच्छी खबर और बहुत बहुत धन्यवाद @raRaRa @normj !!! मूर्ख और/या लालची लगने के जोखिम पर क्या इसका आंतरिक रूप से पॉवरशेल 7 भी मतलब है? बस डबल चेकिंग ......

बढ़िया काम @normj और AWS में हर कोई! मैं

नीचे स्क्रॉल करने वालों के लिए ब्लॉग का लिंक यहां दिया गया है
https://aws.amazon.com/blogs/compute/announcing-aws-lambda-supports-for-net-core-3-1/

बहुत बढ़िया, डॉटनेट कोर 3.1 में समर्थन जोड़ने के लिए एक लाख धन्यवाद!!!

@andyKalman अभी तक PowerShell 7 पर नहीं है। मैं AWSLambdaPSCore मॉड्यूल पर कुछ अंतिम टच अप कर रहा हूं और फिर गैलरी में AWSLambdaPSCore के 2.0.0 संस्करण को जारी कर दूंगा।

मैं त्वरित उत्तर @normj की सराहना करता

बधाई!
और धन्यवाद एडब्ल्यूएस और .NET टीम!
बहुत सराहना की।

ऐसा करने में मदद करने वाले सभी लोगों को धन्यवाद! यह एक बहुत बड़ी रिलीज़ है और यह दिखाती है कि इसमें बहुत मेहनत की गई है! अच्छा! मैं

धन्यवाद !! : ताली :: ताली :: टाडा :: टाडा:

बधाई हो दोस्तों, उन्नयन के लिए तत्पर हैं।

धन्यवाद!

बहुत बढ़िया काम, इन लैम्ब्डा को अपग्रेड करने के लिए उत्सुक।

महान काम! धन्यवाद @normj

महान कार्य दल!

dotnet 3.1 Async Streams +AWS AppSync/GraphQL सब्सक्रिप्शन के साथ लैम्ब्डा वर्कर्स पर कूदने के लिए उत्सुक।
एडब्ल्यूएस टीम, बहुत बहुत धन्यवाद!

ओएमजी, दोस्तों आप नियम! अद्भुत! वू हू! मैं

धन्यवाद!

@andyKalman मैंने AWSLambdaPSCore मॉड्यूल के संस्करण 2.0.0 को धक्का दिया जो अब पावरशेल 7 का उपयोग करता है। मैं PS7 समर्थन पर एक ब्लॉग पोस्ट डालने की योजना बना रहा हूं लेकिन यह मौजूदा पावरशेल 6 समर्थन के समान ही कार्य करता है 7 का उपयोग करता है।

@andyKalman मैंने AWSLambdaPSCore मॉड्यूल के संस्करण 2.0.0 को धक्का दिया जो अब पावरशेल 7 का उपयोग करता है। मैं PS7 समर्थन पर एक ब्लॉग पोस्ट डालने की योजना बना रहा हूं लेकिन यह मौजूदा पावरशेल 6 समर्थन के समान ही कार्य करता है 7 का उपयोग करता है।

यदि मैं उन्हें नए संस्करण के साथ प्रकाशित करता हूं तो क्या AWSLambdaPSCore का नया संस्करण मेरे मौजूदा लैम्ब्डा फ़ंक्शन के भीतर किसी भी कॉन्फ़िगरेशन को अपडेट करता है? क्या यह इसे dotnet3.1 और ps7 की ओर इंगित करेगा?

@ tr33squid हाँ यदि आप 2.0.0 के साथ परिनियोजित करते हैं तो यह .NET Core 3.1 और PS7 का उपयोग करेगा

बहुत बहुत धन्यवाद और बढ़िया काम AWS टीम !!

हेलो सब लोग,

मैं लैम्ब्डा में .NET कोर 3.1 के लिए समर्थन लाने पर सक्रिय रूप से काम कर रहा हूं। इसमें कुछ समय लगता है क्योंकि Microsoft द्वारा रनटाइम बनाने के तरीके में बहुत काम किया गया था। मैं आपको एक मूल रनटाइम लाने के लिए इन परिवर्तनों को शामिल करने पर काम कर रहा हूं।

AWS-Lambda .NET कोर टीम को धन्यवाद

नमस्ते,
एडब्ल्यूएस-लैम्ब्डा निष्पादित करने का प्रयास करते समय मुझे यह त्रुटि मिल रही है
किसी भी संगत फ्रेमवर्क संस्करण को खोजना संभव नहीं था।
निर्दिष्ट फ्रेमवर्क 'Microsoft.AspNetCore.App', संस्करण '3.1.0' नहीं मिला।
कोई सुझाव ??

नमस्ते,
एडब्ल्यूएस-लैम्ब्डा निष्पादित करने का प्रयास करते समय मुझे यह त्रुटि मिल रही है
किसी भी संगत फ्रेमवर्क संस्करण को खोजना संभव नहीं था।
निर्दिष्ट फ्रेमवर्क 'Microsoft.AspNetCore.App', संस्करण '3.1.0' नहीं मिला।
कोई सुझाव ??

आपको 3.1.0 एसडीके स्थापित करने की आवश्यकता है।

मेरा मानना ​​है कि Microsoft.AspNetCore.App को आपके प्रोजेक्ट से हटा दिया जाना चाहिए
निर्भरता, अब कोर 3.1.0 के लिए आवश्यक नहीं है, मुझे इसे हटाना पड़ा
मैंने 2.1 से अपग्रेड की गई सेवा का निर्माण और तैनाती की।

शुक्र, 24 अप्रैल, 2020 को सुबह 3:24 बजे ग्रेगरी लियोन नोटिफिकेशन @github.com
लिखा था:

नमस्ते,
एडब्ल्यूएस-लैम्ब्डा निष्पादित करने का प्रयास करते समय मुझे यह त्रुटि मिल रही है
किसी भी संगत फ्रेमवर्क संस्करण को खोजना संभव नहीं था।
निर्दिष्ट ढांचा 'Microsoft.AspNetCore.App', संस्करण '3.1.0' था
पता नहीं चला।
कोई सुझाव ??

आपको 3.1.0 एसडीके स्थापित करने की आवश्यकता है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/aws/aws-lambda-dotnet/issues/554#issuecomment-618850277 ,
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AMSHCOLW5WJDS7CCAFDMP4TROE5ENANCNFSM4JU5UTJA
.

--
श्रेष्ठ,
जॉर्ज

जॉर्ज टास्कोस
वरिष्ठ समाधान वास्तुकार

हम 8
230 पार्क एवेन्यू, तीसरा फ्लो। पश्चिम
न्यूयॉर्क, एनवाई 10169
(917) 717-9067
Weare8.com

निजी प्रवेश,
71 वेंडरबिल्ट एवेन्यू
तीसरी मंजिल

मेरा मानना ​​है कि Microsoft.AspNetCore.App को आपकी परियोजना निर्भरता से हटा दिया जाना चाहिए, कोर 3.1.0 के लिए अब इसकी आवश्यकता नहीं है, मुझे 2.1 से अपग्रेड की गई सेवा को बनाने और तैनात करने के लिए इसे हटाना पड़ा।
…
शुक्र, 24 अप्रैल, 2020 को सुबह 3:24 बजे ग्रेगरी लियोन्स @ । * > लिखा: नमस्ते, मुझे यह त्रुटि तब हो रही है जब एडब्ल्यूएस-लैम्ब्डा को निष्पादित करने का प्रयास करते समय किसी भी संगत फ्रेमवर्क संस्करण को खोजना संभव नहीं था। निर्दिष्ट फ्रेमवर्क 'Microsoft.AspNetCore.App', संस्करण '3.1.0' नहीं मिला। कोई सुझाव ?? आपको 3.1.0 एसडीके स्थापित करने की आवश्यकता है। — आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस धागे की सदस्यता ली है। इस ईमेल का सीधे उत्तर दें, इसे GitHub < #554 (टिप्पणी) > पर देखें, या https://github.com/notifications/unsubscribe-auth/AMSHCOLW5WJDS7CCAFDMP4TROE5ENANCNFSM4JU5UTJA को अनसब्सक्राइब
- बेस्ट, जॉर्ज जॉर्ज टास्कोस सीनियर सॉल्यूशंस आर्किटेक्ट WeAre8 230 पार्क एवेन्यू, तीसरा फ्लो। वेस्ट न्यू यॉर्क, एनवाई 10169 (917) 717-9067 Weare8.com निजी प्रवेश, 71 वेंडरबिल्ट एवेन्यू तीसरी मंजिल

आपके जवाब के लिए धन्यवाद,
दरअसल यह त्रुटि मेरी मूर्खतापूर्ण गलती के कारण हुई थी। मैं अपने serverless.yml में रनटाइम: dotnetcore2.1 को हटाना भूल गया। अब मसला हल।

कोई भी इस पर कोई अद्यतन बेंचमार्क/तुलना करता है? मैं केवल एक कस्टम रनटाइम के साथ पुराने पा सकता हूं ..

कोई भी इस पर कोई अद्यतन बेंचमार्क/तुलना करता है? मैं केवल एक कस्टम रनटाइम के साथ पुराने पा सकता हूं ..

यहाँ एक अच्छा है।
https://medium.com/@zaccharles/a -close-look-at-net-core-3-1-on-aws-lambda-9ccec4dd96be

इसके अलावा 512 एमबी लैम्ब्डा आकार पर 2.1 जटिल लैम्ब्डा को 3.1 में अपडेट करने के मेरे व्यक्तिगत अनुभव में लगभग समान प्रदर्शन (ठंडा और गर्म शुरुआत) देखा गया। 2.1 और 3.1 लैम्ब्डा दोनों लैम्ब्डा परत, अनुकूलित प्रकाशन, न्यूटनसॉफ्ट (3.1 में माइक्रोसॉफ्ट जेसन के साथ पूर्ण सुधार देख सकते हैं), स्तरीय संकलन बंद, और 3.1 के लिए आरटीआर का उपयोग करते हैं।

मेरे मेट्रिक्स से, ऐसा लगता है कि डॉटनेट 3.1 रनटाइम के साथ मामूली प्रदर्शन प्राप्त होता है, लेकिन अमेज़ॅन लिनक्स 2 और डॉटनेट 3.1 प्रारंभ पर प्रदर्शन खो देता है। (2.1 Amazon Linux 1 का उपयोग करता है।) लाभ कमाना।