Aws-lambda-dotnet: تم إصدار .NET Core 3.1 (LTS)

انها LTS وسيتم دعمها. سيستغرق الأمر بعض الوقت فقط لتجهيز NET Core 3.1 لـ Lambda ونشرها.

انها LTS وسيتم دعمها. سيستغرق الأمر بعض الوقت فقط لتجهيز NET Core 3.1 لـ Lambda ونشرها.

إذا كان هناك أي شيء يمكنني القيام به للمساعدة ، فيرجى إبلاغي بذلك.

هل سيكون هناك تسريع لوقت البدء البارد؟

NET Core 3.1 لديه بعض الميزات مثل ترجمة AOT

• انشر ريديتورون
• انشرتريميد

normj هل يجب على الأشخاص الاشتراك في هذه المشكلة للحصول على التحديثات أم أن هناك مشكلة أخرى من .NET Core 3.1 يجب أن

يمكننا استخدام هذه المشكلة لتتبع التحديثات. لسوء الحظ ، ربما لن أتمكن من تقديم الكثير من تحديثات الحالة حتى يتم إصدارها.

هل سيكون هناك تسريع لوقت البدء البارد؟

NET Core 3.1 لديه بعض الميزات مثل ترجمة AOT

• انشر ريديتورون
• انشرتريميد

في حال كانت الإجابة بنعم على التعليق ، فهل سيكون من الممكن تشغيل واختبار "لامدا المترجمة" من بيئة محلية؟ أود أن أضع بيئة لينكس لها بفارغ الصبر :)

أي تحديث هنا؟

تضمين التغريدة

على النحو الوارد أعلاه من normj

يمكننا استخدام هذه المشكلة لتتبع التحديثات. لسوء الحظ ، ربما لن أتمكن من تقديم الكثير من تحديثات الحالة حتى يتم إصدارها.

تضمين التغريدة
كان سؤالي حول ETA. سيكون من المفيد معرفة ETA لهذا الأمر حيث يمكننا الاستعداد وفقًا لذلك.

@ rati-dzidziguri نادرًا ما تكشف أمازون عن الوقت المتوقع لوسائل النقل عندما يتعلق الأمر بالإصدارات.

@ rati-dzidziguri أتفهم وأقدر أنك تريد ETA حتى تتمكن من التخطيط وفقًا لذلك. في الواقع ، هذا هو السبب في أننا عمومًا لا نعطي ETA لأننا نحاول جاهدًا عدم تقديم وعود لسنا متأكدين بنسبة 100٪ من قدرتنا على الوفاء بها. أنا أكره أن أعطيك إيتا وأنك تصنع خارطة الطريق الخاصة بك بناءً على ذلك ، ثم نفتقد أن إيتا التي توقعتها تلقي بكل خططك في حالة من الفوضى.

في الوقت الحالي ، إذا كنت تحتاج حقًا إلى ميزات .NET Core 3.1 ، فأقترح استخدام .NET Core 3.1 باعتباره وقت تشغيل مخصص لـ Lambda والذي تم شرحه هنا (باستثناء تغيير المراجع من .NET Core 3.0 إلى .NET Core 3.1). ثم عندما يأتي دعم .NET Core 3.1 الأصلي ، سيكون لديك ترحيل بسيط للغاية لتغيير بعض الإعدادات على وظيفة Lambda الخاصة بك.

normj أحد الأسباب التي جعلتني أقرر أنه لا يمكنني استخدام ميزة وقت التشغيل المخصص مع فئة "LambdaEntry" وهو الجانب "المعماري المتآلف" لنهج التنفيذ. يأتي كل طلب لواجهة برمجة التطبيقات من خلال الإدخال الوحيد lambda و "الموزع" على وحدات التحكم في مشروع ASP. net هو ما يقصد به هيكل وقت التشغيل المخصص ، وهو أمر مناسب بالتأكيد ولكنه يتضمن جانبًا سلبيًا هيكليًا لحالات مثل التي أريدها. أريد أن يصبح كل طلب أمر / استعلام لامدا لكل منهما. منذ ذلك الحين يمكنني الحصول على قابلية للتوسع في إدارة حزم النشر بحيث يمكنني تقسيم بعض الوظائف وإدارة الرموز في أي وقت أريده.
هذا هو السبب في أنني أنتظر وقت التشغيل الرسمي ليتم دعمه بحيث يمكنني إنشاء حزمة من "لامبدا فردية الغرض" باستخدام SAM مكتوب في قالب مع "وقت التشغيل: .netcore 3.1" config.

من فضلك أعطني نصيحة إذا كنت أخطأت :)

يمكنك بالتأكيد تحقيق العديد من وظائف lambda من قاعدة رمز واحدة باستخدام Lambda Bootstrapper وميزة وقت التشغيل المخصصة.

لدي مجموعة من 16 لامدا يتم نشرها من تطبيق واحد ، بدلاً من "متراصة".

يتم تحقيق ذلك باستخدام متغير البيئة _handler لاختيار الطريقة المراد استخدامها في وقت التشغيل ، بدلاً من التعيين الثابت الترميز واحد لواحد الموضح في نموذج التعليمات البرمجية لمشاركة المدونة.

أعتقد أنه تطبيق وحدة تحكم يتلقى مفتاحًا يخبره بالإجراء الذي يجب أن "يصبح" عند بدء التشغيل.

تضمين التغريدة
شكرا لك على الاقتراح اللطيف! يمكنني معرفة الشكل الذي قد تبدو عليه حالتك. ربما تكون قد وضعت منطق التبديل في فئة رئيسية أو فئة بدء التشغيل بحيث يمكن تحديد وظيفتها في المرحلة الأولى من وقت التشغيل. ويمكنها حل مشكلة "الأحادية فقط" بالطبع. نهج ذكي جدا :)

لكن لا يزال هناك اعتبار واحد (إن لم يكن كثير) يجب أن أفكر فيه ، خاصة عندما أتخيل العمل كفريق. سيؤدي استخدام وقت التشغيل المخصص وتحديد "الهوية الوظيفية" عند بدء التشغيل إلى التخلص من إمكانية SAM. على سبيل المثال السهل بالنسبة لنا ، لا يمكن تعريف بوابة واجهة برمجة التطبيقات أثناء نشر لامدا ، مما يعني أنه يتعين علينا إنشاء واحدة لها يدويًا.
أعلم أنني أبالغ هنا لأننا نستطيع عمل تكوين يشبه SAM باستخدام البرنامج النصي bootstrap كما أوضح البرنامج التعليمي aws . لكنها لن ترضينا تمامًا لأنها تستخدم برنامجًا نصيًا لينكس مما يعني
(1) قد يكون الأمر محرجًا للقادمين الجدد ، وأحيانًا يصبح منحنى تعليمي.
(2) ستتجاهل ميزة تعبير القالب غير المزود بخادم لأنه حرفياً نص برمجي وليس مستندًا.

أعتقد أن القالب بدون خادم يعمل كمستند شبه مستند لشكل الخادم وكيف يعمل ، والذي لن يتم مشاركته داخل فريق التطوير فحسب ، بل حتى مع بعض الفنيين غير الفنيين. و SAM هو مفهوم واضح المعالم حيث ستتيح التمثيلات المجردة لأحد التطبيقات في المستقبل القريب إمكانية إعادة استخدامها من قبل فريق آخر باستخدام لغات ومنصات مختلفة تمامًا. لا تزال هذه الجوانب تحفزني بلا شك على التمسك باستخدام ميزة "نموذج بدون خادم".

بعض المواعيد الرائعة القادمة لإصدار هذا ، 25 ديسمبر ، 1 يناير تتبادر إلى الذهن ؛)

أعياد سعيدة جميعًا ، أتمنى أن أمنحك كل وقت تشغيل .NET Core 3.1 Lambda لعيد الميلاد ، لكنني أعتقد أن 2020 سيكون مثيراً بالنسبة لك لـ .NET و AWS.

أعياد سعيدة جميعًا ، أتمنى أن أمنحك كل وقت تشغيل .NET Core 3.1 Lambda لعيد الميلاد ، لكنني أعتقد أن 2020 سيكون مثيراً بالنسبة لك لـ .NET و AWS.

لا تقلق ، استمتع بالعطلات! لا أطيق الانتظار لرؤية ما لديك من أجلنا في 2020! :)

في انتظار دعم lambda الأصلي على .NetCore3.1

هناك حد لحجم القرص لوظائف لامدا. أعتقد أنه يبلغ 250 ميغا ، وعند استخدام وقت التشغيل المخصص ، يتعين علينا إرسال جميع التجميعات الأساسية لـ asp.net مع تطبيقنا. لقد وصلت إلى هذا الحد عندما كانت AWS تقوم بفك ضغط حزمة zip الخاصة بي. اضطررت إلى إجراء بعض التنظيف لتقليل المساحة التي يستخدمها تطبيقي. عندما يظهر الدعم المحلي ، لا يتعين علينا حزم تطبيقنا مع تجميعات .core.

هل هناك أي تقدير للوقت الذي يمكن أن نتوقع فيه الإفراج عن هذا؟

نحن في انتظار الترقية إلى .Net core 3.1 حتى يتوفر دعم أصلي لها.

هل هناك أي تقدير للوقت الذي يمكن أن نتوقع فيه الإفراج عن هذا؟

نحن في انتظار الترقية إلى .Net core 3.1 حتى يتوفر دعم أصلي لها.

إذا عدت إلى الوراء وقراءة الردود ، فسوف تقرأ من Normj أنهم لن يقدموا أي تقديرات.

إذا عدت إلى الوراء وقراءة الردود ، فسوف تقرأ من Normj أنهم لن يقدموا أي تقديرات.

ش ش ش ش عادة - نعم. ولكن إذا ظهر عدد كافٍ من الأشخاص باستخدام شوكات الملعب ، فربما يتم إعطاء إشارة إلى تاريخ الإصدار لقمع الاضطرابات: ابتسامة:

أتذكر بعض الوقت عندما قضت AWS وقتًا طويلاً في إعداد الصور الأصلية 2.1. لقد قالوا شيئًا مفاده أنهم أعادوا تصميم العملية لجعل نشر الإصدارات المستقبلية أسهل وأسرع للوقوف. أدخل NetCore 3.1 وبعد شهرين تقريبًا وما زال غير متاح :(

أنت تعلم أن Azure توفر هذه الصورة 3.1 في اليوم الأول. لقد بدأت في معرفة سبب اختيار حكومة الولايات المتحدة Azure كموفر سحابي لـ JEDI.

لقد حصلنا للتو على الضوء الأخضر من أصحاب المصلحة لدينا لبدء استهداف Azure كمزود أساسي لدينا وترك AWS بمثابة النسخة الاحتياطية. مع تأخيرات سخيفة كهذه ، أنا متأكد من أننا لسنا الوحيدين.

أتذكر بعض الوقت عندما قضت AWS وقتًا طويلاً في إعداد الصور الأصلية 2.1. لقد قالوا شيئًا مفاده أنهم أعادوا تصميم العملية لجعل نشر الإصدارات المستقبلية أسهل وأسرع للوقوف. أدخل NetCore 3.1 وبعد شهرين تقريبًا وما زال غير متاح :(

أنت تعلم أن Azure توفر هذه الصورة 3.1 في اليوم الأول. لقد بدأت في معرفة سبب اختيار حكومة الولايات المتحدة Azure كموفر سحابي لـ JEDI.

لقد حصلنا للتو على الضوء الأخضر من أصحاب المصلحة لدينا لبدء استهداف Azure كمزود أساسي لدينا وترك AWS بمثابة النسخة الاحتياطية. مع تأخيرات سخيفة كهذه ، أنا متأكد من أننا لسنا الوحيدين.

أنا أتفق معك. لا تسمح مؤسستي بوقت تشغيل مخصص ونحن عالقون نوعًا ما مع 2.1. عندما يتعلق الأمر بـ EF & Postgres جنبًا إلى جنب مع العمليات المكانية ، فإن الأمر يسبب الكثير من الألم. لقد كنا ننتظر أن يتم ذلك. من المؤسف أنه لم يتم القيام به بعد.

أتذكر بعض الوقت عندما قضت AWS وقتًا طويلاً في إعداد الصور الأصلية 2.1. لقد قالوا شيئًا مفاده أنهم أعادوا تصميم العملية لجعل نشر الإصدارات المستقبلية أسهل وأسرع للوقوف. أدخل NetCore 3.1 وبعد شهرين تقريبًا وما زال غير متاح :(

أنت تعلم أن Azure توفر هذه الصورة 3.1 في اليوم الأول. لقد بدأت في معرفة سبب اختيار حكومة الولايات المتحدة Azure كموفر سحابي لـ JEDI.

لقد حصلنا للتو على الضوء الأخضر من أصحاب المصلحة لدينا لبدء استهداف Azure كمزود أساسي لدينا وترك AWS بمثابة النسخة الاحتياطية. مع تأخيرات سخيفة كهذه ، أنا متأكد من أننا لسنا الوحيدين.

هل تستخدم JEDI .NET Core لفرضية أن هذا هو السبب الذي جعل الحكومة تتعامل مع Azure؟

مرحبا جميعا،

أنا أعمل بنشاط على جلب الدعم لـ .NET Core 3.1 في Lambda. يستغرق الأمر بعض الوقت لأن Microsoft قامت بالكثير من العمل في كيفية إنشاء وقت التشغيل. أنا أعمل على دمج هذه التغييرات لتوفير وقت تشغيل أصلي لك.

assyadh شكرا لك! لا أعتقد أن التأخيرات "سخيفة". في الواقع ، أفضل انتظار إصدار عمل قوي. أحب أن AWS Lambda يدعم .NET Core وأنا أقدر أنك تواصل دعمه ، كما وعدت.

أنا لا أفهم الدافع. ليس الأمر أنه ليس لدينا بيئة LTS في الوقت الحالي.

من الواضح أننا نريد استخدام الألعاب الجديدة ولكن فريق .NET في AWS لديه كمية ثابتة فقط من الموارد ولا يمكنهم فعل كل شيء في وقت واحد.

إلى جانب ذلك ، لا أتوق إلى الحاجة إلى التعجيل بتحديث جميع وقت تشغيل الوظائف خوفًا من أن تكون خارج شروط الخدمة.

جيد بالنسبة لك Kralizek لكن حالتك هي ملكك ولا تمثل الآخرين. إنها ليست "ألعابًا جديدة" حقًا الآن. يحتوي .NET Core 3.x (و ASP.NET Core) على تحسينات كبيرة تزيد عن 2.x بطرق متنوعة ويحرص المتبنون الأوائل على اعتمادها والاستفادة منها. كما يقول JamesQMurphy ، نفضل أيضًا أن يكون الإصدار قويًا.

أتطلع لرؤية عملكassyadh.

"أنا لا أفهم الدافع".

لا يمكننا استخدام NET Core 3.1 المشتركة في وظيفة .NET Core 2.1 lambda ، في الواقع لا يمكننا حتى استخدام رمز .NET Core 2.2 المشترك في وظيفة .NET Core 2.1 lambda ، لذلك اضطررنا مؤخرًا إلى تخفيض إصدارنا. مشاركة المكونات مع .NET Core 2.1 للحصول على دعم في الوظيفة.

هل يمكن تجميع المكونات المشتركة الخاصة بك في netstandard20؟ ثم يمكنك مشاركتها في netcore2 & 3

في حين أن هذا الموضوع خاص بـ .NET 3.1 ، فأنا متأكد من أن هذه المحادثة الدقيقة ستتم مرة أخرى عند وصول .NET 5 (أو 6 إذا كان ذلك سيكون LTS التالي).

بينما تم الاستشهاد ببعض الأمثلة المحددة حيث لا يكون ذلك ممكنًا (على سبيل المثال ، ملف الرمز البريدي كبير جدًا ، سياسة الشركة) ، _ بشكل عام _ إذا كنت تريد استخدام "أحدث وأكبر" NET Core من الآن فصاعدًا ، يمكنك القيام بذلك باستخدام القليل من إعادة هيكلة البناء وحزمة دعم وقت التشغيل المخصصة.

في هذا الوقت ، صادفنا أن نكون في مرحلة حيث كان الإصدار الأخير _أيضًا _ هو إصدار LTS ، والذي يبدو أنه يجعل الحاجة إلى الحصول عليه "في أسرع وقت ممكن" من Amazon تبدو أكثر "إلحاحًا" مما كان عليه ، على سبيل المثال ، وجود دعم مدمج 2.2 أو 3.0.

في النهاية ، هناك مفاضلة بين الميزات الجديدة التي يمكن استخدامها في Lambda مقابل جهود التطوير التي يجب وضعها مع حلول PaaS.

لم يكن NET Core 3.1 متاحًا حتى على Azure App Service من Microsoft لمدة 2-3 أسابيع بعد إصداره.

إذا كنت ترغب عمومًا في أن تكون على "حافة النزيف" في أسرع وقت ممكن ، فإن أخذ استثمار صغير في استخدام دعم وقت التشغيل المخصص على المدى القصير سيفتح لك إمكانية تشغيل أي إصدار مستقبلي من .NET Core في Lambda وفقًا للمقاييس الزمنية الخاصة بك. بالطبع المفاضلة هنا من بين أشياء أخرى هي الحزم الأكبر ، والكود أكثر قليلاً ، والحاجة إلى إجراء الترقيع الخاص بك.

مع كل شيء ، هناك توازن ومقايضة ، وبالنسبة للدعم المدمج ، سيكون هناك دائمًا تأخر في الإتاحة لأن البرنامج يستغرق وقتًا.

مع الإصدارات الرئيسية من .NET في نوفمبر من الآن فصاعدًا ، من المحتمل أن يكون لفترة عيد الميلاد / العطلة تأثير على المدة التي تستغرقها إتاحة هذه الأشياء المضمنة من حيث وقت فريق Lambda والسعة المتاحة.

فقط أضيف أفكاري. أنا أفهم مدى أهمية هذا الإصدار وأقدر إخبارنا به. أستخدم هذه التعليقات لدفع الحاجة الملحة إلى جانبنا. كما ذكر martincostello ، فإن توقيت إصدار .NET Core 3.1 لم يكن رائعًا بسبب الأعياد ولكن أيضًا أثناء إعادة الابتكار.

كنت الرجل الذي ذكر في الماضي لـ 2.1 أنني قفزت الأتمتة التي وضعناها ستسرع الإصدار المستقبلي. لقد ساعدتنا الأتمتة التي

لذا رجاءً صدقوني أن NET Core 3.1 هو assyadh ، وأنا وكثيرين آخرين كأولوية قصوى

فقط للتحقق ، هل يبدأ العمل على دمجها بمجرد إصدار Microsoft للإصدارات المسبقة بدلاً من انتظار الإصدار النهائي؟ من المفترض أن يقلل ذلك من تأثير الكريسماس ويسمح بتسليمه قريبًا بمجرد صدور الإصدار النهائي لأنه سيحتاج فقط إلى الاختبار.

أستخدم هذه التعليقات لدفع الحاجة الملحة إلى جانبنا

شكرا لك على هذاnormj. هذا هو مبلغ 0.02 دولار ، على أمل أن يساعد ذلك أيضًا في التبشير.

كما ذكر martincostello ، فإن توقيت إصدار .NET Core 3.1 لم يكن رائعًا بسبب الأعياد ولكن أيضًا أثناء إعادة الابتكار.

كما ألمح mungojam إلى ، كان NET Core 3.1 متاحًا في نموذج المعاينة بدءًا من 15 أكتوبر ، قبل أكثر من شهر من الإصدار. أيضًا ، إنه في الأساس إصدار لإصلاح الأخطاء 3.0 - لا أعرف أدواتك ولكني أتخيل أن العمل الاستكشافي كان يمكن أن يبدأ باستخدام 3.0 ، والذي تم إصداره في 23 سبتمبر وفي المعاينة طوال العام . من الجدير بالذكر أن الإصدار 3.1 تم إعطاؤه موعدًا تقديريًا للإصدار في إعلان الإصدار 3.0.

لم يكن NET Core 3.1 متاحًا حتى على Azure App Service من Microsoft لمدة 2-3 أسابيع بعد إصداره.

كان NET Core 3.1 متاحًا في Azure Functions في 17 أكتوبر ، بعد يومين من إصدار Preview 1.

يمكنك أن تقول ما تريده بشأن احتياج أي شركة إلى 3.1 على الفور ، سواء كان ذلك "ميزة النزيف" ، أو خيارات وقت التشغيل المخصصة ، وما إلى ذلك ، ولكن هذا حقًا جزء من صورة أكبر حول مدى جدية AWS في دعمنا لنا. NET عملاء. إذا كانت AWS - وليس فريق Norm ، ولكن AWS بشكل عام - قد جعلته أولوية ، فلا بد لي من التفكير في أنه كان من الممكن أن يكونوا أمام هذا ، مع التأكد من أنهم يتنافسون مع Azure.

أنا شخصياً أقدر حقًا وجود خيارات بين العروض السحابية التي يمكنني اختيارها بناءً على الجدارة بدلاً من عقيدة الشركة ، وأود أن أرى AWS تتخذ الخطوة التالية في تحسين دعم NET.

شكراً normj و assyadh وأي آخرين يعملون على هذا لجهودكم.

من المحتمل أن يكون فريق .NET في AWS قد بدأ جيدًا رحلته في التحضير لـ .NET 3.1 LTS عند إصدار معاينة 3.0. الشيء هو أن AWS تميل إلى أن تكون غير واضحة بشأن ما يعملون عليه خلف الستائر. هذا النقص في الشفافية يولد الافتراضات. أعتقد أنه لن يضر أن يكون لديك نوع من خارطة الطريق ، حتى لو كانت مؤقتة والتواريخ عرضة للتغيير ، وما إلى ذلك.

أعتقد أن المشكلة تكمن في أن فريق AWS لا يريد طرح أي نوع من ETA وبالتالي يتم وضع المطورين في الظلام. يقول normj أن هذا لأنه لا يريد أن يقوم أي شخص أو أي شركة بوضع خطط مستقبلية بناءً على تلك ETAs. أليس الفهم العام أن ETA هو مجرد تقدير ولا ينبغي لأي شركة أن تضع خططًا جادة بناءً على تقديرات شركة أخرى ، وحتى لو فعلت ذلك ، فلا يمكن للشركة إلقاء اللوم على AWS أو أن تغضب منها لفقدانها ETA؟

الوقت المقدر للوصول ليس يومًا محددًا. يمكن أن يكون شهر. ربع. ويجب أن نكون على ما يرام مع أي ETA ولا بأس إذا تم تفويتها.

انظر الى
https://docs.aws.amazon.com/lambda/latest/dg/runtime-support-policy.html
يبدو أن AWS تلغي وقت التشغيل بعد وقت قصير من انتهاء عمر إصدار وقت التشغيل هذا.

لأن إصدارات .NET Core LTS مدعومة لمدة 3 سنوات نحن بالفعل
"قضاء الوقت الذي يمكننا فيه استخدام .NET Core 3.1 lambdas".
لذلك ، أفهم أن الأشخاص مريضون داخليًا للحصول على .NET core 3.1 على lambdas.
راجع للشغل ، أفضل أيضًا إطلاق الصخور الصلبة ثم اندفاع شيء ما.

أفترض أنه سيكون متاحًا في الشهر أو الشهرين المقبلين ، لكن بعض الالتزام من AWS ،
حتى لو كان التحفظ الشديد قد يكون مفيدًا للفرق في التخطيط لعملياتها.

شيء آخر هو أنه في هذا الوقت من OSS: هل يستطيع مجتمع .NET المساعدة؟ نحن نتحدث على جيثب بعد كل شيء.
هل هذا وقت التشغيل "المدمج" هو رمز مغلق؟

أيضًا ، ستكون ميزة KILLER إذا كان لعملية النشر مفتاح للقيام بـ ReadyToRun وميزات تجميع AOT الأخرى ، لذا فإن أوقات البدء البارد تنخفض بشكل خطير.
من شأن ذلك أن يجعل NET Core جذابًا للغاية على AWS Lambda ، IMO.

normj والفريق:
شكرًا لك على جعل .NET core رائعًا على AWS

فقط أضيف أفكاري. أنا أفهم مدى أهمية هذا الإصدار وأقدر إخبارنا به. أستخدم هذه التعليقات لدفع الحاجة الملحة إلى جانبنا.

يرجى استخدام هذا المنشور لدفع الاستعجال إلى جانبك. مع أخذ ذلك في الاعتبار ، ها هي بنساتي.

فقط للتحقق ، هل يبدأ العمل على دمجها بمجرد إصدار Microsoft للإصدارات المسبقة بدلاً من انتظار الإصدار النهائي؟

سئل: هل نحصل على إجابة صادقة على هذا السؤال؟

يبدو أن الإجابة بديهية. يبدو أن أولوية .NET هي "مستوى الهوايات" وليست "على مستوى المؤسسة" كما ينبغي.

لقد سمعت في مكان ما أن 1) تم جعل عناصر Net Core بأكملها مفتوحة المصدر ، و 2) توجد بعض برامج التبني المبكرة التي تتيح لك "بدء التشغيل" عند الإصدار الفعلي. (انظر جوجل للحصول على التفاصيل.)

أنا مضحكة هنا ، ولكن الحقيقة هي أن كل من يتابع .NET يعرف هذا ، لذا فهو يضيف إلى الدليل الذاتي الذي أتحدث فيه.

بصراحة ، بعد التأخيرات 2.1 في الإصدار ، كنت آمل أن التغييرات التي تم إجراؤها في ذلك الوقت تعني أنه في هذه المرة تقريبًا (3.1) سيكون لدينا دعم للإطار الجديد لمدة لا تزيد عن أسبوعين من الإصدار الفعلي. أعني أنه في غضون ساعات من الإصدار سيكون مثاليًا ، لكن إعطاء بعض المساحة لللمسات النهائية / التلميع ، في غضون أسبوعين ، يبدو أنه صحيح.

ولكن ها نحن هنا منذ ما يقرب من شهرين ويبدو الأمر مجرد "هواية على مستوى العش".

@ rati-dzidziguri أتفهم وأقدر أنك تريد ETA حتى تتمكن من التخطيط وفقًا لذلك. في الواقع ، هذا هو السبب في أننا عمومًا لا نعطي ETA لأننا نحاول جاهدًا عدم تقديم وعود لسنا متأكدين بنسبة 100٪ من قدرتنا على الوفاء بها.

هذا تفكير "على مستوى الهواية" ، كما يقولabukres بأناقة:

أعتقد أن المشكلة تكمن في أن فريق AWS لا يريد طرح أي نوع من ETA وبالتالي يتم وضع المطورين في الظلام. يقول normj أن هذا لأنه لا يريد أن يقوم أي شخص أو أي شركة بوضع خطط مستقبلية بناءً على تلك ETAs. أليس الفهم العام أن ETA هو مجرد تقدير ولا ينبغي لأي شركة أن تضع خططًا جادة بناءً على تقديرات شركة أخرى ، وحتى لو فعلت ذلك ، فلا يمكن للشركة إلقاء اللوم على AWS أو أن تغضب منها لفقدانها ETA؟

الوقت المقدر للوصول ليس يومًا محددًا. يمكن أن يكون شهر. ربع. ويجب أن نكون على ما يرام مع أي ETA ولا بأس إذا تم تفويتها.

أعتقد أن حقيقة خسارة AWS لعقد JEDI لصالح Azure ، كان ينبغي أن تكون كافية لبدء بعض اجتماعات تحديد الأولويات داخليًا لأنها تثبت ، في ظاهرها ، أن .NET هي مسعى "على مستوى المؤسسة" ويجب التعامل معها على هذا النحو. بدلاً من إهدار الموارد في محاولة "رفع دعوى" على القرار ، استخدم هذه الموارد داخليًا لمنح مجتمع .NET بعض الحب. استخدم هذا كلحظة لإعادة ترتيب أولويات .NET بحيث يكون الإصدار التالي من .NET ، AWS على رأسه ، ويوضح أنه على استعداد لبدء العمل.

normj و martincostello وبقية النحل العامل هناك في AWS ، يعملون بجد لتقديم عرض SOLID .NET ، يرجى فهم أن هذه الشكاوى (المجتمعية) ليست معك في حد ذاتها ، بل تتعلق بالثقافة / السياسة التي تملي تفويض الأولوية الذي تم إعطاؤه لك فيما يتعلق بـ .NET. الرجاء استخدام هذا المنشور للمساعدة في الحصول على دعم "على مستوى المؤسسة".

أرى بشكل أساسي أن هذه فرصة ضائعة لكي تتألق AWS. تخيل لو أن اتباع إصدار LTS الجديد سيكون ذا أولوية عالية. يا له من بيان قوي سيكون.

أشياء كهذه تجعلنا المطورين / المهندسين المعماريين نفقد الحجج ضد صانعي القرار غير التقنيين عندما نحتاج إلى تحديد السحابة التي يجب استخدامها للمشروع التالي. في هذه الأيام عندما يكون لكل من Azure و AWS عروض متساوية في التكلفة والميزات ، يتم اتخاذ القرارات بشكل أكبر بشأن السياسة والإدراك. ليس لدي ما أحضره عندما يقولون "لقد مرت X أسابيع / أشهر على الإصدار الرسمي وما زالت AWS غير جاهزة"

مرة أخرى ، مثلما يقول @ VagyokC4 ، هذا ليس شخصيًا ضد الموظفين الذين يقومون بالعمل الفعلي ، ولكنه أكثر من دعوة للاستيقاظ لإدارة AWS العليا.

قد يفكر كل شخص يقوم بعمل .NET Core 3.1 Lambda في تمكين IL Trimming. على الأرجح ستعمل على تقليل حجم ملفاتك المضغوطة.
https://www.hanselman.com/blog/MakingATinyNETCore30EntirelySelfcontainedSingleExecutable.aspx

هل تم إنشاء .NET core lambda 3.1 باستخدام RuntimeAPI؟
في العراء ، على جيثب؟
إذا كانت الإجابة "لا" ، فلماذا؟

كل ما أريده .... عيد الحب هو دعم lambda .net core 3.1

كل ما أريده .... عيد الحب هو دعم lambda .net core 3.1

لا يتدحرج لسانه بالضبط ، لكنه طنين:

لا أريد الكثير لعيد الميلاد عيد الحب
هناك شيء واحد أحتاجه
لا يهمني الهدايا
تحت شجرة AWS
أنا فقط أريده من أجل بلدي
أكثر مما يمكن أن تعرفه
اجعل أمنيتي تتحقق أوه
كل ما أريده لعيد الحب هو دعم NET Core 3.1 ...

:ابتسامة:

تقوم Microsoft بتضمين تراخيص Go Live في نهاية دورة المعاينة الخاصة بهم عندما لا يتم إدخال أي تغييرات عاجلة. بحلول هذه المرحلة ، يقدمون دعمًا للإنتاج لهذا الإصدار القادم. ستنتظر توصيتي حتى يصدروا إصدارًا بترخيص Go Live ثم يبدأون العمل على الأدوات. مع .NET Core 3.1 جاء في Preview 3 الذي تم إصداره في 11/14. في هذه الحالة ، لم يكن RTM قد تأخر حتى 3 أسابيع في 12/3 ، لكنك لا تزال أقرب إلى طرح الميزات عندما تصل RTM ويبدأ العملاء في بناء التوقعات.

فقط 0.02 دولار

كل ما أريده .... عيد الحب هو دعم lambda .net core 3.1

لا يتدحرج لسانه بالضبط ، لكنه طنين:

لا أريد الكثير لعيد الميلاد ~ عيد الحب
هناك شيء واحد أحتاجه
لا يهمني الهدايا
تحت شجرة AWS
أنا فقط أريده من أجل بلدي
أكثر مما يمكن أن تعرفه
اجعل أمنيتي تتحقق أوه
كل ما أريده لعيد الحب هو دعم NET Core 3.1 ...

😁

+1 :)

هل يوجد أي تحديث لوقت تشغيل .NET Core 3.1 الخاص بـ Lambda؟

لقد بدأنا مشروعًا جديدًا وكنا نميل بشدة إلى استخدام Lamba لغالبية المستخدمين الذين ليس لديهم خادم ، ولكن معرفة الوقت الذي يستغرقه الحصول على إصدار LTS مدعوم يجعلنا نعيد التفكير ، وربما نغير البنية أو المزود.

<Rant>
إنه لأمر محبط أن سياسة دعم AWS Lambda Runtime صارمة للغاية حول نافذة 30 يومًا ، عندما يتم طلب ميزات مثل هذه لمدة تزيد عن 30 يومًا. بعد ذلك ، ستنشر AWS ذات يوم بشكل سحري هذه الميزة وسيتعين على الجميع التدافع للانتقال إلى .NET Core 3.1. يؤدي هذا إلى وضع معظم المؤسسات في مكان سيء نظرًا لأن الأمر يستغرق في كثير من الأحيان وقتًا أطول من شهر لإصلاح واختبار ونشر شيء ما في بيئة الإنتاج. لقد كنت شخصياً في مؤخرة هذه السياسة. مرة واحدة (بسبب قيود الموارد والأولويات العليا الأخرى) شركة كنت أتركها هذه المرة. لم نتمكن من ترقية Lambdas إلى .NET Core 2.1 بعد مرور 3 أشهر. بمجرد أن حاولنا نشر lambda مع CloudFront ، حدث شيء سيء (ماذا؟ من يدري لأن سجلات CF غير مهمة) وتحتاج إلى التراجع. إلا أنه لم يكن هناك وقت تشغيل للعودة إليه. وبالتالي فإن النشر هو LOCKED . فتحنا تذكرة على الفور. بعد مرور 24 ساعة ، تلقينا ردنا الأول وهو "حذف المكدس بالكامل والبدء من جديد". وهو رد يجهل تمامًا نظرًا لأنه كان سيأخذ جداول DynamoDb الخاصة بنا مع عملية "الحذف". لقد تم حبسنا في هذا التراجع لأكثر من أسبوعين ونصف. في النهاية حصلنا على مهندس دعم فهم تقنيات الحاويات وساعدنا على التراجع ثم بقينا على الخط حتى نجح CloudFormation الخاص بنا. التي فعلت ذلك بشكل جيد ، لا تغيير في المحاولة الأولى. وهذا ما يجعلني أكره الآن CF ، لأنه مزاجي للغاية للاستخدام.
</Rant>

TL ؛ DR ؛ إن سياسة AWS Lambda Runtime Support غير سارة للعمل معها ويمكن أن تجعلك في حالة ساخنة.
https://docs.aws.amazon.com/lambda/latest/dg/runtime-support-policy.html

CraigHead آسف

نعم ، لقد كان الترحيل من .NET Core 2.0 إلى .NET Core 2.1. آسف على التشدق. 30 يومًا ضيق نوعًا ما بالنسبة للبعض منا. بالنظر إلى الطول الكلي ، من المحتمل أن تعمل لامدا بدون صيانة كبيرة وتأكيد جواب إضافي.

في غضون ذلك ، يحدث هذا في جانب Azure من عدم وجود خادم
https://visualstudiomagazine.com/articles/2020/01/30/azure-functions-3-0-runtime.aspx

في غضون ذلك ، يعمل فريق AWS على ذلك. تعليقات Snarky لا تساعد
معهم. سيقومون بتحديث هذه المشكلة عندما تكون جاهزة.

يوم الثلاثاء 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-lambda-dotnet/issues/554؟email_source=notifications&email_token=AAAZVJXAAYET4F7PFFOTO3LRCLUETA5CNFSM4JU5UTJKYY3PNVWWK3TUL52HS4DFVREXG43
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AAAZVJQK3NBVXBZALM4V5KLRCLUETANCNFSM4JU5UTJA
.

لم تكن وجهة نظري هي وضع تعليق لاذع ولكن للإشارة إلى أنه حتى MS أعلنت عن توفر GA لـ 3.1 مؤخرًا ، لذلك آمل أن أرى AWS ينهي عملها على دعم 3.1 قريبًا.
.

في غضون ذلك ، يحدث هذا في جانب Azure من عدم وجود خادم
https://visualstudiomagazine.com/articles/2020/01/30/azure-functions-3-0-runtime.aspx

بالنظر إلى أنها لغة MS ، فليس من المستغرب أن تتفوق Azure على AWS لدعم ذلك.

تراقب هذا الموضوع عن كثب - أتطلع إلى ترقية C # Lambdas.

تم إصدار dotnet core 3.1.0 2019-12-03
https://dotnet.microsoft.com/download/dotnet-core/3.1

كان متوفرا في Azure في 2020-01-23
https://azure.microsoft.com/en-us/updates/azure-functions-runtime-30-is-now-available/

نحن أقصر قليلاً من شهر إضافي مقارنةً بـ Azure

راجع للشغل ، تتم جميع عمليات التطوير الأساسية لـ .NET في العراء على github
لذلك ، لا ينبغي أن يكون لكونك "لغة MS" تأثير كبير.
أو تقترح أن عملاء AWS الذين يستخدمون dotnet أفضل من Azure: P؟

على أي حال ، لأي شخص يستمع إلى AWS:
نحن ننتظر 3.1 على Lambda ، هذا مهم بالنسبة لنا.

راجع للشغل ، تتم جميع عمليات التطوير الأساسية لـ .NET في العراء على github
لذلك ، لا ينبغي أن يكون لكونك "لغة MS" تأثير كبير.
أو تقترح أن عملاء AWS الذين يستخدمون dotnet أفضل من Azure: P؟

أعني ، سيكون من المحرج بعض الشيء ألا تدعم منصة Microsoft Cloud Platform الميزات الجديدة للغة الخاصة بهم. لأكون صادقًا ، أنا مندهش قليلاً من أن الأمر استغرق أكثر من شهر ونصف بقليل! ربما كان من الممكن أن يؤدي المزيد من الاتصالات الداخلية إلى السماح لكليهما بالإفراج عنهما في نفس الوقت.

أعتقد أن AWS تبلي بلاءً حسنًا مع دعمها .Net ، خاصةً مع حزم التطوير التي ترتبط بخدماتها مثل CloudWatch + ILogging وربط تكوين معلمات SSM. لقد ساعدنا كثيرًا.

آمل أن نرى الإصدار 3.1 قريبًا على الرغم من :)

أتمنى أن يكون هناك تطبيق ملموس أفضل لـ Cloudwatch ILogger . سيتم دمج هذا بشكل أفضل في ServiceCollection / ServiceProvider عند استخدام Lambda SDK. الإصدار الحالي الذي يتم توفيره في سياق الطلب وفئة LambdaLogger الثابتة من المستحيل أساسًا اختبار الوحدة / التحقق من إخراج السجل وربط نتائج .netcore ConsoleLogProvider الافتراضية في سجلات Cloudwatch الفوضوية.

أتمنى أن يكون هناك تطبيق ملموس أفضل لـ Cloudwatch ILogger .

هل جربت https://github.com/aws/aws-logging-dotnet#aspnet -core-logging؟

ماذا تريد أن تبدو سجلاتك مثلCraigHead؟

لقد استخدمنا Serilog & https://github.com/structured-log/structured-log في الماضي لإخراج سجلات وحدة تحكم لطيفة وكذلك السجلات المستندة إلى JSON والتي تم استيرادها إلى التسلسل. https://datalust.co/ كانت هذه أفضل طريقة بالنسبة لنا للحصول على سجلات مركزية بتنسيق رائع حقًا.

CraigHead Amazon.Lambda.Logging.AspNetCore هو تطبيقنا لدمج تسجيل Lambda في IServiceCollection. هل هذه المكتبة لا تعمل من أجلك.

لا أوصي بحزمة AWS.Logger.AspNetCore من ttps: //github.com/aws/aws-logging-dotnet#aspnet -core -logging لـ Lambda. تستخدم هذه المكتبة مؤشر ترابط في الخلفية لدفع السجلات إلى CloudWatch Logs. لا يعمل استخدام خيط في الخلفية مثل هذا بشكل جيد مع Lambda الذي يجمد بيئة حساب Lambda بمجرد عودة معالج الوظيفة مما يعني أن مؤشر ترابط الخلفية قد لا يحصل على فرصة لمسح الرسائل في قائمة الانتظار.

لم أكن أعرف عن هذا. شكرا على البقشيش!
كنت أشير إلى Amazon.Lambda.Core.LambdaLogger في SDK.
سوف أتحقق من هذه الحزمة بالتأكيد ( Amazon.Lambda.Logging.AspNetCore ).

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

تضمين التغريدة
في lambda-land AFAIK ، لا يوجد أي حدث يُعلمك بأن المثيل الحالي سيتوقف عن المعالجة أو سيتم إنهاؤه ، لذلك سيظل اقتراحك يترك أحداث السجل المخزن بدون مسح (مفقود).

من فضلك لا تختطف هذا الموضوع لاحتياجات أخرى.
تم إنشاء هذا الخيط لإعطاء بعض المعلومات عندما يكون NET Core 3.1 على AWS Lambda متاحًا.
ولإعلام AWS بأننا في الخارج وننتظر.

هل سيتم تضمين أداة اختبار lambda في الإصدار 3.1؟ https://github.com/aws/aws-lambda-dotnet/tree/master/Tools/LambdaTestTool

هذا هو نيتي. يجري العمل في النموذج التجريبي 31 . التحسن الكبير في الفرع 3.1 هو أن كود Lambda المستخدم يعمل الآن في AssemblyLoadContext منفصل والذي يجب أن يصلح الكثير من تعارضات الإصدار التي واجهها المستخدمون مع الإصدار الحالي. إنني أتطلع إلى الخلف لنقل ميزة AssemblyLoadContext إلى الإصدار 2.1.

كملاحظة جانبية. لقد ناقشت حول تحويل واجهة المستخدم المجردة إلى تطبيق Blazor من جانب الخادم. هل لدى أي شخص لديه خبرة أكبر في Blazor أي ملاحظات حول ما إذا كانت هذه فكرة جيدة أم سيئة؟

كملاحظة جانبية. لقد ناقشت حول تحويل واجهة المستخدم المجردة إلى تطبيق Blazor من جانب الخادم. هل لدى أي شخص لديه خبرة أكبر في Blazor أي ملاحظات حول ما إذا كانت هذه فكرة جيدة أم سيئة؟

أي شيء من Blazor في هذه المرحلة هو فكرة جيدة ، خاصة بالنسبة لأولئك منا الذين يهزون DotNet!

"bare bones UI" - هذا تطبيق آخر غير متصل بـ .NET Core 3.1 Lambdas؟
راجع للشغل ، لا يهمني بليزر على الإطلاق

petarrepac كان هذا في إشارة إلى AWS .NET Mock Lambda Test Tool التي قمنا بشحنها للمساعدة في تصحيح وظائف .NET Core 2.1 Lambda. ها هو المنشور للرجوع إليه

أنا بصدد تحديث الأداة لـ .NET Core 3.1.

تضمين التغريدة
آه ، لم أفهم ذلك ، شكرًا
من المثير للاهتمام أننا لم نكن بحاجة إلى مثل هذه الأداة

من وجهة نظرنا ، فإن lambda عبارة عن AspNetCore HttpApi المجردة يمكنك الاتصال محليًا والاختبار محليًا
الاختلاف الوحيد هو ملف / فئة نقطة الدخول التي تقل عن 50 سطرًا من التعليمات البرمجية
أيضًا ، لا يمكن اختبار الكثير من الأشياء بشكل صحيح إلا عند نشرها في AWS:

• أذونات
• شكل أحداث JSON المتلقاة والسياق
• ...
  لذلك ، مزيج من:
• اختبارات وحدة / تكامل جيدة تعمل محليًا
• اختبار http المحلي
• سهل النشر لاختبار بيئة AWS
  يمكن أن تذهب بعيدا

أو أفتقد بعض السيناريوهات الواضحة؟

petarrepac هذه إحدى الفوائد الكبيرة لاستخدام جسر ASP.NET Core هو أنه من السهل حقًا تشغيله محليًا. أوافق على أن أفضل ممارسة هي استخدام اختبار الوحدة / التكامل ولكن غالبًا ما تكون هناك احتياجات للاختبار السريع المخصص لمنطق التطبيق وهذا هو ما تعتبره هذه الأداة جيدة.

شكرا لكمnormj. بالنسبة إلى Blazor ، يمكن أن تكون لمسة لطيفة. بالنسبة لحالة استخدام فريقنا على الأقل ، من المحتمل ألا يتم استخدامها.

نحن فقط في واجهة المستخدم لفترة كافية لإرسال حمولة ، ثم ننتقل عبر الكود في VS.

يمكنك بالتأكيد تحقيق العديد من وظائف lambda من قاعدة رمز واحدة باستخدام Lambda Bootstrapper وميزة وقت التشغيل المخصصة.

لدي مجموعة من 16 لامدا يتم نشرها من تطبيق واحد ، بدلاً من "متراصة".

يتم تحقيق ذلك باستخدام متغير البيئة _handler لاختيار الطريقة المراد استخدامها في وقت التشغيل ، بدلاً من التعيين الثابت الترميز واحد لواحد الموضح في نموذج التعليمات البرمجية لمشاركة المدونة.

أعتقد أنه تطبيق وحدة تحكم يتلقى مفتاحًا يخبره بالإجراء الذي يجب أن "يصبح" عند بدء التشغيل.

تضمين التغريدة

أواجه بعض المشاكل في سحب هذا بناءً على شرحك. لدي حوالي 20 وظيفة Lambda في Functions.cs الخاصة بي مرتبطة بالتعريفات المقابلة في serverless.template. أتفهم أنك ستمرر متغير بيئة مع كل تعريف للإشارة إلى الوظيفة التي يجب استدعاؤها. معظم هذه الوظائف هي من التوقيع:

APIGatewayProxyResponse هذه الوظيفةLambdaFunction (طلب APIGatewayProxyRequest ، سياق ILambdaContext)
{

كيف أضيف دعمًا لتوقيعات دالة lambda المختلفة ، إذا كانت لدي وظائف أخرى تأخذ وسيطات مختلفة (بخلاف APIGatewayProxyRequest) وأنواع إرجاع مختلفة؟

من فضلك لا تخرج عن مسار الموضوع.

twopointzero لقد قضيت أيامًا في Google في البحث عن حل لتشغيل وظائف lambda المتعددة باستخدام مشروع .NET Core 3.1 Custom Runtime. لا يوجد موضوع آخر ذي صلة على الإنترنت وأنا أرد على مشاركة موجودة قدمت بصيصًا من الأمل في وجود حل لمشكلتي.

عدم وجود دعم أصلي لـ .NET Core 3.1 في AWS يجعل الحياة صعبة. نحتاج إلى الترقية إلى الإصدار 3.1 من أجل الترقية إلى أحدث إصدار من EntityFramewore Core 3.1.2 ، والذي يعمل على إصلاح المشكلات التي نراها مع تجميع الاتصالات في Aurora (PostgresSQL).

normj أنا أفهم تمامًا موقف "لا إيتا" ولكن هل يمكن أن تخبرني ما إذا كنا قريبين؟ <30 يومًا؟

antsaia مع الاحترام ، كان تعليقك

وحتى لا أخرج هذا الخيط عن مساره بنفسي ، فهذا تعليقي الأخير على الموضوع.

normj هل هناك أي مورد متاح (مدونة ، منتدى ، إلخ) حيث يمكننا الحصول على معلومات حول حالة تنفيذ دعم .net core 3.1؟

أزور هذه الصفحة يوميًا على أمل الحصول على أي معلومات جديدة ولكن من الواضح أنه لا توجد معلومات كافية (لأنها ليست مخصصة لهذا الاستخدام). سيسهل الأمر كثيرًا إذا كان لدينا نوع من التحديث الأساسي حتى نتمكن من التخطيط مسبقًا.

مثل الكثيرين هنا ، تعتمد خطتنا لتقديم الميزات إلى حد كبير على ما إذا كان بإمكاننا استخدام 3.1 أو إذا كان علينا تطويره باستخدام 2.1. في حالتي ، سيقدم الإصدار 3.1 الدعم لـ System.Draw وهذا له تأثير كبير على الميزة التي سأعمل عليها.

كل ما أريده .... عيد القديس باتريك هو دعم lambda .net core 3.1

@ liam-sage ، كل ما استطعت العثور عليه هو بعض المنشورات في منتدى أمازون تشير إلى أنه سيكون جاهزًا في الربع الأول من عام 2020. https://forums.aws.amazon.com/thread.jspa؟

@ liam-sage ، كل ما استطعت العثور عليه هو بعض المنشورات في منتدى أمازون تشير إلى أنه سيكون جاهزًا في الربع الأول من عام 2020. https://forums.aws.amazon.com/thread.jspa؟

هذا يعني أنه يجب أن يبدأ البث المباشر في شهر مارس. أنا في انتظار.

مرحبًا ، أعلم أنه ليس مناسبًا تمامًا ولكن يمكنك تحديث لامبدا الخاصة بك إلى dotnetcore 3.1. في هذه الأثناء أثناء انتظارك ، أقترح عليك إنشاء الكثير من lambdas لكتابة قالب dotnetcore الخاص بك. لقد فعلت ذلك من أجل بلدي. أردت التأكد من أنني لست مضطرًا لإضاعة ساعات مع الكود المعياري. يمكن العثور على مثال لقالب هنا .

وفنسنت ، كيف نستضيفه هناك؟ باستخدام وقت تشغيل مخصص؟
يوم الخميس ، 5 مارس 2020 ، الساعة 7:40 مساءً. Vincent van der Walt <
[email protected]> كتب:

مرحبًا ، أعلم أنه ليس مناسبًا تمامًا ولكن يمكنك الحصول على لامبدا الخاصة بك
تم التحديث إلى dotnetcore 3.1.2 في هذه الأثناء أثناء انتظارك أود أن أقترح
إذا قمت بإنشاء الكثير من lambdas لكتابة قالب dotnetcore الخاص بك. فعلت
هذا من أجل بلدي. أردت التأكد من أنني لست مضطرًا لإضاعة ساعات مع
كود معياري. يمكن العثور على مثال لقالب هنا
https://github.com/vincentvanderwalt/aws-lambda-dotnetcore-3-template .

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/aws/aws-lambda-dotnet/issues/554؟email_source=notifications&email_token=AGIDH4OWUT7Y3HR3O5KARBDRF62V3A5CNFSM4JU5UTJKYY3PNVWWK3TUL52HS4DFVREXG43VM13TUL52HS4DFVREXG43VM25
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AGIDH4PLKFSDLNBX2QVMG63RF62V3ANCNFSM4JU5UTJA
.

نعم ، إنه يستفيد من وقت التشغيل المخصص.

يمكنك تشغيله محليًا على جهازك أو نشره في نظام AWS.

F5 للمحلي و dotnet lambda deploy-serverless للنشر في aws

يشرح الملف التمهيدي كيفية تثبيت القالب على جهازك المحلي (إنه قالب dotnetcore)

أوقات التشغيل المخصصة رائعة ، لكنني ما زلت أنتظر دعم AWS الكامل لـ .Net Core 3.1 لأجهزة lambdas لاستخدامها في بيئات الإنتاج 😄

في كل مرة أرى هذا في صندوق الوارد الخاص بي ، أفتحه بفارغ الصبر لمعرفة ما إذا كان
أعلن عن أي شيء فقط للعثور على منشور غير مفعّل قليلاً على الأقل
عنوان. طلب شخص آخر من الآخرين عدم اختطاف الخيط ولم يفعل ذلك
عمل. هل يمكن لشخص ما قفل الخيط حتى يكون شخص ما جاهزًا للإعلان عن ملف
الافراج عن دعم 3.1؟

يوم الجمعة 6 مارس 2020 الساعة 7:13 صباحًا bartoszsiekanski [email protected]
كتب:

أوقات التشغيل المخصصة رائعة ، لكنني ما زلت أنتظر دعم AWS الكامل
بالنسبة لـ .Net Core 3.1 لأجهزة lambdas لاستخدامها في بيئات الإنتاج 😄

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/aws/aws-lambda-dotnet/issues/554؟email_source=notifications&email_token=AAVUT3SNDR4L2ZL5J4KQYDDRGDSHBA5CNFSM4JU5UTJKYY3PNVWWK3TUL52HS4DFVREXG43TUL52HS4DFVREXG43
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AAVUT3TBH3NIBMGB54EFCR3RGDSHBANCNFSM4JU5UTJA
.

الرجاء إنشاء مشكلات منفصلة لأي شيء آخر غير مناقشة دعم NET Core 3.1. هل يمكنني إغلاق هذه المسألة حتى يكون لدينا المزيد من الأخبار normj ؟

@ hounddog22030 لم أدرك أنني كنت "أختطف" الموضوع. كنت أقترح أنه بدلاً من السؤال باستمرار عما إذا كان جاهزًا ، هناك طرق بديلة إذا كان الناس يائسين للانتقال إلى dotnetcore 3.1. سيكون دعم وقت التشغيل الرسمي غير المخصص جاهزًا عندما يكون جاهزًا. يجب على الناس فقط أن يكونوا أكثر صبرًا أو أن يبحثوا عن نهج بديل.

إذا كانت AWS تدعم الخيار المضمَّن ذاتيًا في أمر حزمة dotnet lambda ، فيجب أن تكون وظائف lambda قابلة للتنفيذ بغض النظر عن إصدار SDK الخاص بها. حق؟ لماذا لا تفعل ذلك بدلاً من إضافة دعم لكل إصدار من NET Core.

إذا كانت AWS تدعم الخيار المضمَّن ذاتيًا في أمر حزمة dotnet lambda ، فيجب أن تكون وظائف lambda قابلة للتنفيذ بغض النظر عن إصدار SDK الخاص بها. حق؟ لماذا لا تفعل ذلك بدلاً من إضافة دعم لكل إصدار من NET Core.

لقد وصفت للتو ميزة وقت تشغيل lambda المخصصة

aussiearef يعمل هذا جيدًا بالفعل ، لكن الحزمة المضمنة ذاتيًا تتضمن .Net Core نفسها ، والتي تضيف عادةً ما يصل إلى 40 ميجابايت على الأقل (مضغوط) لموقع ويب - لا تترك مساحة كبيرة للتطبيق والاعتماديات نفسها.

عند استخدام نفس الإصدار من .NET core ، يكون وقت التشغيل المخصص أبطأ (بدء التشغيل البارد) من وقت التشغيل الأصلي. يضيف الإصدار 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 ، كتب نورم جوهانسون ، [email protected] :

وخرج مع بقاء 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 سأترك لك شرف إغلاق هذا الموضوع.

عمل جيد!

هذا هو AWS Baby. هذا هو AWS !!!
بغض النظر عما يحدث ، في النهاية ، ينجزونه.

شكرا جزيلا يا فريق !!!

نبأ عظيم وشكرا جزيلا raRaRanormj !!! في خطر أن تبدو أحمقًا و / أو جشعًا ، فهل هذا يعني أيضًا جوهريًا Powershell 7 أيضًا؟ فقط فحص مزدوج ......

عمل رائع normj والجميع في AWS! 🥳

إليك رابط المدونة لأولئك الذين يقومون بالتمرير إلى الأسفل
https://aws.amazon.com/blogs/compute/announcing-aws-lambda-supports-for-net-core-3-1/

رائع ، شكرًا مليونًا لإضافة الدعم إلى dotnet core 3.1 !!!

andyKalman ليس بعد على PowerShell 7. أقوم ببعض اللمسات الأخيرة على وحدة AWSLambdaPSCore ثم سأحصل على الإصدار 2.0.0 من AWSLambdaPSCore في المعرض.

إنني أقدر الرد السريع normj . لقد رأيت رقم 607 بعد الحقيقة ، ومن الجيد جدًا أن أرى أنه متابعة سريعة. هل هناك مشكلة أخرى يجب تتبعها حتى أتمكن من إيقاف التعليقات هنا؟ :) شكرا لك مرة أخرى.

تهاني!
وشكرًا لكل من AWS و .NET Team!
مقدر جدا.

شكرا لكل من ساعد في تحقيق ذلك! هذا إصدار ضخم ويظهر الكثير من العمل الشاق الذي تم بذله! لطيف - جيد! 🎉🥳

شكرا !! : clap :: clap :: tada :: tada:

تهانينا يا رفاق ، أتطلع إلى الترقية.

شكرا!

عمل رائع ، حريص على ترقية هذه اللامدا.

عمل عظيم! شكرا لكم normj 👏 👏

فريق عمل رائع!

حريصة على القفز على عمال Lambda باستخدام dotnet 3.1 Async Streams + اشتراكات AWS AppSync / GraphQL.
فريق AWS ، شكرًا جزيلاً!

يا رفاق ، أنتم القواعد! مدهش! رائع! 😄😄😄

شكرا!

andyKalman لقد دفعت الإصدار 2.0.0 من وحدة AWSLambdaPSCore التي تستخدم الآن PowerShell 7. أخطط لنشر منشور مدونة على دعم PS7 ولكنه يعمل بنفس طريقة دعم PowerShell 6 الحالي الذي يستخدم 7 فقط.

andyKalman لقد دفعت الإصدار 2.0.0 من وحدة AWSLambdaPSCore التي تستخدم الآن PowerShell 7. أخطط لنشر منشور مدونة على دعم PS7 ولكنه يعمل بنفس طريقة دعم PowerShell 6 الحالي الذي يستخدم 7 فقط.

هل يقوم الإصدار الجديد من AWSLambdaPSCore بتحديث أي من التكوينات ضمن وظائف Lambda الحالية الخاصة بي إذا قمت بنشرها مع الإصدار الجديد؟ مثل هل سيوجهها نحو dotnet3.1 و ps7؟

@ tr33squid نعم إذا قمت فسيستخدم .NET Core 3.1 و PS7

شكرًا جزيلاً لفريق AWS على العمل الرائع !!

مرحبا جميعا،

أنا أعمل بنشاط على جلب الدعم لـ .NET Core 3.1 في Lambda. يستغرق الأمر بعض الوقت لأن Microsoft قامت بالكثير من العمل في كيفية إنشاء وقت التشغيل. أنا أعمل على دمج هذه التغييرات لتوفير وقت تشغيل أصلي لك.

بفضل فريق AWS-Lambda .NET الأساسي

أهلا،
أتلقى هذا الخطأ عند محاولة تنفيذ AWS-Lambda
لم يكن من الممكن العثور على أي إصدار إطار عمل متوافق.
لم يتم العثور على إطار العمل المحدد "Microsoft.AspNetCore.App" ، الإصدار "3.1.0".
أي اقتراحات ؟؟

أهلا،
أتلقى هذا الخطأ عند محاولة تنفيذ AWS-Lambda
لم يكن من الممكن العثور على أي إصدار إطار عمل متوافق.
لم يتم العثور على إطار العمل المحدد "Microsoft.AspNetCore.App" ، الإصدار "3.1.0".
أي اقتراحات ؟؟

تحتاج إلى تثبيت 3.1.0 SDK.

أعتقد أنه يجب إزالة Microsoft.AspNetCore.App من مشروعك
التبعيات ، التي لم تعد ضرورية لـ Core 3.1.0 ، كان علي إزالتها إلى
بناء ونشر الخدمة التي قمت بالترقية من 2.1.

يوم الجمعة 24 أبريل 2020 الساعة 3:24 صباحًا Gregory Lyons [email protected]
كتب:

أهلا،
أتلقى هذا الخطأ عند محاولة تنفيذ AWS-Lambda
لم يكن من الممكن العثور على أي إصدار إطار عمل متوافق.
إطار العمل المحدد 'Microsoft.AspNetCore.App' ، الإصدار '3.1.0' كان
غير موجود.
أي اقتراحات ؟؟

تحتاج إلى تثبيت 3.1.0 SDK.

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على 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 شارع فاندربيلت
الطابق 3

أعتقد أنه يجب إزالة Microsoft.AspNetCore.App من تبعيات مشروعك ، ولم تعد هناك حاجة لـ Core 3.1.0 ، فقد اضطررت إلى إزالته لإنشاء ونشر الخدمة التي قمت بالترقية من 2.1.
...
يوم الجمعة 24 أبريل 2020 الساعة 3:24 صباحًا Gregory Lyons @ . * > كتب: مرحبًا ، لقد تلقيت هذا الخطأ عند محاولة تنفيذ AWS-Lambda. لم يكن من الممكن العثور على أي إصدار إطار عمل متوافق. لم يتم العثور على إطار العمل المحدد "Microsoft.AspNetCore.App" ، الإصدار "3.1.0". أي اقتراحات ؟؟ تحتاج إلى تثبيت 3.1.0 SDK. - أنت تتلقى هذا لأنك مشترك في هذا الموضوع. قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو اعرضها على GitHub < # 554 (تعليق) > ، أو قم بإلغاء الاشتراك https://github.com/notifications/unsubscribe-auth/AMSHCOLW5WJDS7CCAFDMP4TROE5ENANCNFSM4JU5UTJA .
- بست ، جورج جورج تاسكوس مهندس حلول أول في WeAre8 230 بارك أفينيو ، الطابق الثالث. West New York، NY 10169 (917) 717-9067 weare8.com مدخل خاص ، 71 شارع فاندربيلت الطابق الثالث

شكرا لردك،
في الواقع كان هذا الخطأ بسبب خطأي السخيف. لقد نسيت إزالة وقت التشغيل: dotnetcore2.1 في serverless.yml. الآن حل المشكلة.

هل يقوم أي شخص بأي معيار معياري / مقارنات محدثة حول هذا؟ كل ما يمكنني العثور عليه هو القديم مع وقت تشغيل مخصص ..

هل يقوم أي شخص بأي معيار معياري / مقارنات محدثة حول هذا؟ كل ما يمكنني العثور عليه هو القديم مع وقت تشغيل مخصص ..

هنا فكرة جيدة
https://medium.com/@zaccharles/a -close-look-at-net-core-3-1-on-aws-lambda-9ccec4dd96be

كما أن تجربتي الشخصية في تحديث 2.1 lambda معقد إلى 3.1 على حجم lambda 512 ميجابايت شهدت نفس الأداء تقريبًا (بداية باردة ودافئة). يستخدم كل من الإصدارين 2.1 و 3.1 lambda طبقة lambda ، والنشر المحسّن ، و newtonsoft (قد يشهد تحسنًا مثاليًا مع Microsoft json في الإصدار 3.1) ، وإيقاف التجميع المتدرج ، و RTR لـ 3.1.

من قياساتي ، يبدو أنه يكتسب أداءً طفيفًا مع وقت تشغيل dotnet 3.1 ، لكنه يفقد الأداء على تهيئة Amazon Linux 2 و dotnet 3.1. (الإصدار 2.1 يستخدم Amazon Linux 1).