Aws-lambda-dotnet: .NET Core 3.1 (LTS) telah dirilis

Ini adalah LTS dan akan didukung. Hanya perlu beberapa saat untuk menyiapkan .NET Core 3.1 untuk Lambda dan digunakan.

Ini adalah LTS dan akan didukung. Hanya perlu beberapa saat untuk menyiapkan .NET Core 3.1 untuk Lambda dan digunakan.

Jika ada yang bisa saya lakukan untuk membantu, beri tahu saya.

Apakah akan ada percepatan untuk waktu mulai dingin?

.NET Core 3.1 memiliki beberapa fitur seperti kompilasi AOT

• TerbitkanSiapDijalankan
• PublikasikanDipangkas

@normj haruskah orang berlangganan masalah ini untuk pembaruan atau apakah ada masalah .NET Core 3.1 lain yang harus kita ikuti untuk kemajuan?

Kami dapat menggunakan masalah ini untuk melacak pembaruan. Sayangnya saya mungkin tidak akan dapat memberikan banyak pembaruan status sampai keluar.

Apakah akan ada percepatan untuk waktu mulai dingin?

.NET Core 3.1 memiliki beberapa fitur seperti kompilasi AOT

• TerbitkanSiapDijalankan
• PublikasikanDipangkas

Jika jawabannya ya untuk komentar, apakah mungkin menjalankan dan menguji 'lamba yang dikompilasi' dari lingkungan lokal? Saya dengan bersemangat akan mengatur lingkungan linux untuk itu :)

Ada pembaruan di sini?

@rati-dzidziguri

Seperti di atas dari @normj

Kami dapat menggunakan masalah ini untuk melacak pembaruan. Sayangnya saya mungkin tidak akan dapat memberikan banyak pembaruan status sampai keluar.

@beeradmoore
Pertanyaan saya adalah tentang ETA. Itu akan sangat membantu untuk mengetahui ETA untuk ini karena kami dapat mempersiapkannya dengan tepat.

@rati-dzidziguri Amazon jarang mengungkapkan ETA mereka dalam hal rilis.

@rati-dzidziguri Saya mengerti dan menghargai Anda menginginkan ETA sehingga Anda dapat merencanakannya. Kenyataannya karena alasan itulah kami umumnya tidak memberikan ETA karena kami berusaha sangat keras untuk tidak membuat janji yang tidak 100% kami yakini dapat kami tepati. Saya tidak ingin memberi Anda ETA dan Anda membuat peta jalan Anda berdasarkan itu dan kami kemudian kehilangan ETA yang Anda harapkan membuat semua rencana Anda berantakan.

Untuk saat ini jika Anda benar-benar membutuhkan fitur .NET Core 3.1 maka saya sarankan menggunakan .NET Core 3.1 sebagai Lambda Custom Runtime yang dijelaskan di sini (kecuali referensi perubahan dari .NET Core 3.0 ke .NET Core 3.1). Kemudian ketika dukungan .NET Core 3.1 asli datang, Anda akan memiliki migrasi yang sangat sederhana untuk mengubah beberapa pengaturan pada fungsi Lambda Anda.

@normj Salah satu alasan membuat saya memutuskan bahwa saya tidak dapat menggunakan fitur runtime khusus dengan kelas 'LambdaEntry' adalah aspek 'arsitektur monolitik' dari pendekatan implementasi. Setiap permintaan API datang melalui satu-satunya entri lambda dan 'didistribusikan' ke pengontrol proyek ASP .net adalah apa yang dimaksudkan oleh struktur runtime kustom, yang pasti nyaman tetapi mencakup kerugian struktural untuk kasus-kasus seperti yang saya inginkan. Saya ingin setiap permintaan perintah/permintaan menjadi lambda masing-masing. Sejak itu saya bisa mendapatkan skalabilitas dalam mengelola paket penerapan sehingga saya dapat membagi beberapa fungsi dan mengelola kode kapan pun saya mau.
Inilah sebabnya mengapa saya menunggu runtime resmi didukung sehingga saya dapat membuat bundel 'lamba tujuan tunggal' menggunakan SAM yang ditulis dalam template dengan konfigurasi 'runtime: .netcore 3.1'.

Tolong beri saya saran jika saya salah :)

Anda pasti dapat mencapai beberapa fungsi lambda dari satu basis kode menggunakan Lambda Bootstrapper dan fitur runtime kustom.

Saya memiliki rangkaian 16 lambda yang digunakan dari satu aplikasi, bukan "monolit".

Ini dicapai dengan menggunakan variabel lingkungan _handler untuk memilih metode yang akan digunakan pada saat runtime, daripada pemetaan satu-ke-satu yang dikodekan secara keras yang ditunjukkan dalam kode sampel entri blog.

Saya menganggapnya sebagai aplikasi konsol yang menerima sakelar yang memberi tahu tindakan apa yang harus "menjadi" ketika dimulai.

@martincostello
Terima kasih atas saran yang baik! Saya bisa mencari tahu seperti apa kasus Anda. Anda mungkin telah menempatkan logika sakelar di kelas Utama atau Startup yang dapat ditentukan fungsinya pada tahap pertama runtime. Dan itu bisa memecahkan masalah 'hanya-monolitik', tentu saja. Pendekatan yang sangat cerdas :)

Tapi tetap saja, ada satu (jika tidak banyak) pertimbangan yang harus saya pikirkan, terutama ketika saya membayangkan bekerja sebagai sebuah tim. Menggunakan runtime khusus dan menentukan 'identitas fungsional' saat startup akan menghilangkan kemungkinan SAM. Sebagai contoh mudah bagi kami, gateway API tidak dapat ditentukan saat menerapkan lambda, yang berarti kami harus membuatnya secara manual.
Saya tahu saya melebih-lebihkan di sini karena kita dapat membuat sesuatu seperti konfigurasi SAM menggunakan skrip bootstrap seperti yang dijelaskan oleh tutorial aws . Tapi itu tidak akan sepenuhnya memuaskan kami karena menggunakan skrip linux yang berarti
(1) itu bisa memalukan bagi pendatang baru, dan kadang-kadang akan menjadi kurva belajar.
(2) itu akan membuang manfaat dari ekspresifitas template tanpa server karena secara harfiah merupakan skrip, bukan dokumen.

Saya pikir templat tanpa server berfungsi sebagai semi-dokumen tentang seperti apa tampilan server dan cara kerjanya, yang tidak hanya akan dibagikan dalam tim pengembangan tetapi bahkan dengan beberapa non-teknisi yang berwawasan luas. dan SAM adalah konsep yang terdefinisi dengan baik bahwa dalam waktu dekat representasi abstrak seseorang dari sebuah aplikasi akan memungkinkan untuk digunakan kembali oleh tim lain menggunakan bahasa dan platform yang sama sekali berbeda. Aspek-aspek ini tidak dapat disangkal memotivasi saya untuk tetap menggunakan fitur 'template tanpa server'.

Beberapa tanggal yang bagus di depan untuk merilis ini, 25 Desember, 1 Januari muncul di pikiran;)

Selamat berlibur semuanya, saya harap saya bisa memberi Anda semua runtime .NET Core 3.1 Lambda untuk Natal, tetapi saya pikir 2020 akan menjadi tahun yang menyenangkan untuk .NET dan AWS Anda.

Selamat berlibur semuanya, saya harap saya bisa memberi Anda semua runtime .NET Core 3.1 Lambda untuk Natal, tetapi saya pikir 2020 akan menjadi tahun yang menyenangkan untuk .NET dan AWS Anda.

Jangan khawatir, nikmati liburannya! Tidak sabar untuk melihat apa yang Anda miliki untuk kami di tahun 2020! :)

menunggu dukungan asli lambda di .NetCore3.1

Ada batas ukuran disk untuk fungsi lambda. Saya pikir itu 250 MB dan saat menggunakan runtime khusus, kami harus mengirim semua asp.net core asp.net bersama dengan aplikasi kami. Saya mencapai batas itu ketika AWS membuka ritsleting paket zip saya. Saya harus melakukan pembersihan untuk mengurangi ruang yang digunakan oleh aplikasi saya. Saat dukungan asli keluar, kami tidak perlu mengemas aplikasi kami dengan rakitan .core.

Apakah ada perkiraan kapan kita bisa mengharapkan ini akan dirilis?

Kami sedang menunggu untuk meningkatkan ke .Net core 3.1 sampai ada dukungan asli untuk itu.

Apakah ada perkiraan kapan kita bisa mengharapkan ini akan dirilis?

Kami sedang menunggu untuk meningkatkan ke .Net core 3.1 sampai ada dukungan asli untuk itu.

Jika Anda kembali dan membaca balasan, Anda akan membaca dari normj bahwa mereka tidak akan memberikan perkiraan apa pun.

Jika Anda kembali dan membaca balasan, Anda akan membaca dari normj bahwa mereka tidak akan memberikan perkiraan apa pun.

Mmmm biasanya -- ya. Tetapi jika cukup banyak orang yang muncul dengan garpu rumput maka mungkin sedikit tanggal rilis akan diberikan untuk memadamkan kerusuhan :grin:

Saya ingat beberapa waktu lalu ketika AWS menghabiskan waktu lama untuk menyiapkan gambar asli 2.1. Mereka mengatakan sesuatu yang menyatakan bahwa mereka mendesain ulang proses untuk membuat penggelaran versi masa depan lebih mudah dan lebih cepat untuk stand-up. Masuk NetCore 3.1 dan hampir dua bulan kemudian dan masih belum tersedia :(

Anda tahu Azure memiliki gambar 3.1 ini yang tersedia Hari 1. Saya mulai melihat mengapa Pemerintah AS memilih Azure sebagai penyedia cloud mereka untuk JEDI.

Kami baru saja mendapat lampu hijau dari pemangku kepentingan kami untuk mulai menargetkan Azure sebagai penyedia utama kami meninggalkan AWS sebagai cadangan. Dengan penundaan konyol seperti ini, saya yakin kita bukan satu-satunya.

Saya ingat beberapa waktu lalu ketika AWS menghabiskan waktu lama untuk menyiapkan gambar asli 2.1. Mereka mengatakan sesuatu yang menyatakan bahwa mereka mendesain ulang proses untuk membuat penggelaran versi masa depan lebih mudah dan lebih cepat untuk stand-up. Masuk NetCore 3.1 dan hampir dua bulan kemudian dan masih belum tersedia :(

Anda tahu Azure memiliki gambar 3.1 ini yang tersedia Hari 1. Saya mulai melihat mengapa Pemerintah AS memilih Azure sebagai penyedia cloud mereka untuk JEDI.

Kami baru saja mendapat lampu hijau dari pemangku kepentingan kami untuk mulai menargetkan Azure sebagai penyedia utama kami meninggalkan AWS sebagai cadangan. Dengan penundaan konyol seperti ini, saya yakin kita bukan satu-satunya.

Saya setuju denganmu. Organisasi saya tidak mengizinkan runtime khusus dan kami agak terjebak dengan 2.1. Ketika datang ke EF & Postgres bersama dengan operasi spasial, itu terlalu menyakitkan. Kami telah menunggu ini dilakukan. Sayang sekali belum selesai.

Saya ingat beberapa waktu lalu ketika AWS menghabiskan waktu lama untuk menyiapkan gambar asli 2.1. Mereka mengatakan sesuatu yang menyatakan bahwa mereka mendesain ulang proses untuk membuat penggelaran versi masa depan lebih mudah dan lebih cepat untuk stand-up. Masuk NetCore 3.1 dan hampir dua bulan kemudian dan masih belum tersedia :(

Anda tahu Azure memiliki gambar 3.1 ini yang tersedia Hari 1. Saya mulai melihat mengapa Pemerintah AS memilih Azure sebagai penyedia cloud mereka untuk JEDI.

Kami baru saja mendapat lampu hijau dari pemangku kepentingan kami untuk mulai menargetkan Azure sebagai penyedia utama kami meninggalkan AWS sebagai cadangan. Dengan penundaan konyol seperti ini, saya yakin kita bukan satu-satunya.

Apakah JEDI menggunakan .NET Core untuk membuat asumsi itu sebabnya pemerintah menggunakan Azure?

Halo semuanya,

Saya secara aktif berupaya menghadirkan dukungan untuk .NET Core 3.1 di Lambda. Dibutuhkan beberapa waktu karena banyak pekerjaan yang dilakukan oleh Microsoft dalam cara mereka membangun runtime. Saya sedang berupaya menggabungkan perubahan ini untuk memberi Anda runtime asli.

@assyadh Terima kasih! Saya tidak percaya penundaan itu "konyol"; sebenarnya, saya lebih suka menunggu versi kerja yang solid. Saya suka AWS Lambda mendukung .NET Core dan saya menghargai Anda terus mendukungnya, seperti yang dijanjikan.

Saya tidak mengerti dorongannya. Bukannya kami tidak memiliki lingkungan LTS saat ini.

Jelas kami ingin menggunakan mainan baru tetapi tim .NET di AWS hanya memiliki jumlah sumber daya yang tetap dan mereka tidak dapat melakukan semuanya sekaligus.

Selain itu, saya tidak merindukan kebutuhan untuk terburu-buru dan memperbarui runtime semua fungsi karena takut keluar dari persyaratan servis.

Bagus untuk Anda @Kralizek tetapi situasi Anda adalah milik Anda dan tidak mewakili orang lain. Ini bukan benar-benar "mainan baru" sekarang. .NET Core 3.x (dan ASP.NET Core) memiliki peningkatan yang signifikan dibandingkan 2.x dalam berbagai cara dan pengadopsi awal tertarik untuk mengadopsi dan memanfaatkannya. Seperti yang dikatakan @JamesQMurphy , kami juga lebih suka rilisnya solid.

Saya menantikan karya Anda @assyadh.

"Aku tidak mengerti dorongannya."

Kami tidak dapat menggunakan .NET Core 3.1 yang dibagikan dalam fungsi lambda .NET Core 2.1, pada kenyataannya kami bahkan tidak dapat menggunakan kode .NET Core 2.2 yang dibagikan dalam fungsi lambda .NET Core 2.1, jadi kami baru-baru ini harus dengan enggan menurunkan versi kami berbagi komponen ke .NET Core 2.1 agar mereka didukung dalam fungsi.

Bisakah komponen bersama Anda dikompilasi di netstandard20? Kemudian Anda dapat membagikannya di netcore2&3

Sementara utas ini khusus untuk .NET 3.1, saya yakin percakapan yang tepat ini akan dimainkan lagi ketika .NET 5 tiba (atau 6 jika itu akan menjadi LTS berikutnya).

Sementara beberapa contoh spesifik telah dikutip di tempat yang tidak memungkinkan (misalnya file kode ZIP terlalu besar, kebijakan perusahaan), _secara umum_ jika Anda ingin menggunakan .NET Core "terbaru dan terbaik", Anda dapat melakukannya dengan sedikit refactoring dan paket dukungan runtime kustom.

Saat ini kami kebetulan berada pada titik di mana rilis terbaru _juga terjadi_ menjadi rilis LTS, yang tampaknya membuat kebutuhan untuk memilikinya "ASAP" dari Amazon tampak jauh lebih "mendesak" daripada sebelumnya, katakanlah, memiliki dukungan 2.2 atau 3.0 bawaan.

Pada akhirnya ada trade-off yang harus dibuat antara fitur baru yang dapat digunakan di Lambda vs upaya pengembangan yang perlu dilakukan dengan solusi PaaS.

.NET Core 3.1 bahkan tidak tersedia di Layanan Aplikasi Azure Microsoft selama 2-3 minggu setelah dirilis.

Jika Anda biasanya ingin berada di "pendarahan tepi" ASAP, mengambil investasi kecil dalam menggunakan dukungan runtime kustom dalam jangka pendek akan membuka kunci Anda untuk berpotensi menjalankan versi masa depan .NET Core di Lambda pada rentang waktu Anda sendiri. Tentu saja trade off di sini antara lain adalah paket yang lebih besar, sedikit lebih banyak kode, dan kebutuhan untuk melakukan patching Anda sendiri.

Dengan segalanya, ada keseimbangan dan trade-off, dan untuk dukungan bawaan, secara realistis akan selalu ada lag untuk ketersediaan karena perangkat lunak membutuhkan waktu.

Dengan rilis utama .NET pada bulan November ke depan, periode Natal/Liburan mungkin akan selalu berpengaruh pada berapa lama waktu yang dibutuhkan tim Lambda untuk membuat hal-hal ini tersedia dan kapasitas yang tersedia.

Hanya menambahkan pemikiran saya. Saya mengerti bagaimana rilis ini sangat penting dan saya menghargai Anda memberi tahu kami. Saya menggunakan umpan balik itu untuk mendorong urgensi di pihak kita. Seperti yang disebutkan @martincostello , waktu

Saya adalah orang yang disebutkan di masa lalu untuk 2.1 bahwa saya melompat otomatisasi yang kami lakukan akan mempercepat rilis di masa mendatang. Otomatisasi yang dilakukan oleh @assyadh benar-benar membantu kami, tetapi sayangnya seiring berjalannya waktu, banyak hal telah berubah sejak kami melakukan .NET Core 2.1. Bagian darinya adalah bagaimana MS membangun .NET Core dan bagian lainnya adalah bagaimana layanan Lambda bekerja dengan perpindahan ke Amazon Linux 2.

Jadi tolong percayalah bahwa .NET Core 3.1 adalah @assyadh , saya dan banyak orang lain menjadi prioritas tertinggi untuk diselesaikan.

Hanya untuk memeriksa, apakah pekerjaan untuk memasukkannya dimulai setelah Microsoft merilis pra-rilis daripada menunggu rilis final? Itu mungkin akan mengurangi dampak Natal dan memungkinkannya dikirimkan lebih cepat setelah rilis final keluar karena hanya perlu pengujian.

Saya menggunakan umpan balik itu untuk mendorong urgensi di pihak kami

Terima kasih untuk @normj ini. Ini $0,02 saya, dengan harapan itu juga membantu penginjilan Anda.

Seperti yang disebutkan @martincostello , waktu

Seperti yang disinggung oleh @mungojam , .NET Core 3.1 tersedia dalam bentuk pratinjau mulai 15 Oktober, lebih dari sebulan sebelum rilis. Juga, ini pada dasarnya adalah rilis perbaikan bug 3.0 - Saya tidak tahu alat Anda, tetapi saya akan membayangkan pekerjaan eksplorasi bisa mulai menggunakan 3.0, yang dirilis 23 September dan dalam pratinjau sepanjang tahun . Perlu dicatat bahwa 3.1 diberi perkiraan tanggal rilis dalam pengumuman rilis 3.0.

.NET Core 3.1 bahkan tidak tersedia di Layanan Aplikasi Azure Microsoft selama 2-3 minggu setelah dirilis.

.NET Core 3.1 tersedia di Azure Functions 17 Oktober , dua hari setelah Pratinjau 1 dirilis.

Anda dapat mengatakan apa yang Anda inginkan tentang kebutuhan perusahaan mana pun untuk memiliki 3.1 segera, apakah itu "bleeding edge", opsi runtime kustom, dan sebagainya, tetapi ini benar-benar bagian dari gambaran yang lebih besar tentang seberapa serius AWS ingin mendukung kami .NET pelanggan. Jika AWS - bukan tim Norm, tetapi AWS secara keseluruhan - telah menjadikannya prioritas, saya harus berpikir mereka bisa berada di depan ini, memastikan mereka bersaing dengan Azure.

Secara pribadi, saya sangat menghargai memiliki opsi di antara penawaran cloud yang dapat saya pilih berdasarkan prestasi daripada dogma perusahaan, dan saya ingin melihat AWS mengambil langkah berikutnya dalam meningkatkan dukungan .NET.

Terima kasih @normj , @assyadh , dan orang lain yang mengerjakan ini atas upaya Anda.

Mungkin saja tim .NET di AWS memulai perjalanan persiapan mereka dengan sangat baik untuk .NET 3.1 LTS setelah merilis pratinjau 3.0. Masalahnya, AWS cenderung bungkam tentang apa yang mereka kerjakan di balik tirai. Kurangnya transparansi ini melahirkan dugaan. Saya pikir tidak ada salahnya untuk memiliki semacam peta jalan, bahkan jika itu tentatif dan tanggal dapat berubah, dll.

Saya pikir masalahnya adalah bahwa tim AWS tidak ingin mengeluarkan ETA jenis apa pun dan oleh karena itu pengembang tidak mengetahuinya. @normj mengatakan itu karena dia tidak ingin siapa pun atau perusahaan mana pun membuat rencana masa depan berdasarkan ETA tersebut. Bukankah pemahaman umum bahwa ETA hanyalah perkiraan dan tidak ada perusahaan yang harus membuat rencana serius berdasarkan perkiraan perusahaan lain dan bahkan jika mereka melakukannya, perusahaan tidak dapat menyalahkan AWS atau marah karena melewatkan ETA?

ETA juga bukan hari tertentu. Bisa sebulan. Seperempat. Dan kita harus baik-baik saja dengan ETA apa pun dan OK jika terlewatkan.

Melihat ke
https://docs.aws.amazon.com/lambda/latest/dg/runtime-support-policy.html
tampaknya AWS menghentikan runtime segera setelah akhir masa pakai versi runtime tersebut.

Karena versi .NET Core LTS didukung selama 3 tahun, kami sudah
"menghabiskan waktu kita bisa menggunakan .NET Core 3.1 lambdas".
Oleh karena itu, saya mengerti orang-orang yang rawat inap untuk mendapatkan .NET core 3.1 pada lambdas.
BTW, saya juga lebih suka rilis rock solid daripada sesuatu yang terburu-buru.

Saya berasumsi itu akan tersedia dalam satu atau dua bulan ke depan, tetapi beberapa komitmen dari AWS,
bahkan jika sangat konservatif dapat bermanfaat bagi tim untuk merencanakan operasi mereka.

Hal lain adalah pada OSS kali ini: dapatkah komunitas .NET membantu? Bagaimanapun, kita berbicara di github.
Apakah runtime "bawaan" ini merupakan kode tertutup?

Juga, itu akan menjadi fitur PEMBUNUH jika proses penyebaran memiliki sakelar untuk melakukan ReadyToRun dan fitur kompilasi AOT lainnya sehingga waktu mulai dingin turun dengan serius.
Itu akan membuat .NET Core SANGAT menarik di AWS Lambda, IMO.

@normj dan tim:
terima kasih telah membuat .NET core hebat di AWS

Hanya menambahkan pemikiran saya. Saya mengerti bagaimana rilis ini sangat penting dan saya menghargai Anda memberi tahu kami. Saya menggunakan umpan balik itu untuk mendorong urgensi di pihak kita.

Silakan gunakan posting ini untuk mendorong urgensi di pihak Anda. Dengan mengingat hal itu, inilah dua sen saya.

Hanya untuk memeriksa, apakah pekerjaan untuk memasukkannya dimulai setelah Microsoft merilis pra-rilis daripada menunggu rilis final?

Pertanyaan: Akankah kita mendapatkan jawaban yang jujur ​​untuk pertanyaan ini?

Rasanya seperti jawabannya sudah jelas. Sepertinya prioritas untuk .NET adalah "tingkat hobi" dan bukan "tingkat perusahaan" sebagaimana mestinya.

Saya pernah mendengar di suatu tempat bahwa 1) seluruh hal Net Core telah dibuat open-source, dan 2) ada beberapa program pengadopsi awal yang memungkinkan Anda untuk "beroperasi" pada rilis yang sebenarnya. (lihat Google untuk detailnya.)

Saya bercanda di sini, tetapi kenyataannya, semua orang yang mengikuti .NET mengetahui hal ini, jadi ini menambah bukti diri saya saat berbicara.

Sejujurnya, Setelah penundaan rilis 2.1, saya berharap bahwa perubahan yang dibuat saat itu berarti bahwa kali ini (3.1) kami akan memiliki dukungan untuk kerangka kerja baru tidak lebih dari dua minggu dari rilis sebenarnya. Maksud saya dalam beberapa jam setelah rilis akan ideal, tetapi memberikan ruang untuk sentuhan akhir/poles, dalam waktu dua minggu terasa benar.

Tapi di sini kita hampir dua bulan keluar dan itu hanya terasa "tingkat-hobi".

@rati-dzidziguri Saya mengerti dan menghargai Anda menginginkan ETA sehingga Anda dapat merencanakannya. Kenyataannya karena alasan itulah kami umumnya tidak memberikan ETA karena kami berusaha sangat keras untuk tidak membuat janji yang tidak 100% kami yakini dapat kami tepati.

Ini adalah pemikiran "tingkat hobi", seperti yang dinyatakan dengan elegan oleh

Saya pikir masalahnya adalah bahwa tim AWS tidak ingin mengeluarkan ETA jenis apa pun dan oleh karena itu pengembang tidak mengetahuinya. @normj mengatakan itu karena dia tidak ingin siapa pun atau perusahaan mana pun membuat rencana masa depan berdasarkan ETA tersebut. Bukankah pemahaman umum bahwa ETA hanyalah perkiraan dan tidak ada perusahaan yang harus membuat rencana serius berdasarkan perkiraan perusahaan lain dan bahkan jika mereka melakukannya, perusahaan tidak dapat menyalahkan AWS atau marah karena melewatkan ETA?

ETA juga bukan hari tertentu. Bisa sebulan. Seperempat. Dan kita harus baik-baik saja dengan ETA apa pun dan OK jika terlewatkan.

Saya pikir fakta AWS kehilangan kontrak JEDI ke Azure, seharusnya sudah cukup untuk memulai beberapa pertemuan prioritas secara internal karena, di wajahnya, itu membuktikan bahwa .NET adalah upaya "tingkat perusahaan" dan harus diperlakukan seperti itu. Alih-alih membuang-buang sumber daya untuk mencoba "menuntut" keputusan tersebut, gunakan sumber daya tersebut secara internal untuk memberi komunitas .NET cinta. Gunakan ini sebagai momen untuk kembali memprioritaskan .NET sehingga rilis .NET berikutnya, AWS berada di atasnya, dan membuktikan dengan sendirinya bahwa mereka siap untuk memulai.

@normj , @martincostello , dan lebah pekerja lainnya di sana di AWS, bekerja sangat keras untuk memberikan penawaran SOLID .NET, harap dipahami bahwa keluhan (komunitas) ini bukan hanya Anda, tetapi lebih pada budaya/politik yang menentukan mandat prioritas yang telah diberikan kepada Anda sehubungan dengan .NET. Silakan gunakan pos ini untuk membantu mencapai dukungan "tingkat perusahaan".

Saya terutama melihat ini sebagai peluang yang terlewatkan bagi AWS untuk bersinar. Bayangkan jika mengikuti rilis LTS baru akan menjadi prioritas tinggi. Betapa kuatnya pernyataan itu.

Hal-hal seperti ini membuat kami para developer/arsitek kehilangan argumen terhadap pengambil keputusan non-teknis ketika kami harus memutuskan cloud mana yang akan digunakan untuk proyek berikutnya. Saat ini ketika Azure dan AWS sebagian besar memiliki penawaran biaya dan fitur yang sama, keputusan lebih banyak dibuat pada politik dan persepsi. Saya tidak membawa apa-apa ketika mereka mengatakan "sudah X minggu/bulan setelah rilis resmi dan AWS masih belum siap"

Sekali lagi, seperti yang dikatakan @VagyokC4 , ini bukan masalah pribadi terhadap karyawan yang melakukan pekerjaan sebenarnya, tetapi lebih merupakan panggilan bangun untuk manajemen AWS atas.

Semua orang yang melakukan .NET Core 3.1 Lambda mungkin mempertimbangkan untuk mengaktifkan IL Trimming. Kemungkinan besar Anda akan mengurangi ukuran file zip Anda.
https://www.hanselman.com/blog/MakingATinyNETCore30EntirelySelfcontainedSingleExecutable.aspx

apakah .NET core lambda 3.1 dibangun menggunakan RuntimeAPI?
di tempat terbuka, di github?
jika tidak, mengapa tidak?

Yang saya inginkan untuk.... Hari kasih sayang adalah lambda .net core 3.1 support

Yang saya inginkan untuk.... Hari kasih sayang adalah lambda .net core 3.1 support

Tidak benar-benar menggulung lidah, tapi itu rendah hati:

Saya tidak ingin banyak untuk Hari Valentine
Hanya ada satu hal yang saya butuhkan
Saya tidak peduli dengan hadiahnya
Di bawah pohon AWS
Aku hanya menginginkannya untuk diriku sendiri
Lebih dari yang pernah Anda ketahui
Jadikan keinginanku menjadi kenyataan oh
Yang saya inginkan untuk Hari Valentine adalah .NET Core 3.1 suppooooort ...

:menyeringai:

Microsoft menyertakan lisensi Go Live menjelang akhir siklus pratinjau mereka ketika mereka tidak akan memperkenalkan perubahan yang melanggar. Pada saat itu mereka menawarkan dukungan produksi untuk rilis yang akan datang. Rekomendasi saya adalah menunggu sampai mereka membuat rilis dengan lisensi Go Live dan kemudian mulai mengerjakan alatnya. Dengan .NET Core 3.1 itu datang di Pratinjau 3 yang dirilis pada 11/14. Dalam hal ini RTM bahkan tidak 3 minggu kemudian pada 12/3 tetapi Anda masih akan lebih dekat untuk meluncurkan fitur ketika RTM muncul dan pelanggan mulai membangun harapan.

Hanya $0,02 saya

Yang saya inginkan untuk.... Hari kasih sayang adalah lambda .net core 3.1 support

Tidak benar-benar menggulung lidah, tapi itu rendah hati:

Saya tidak ingin banyak untuk ~Natal~ Hari Valentine
Hanya ada satu hal yang saya butuhkan
Saya tidak peduli dengan hadiahnya
Di bawah pohon AWS
Aku hanya menginginkannya untuk diriku sendiri
Lebih dari yang pernah Anda ketahui
Jadikan keinginanku menjadi kenyataan oh
Yang saya inginkan untuk Hari Valentine adalah .NET Core 3.1 suppooooort ...

😁

+1 :)

adakah pembaruan pada runtime .NET Core 3.1 untuk Lambda?

Kami memulai proyek baru dan sangat condong menggunakan Lamba untuk sebagian besar tanpa server, tetapi melihat berapa lama waktu yang dibutuhkan untuk mendapatkan versi LTS yang didukung membuat kami berpikir ulang, mungkin mengubah arsitektur atau penyedia.

<Rant>
Ini membuat frustrasi karena kebijakan dukungan AWS Lambda Runtime sangat ketat tentang jendela 30 hari, ketika fitur seperti ini diminta lebih dari 30 hari. Kemudian secara ajaib suatu hari AWS akan menerapkan fitur ini dan semua orang harus berebut untuk beralih ke .NET Core 3.1. Ini menempatkan PALING organisasi di tempat yang buruk karena sering kali dibutuhkan lebih dari satu bulan untuk memperbaiki, menguji, dan menyebarkan sesuatu ke lingkungan produksi. Saya pribadi telah digigit oleh kebijakan ini. Suatu kali (karena kendala sumber daya dan prioritas lain yang lebih tinggi) sebuah perusahaan tempat saya gagal saat ini. Tidak sampai 3 bulan kemudian kami dapat mengupgrade Lambdas kami ke .NET Core 2.1. Setelah kami mencoba men-deploy lambda tertentu dengan CloudFront, sesuatu yang buruk (apa? siapa yang tahu karena CF log adalah sampah) terjadi dan perlu dilakukan rollback. Kecuali tidak ada runtime untuk melakukan rollback. Jadi itu LOCKED penyebarannya. Kami segera membuka tiket. 24 jam kemudian kami mendapat respons pertama kami yaitu "hapus seluruh tumpukan dan mulai dari awal". Yang merupakan respons yang benar-benar bodoh mengingat itu akan mengambil tabel DynamoDb kami dengan operasi "hapus". Kami terkunci dalam kemunduran itu selama lebih dari 2 setengah minggu. Akhirnya, kami mendapatkan teknisi pendukung yang memahami teknologi container dan membantu kami melakukan rollback, lalu tetap terhubung hingga CloudFormation kami berhasil. Yang itu baik-baik saja, tidak ada perubahan pada upaya pertama. Itulah mengapa saya sekarang membenci CF, karena terlalu temperamental untuk digunakan.
</Rant>

TL; DR; Kebijakan Dukungan AWS Lambda Runtime tidak menyenangkan untuk digunakan dan dapat membuat Anda terlibat dalam masalah.
https://docs.aws.amazon.com/lambda/latest/dg/runtime-support-policy.html

@CraigHead maaf atas pengalaman Anda yang membuat frustrasi, tetapi untuk memperjelas kapan pun .NET Core 3.1 dirilis di Lambda, runtime .NET Core 2.1 akan didukung di Lambda hingga setidaknya 21 Agustus 2021 berdasarkan siklus dukungan Microsoft. Tidak perlu terburu-buru untuk mengonversi fungsi 2.1 menjadi 3.1. Saya berasumsi pengalaman Anda sebelumnya adalah dengan .NET Core 2.0 yang merupakan anomali untuk Lambda karena itu adalah satu-satunya versi non LTS yang masuk ke Lambda. Itu hanya dilakukan karena beberapa masalah besar dengan .NET Core 1.0.

Yup, itu adalah migrasi dari .NET Core 2.0 maju ke .NET Core 2.1. Maaf tentang kata-kata kasar. 30 hari agak ketat bagi sebagian dari kita. Melihat panjang keseluruhan, lambda berpotensi berjalan tanpa perawatan yang signifikan dan QA tambahan.

sementara itu, ini terjadi di sisi Azure tanpa server
https://visualstudiomagazine.com/articles/2020/01/30/azure-functions-3-0-runtime.aspx

Sementara itu tim AWS sedang mengerjakannya. Komentar snarky tidak membantu
mereka. Mereka akan memperbarui masalah ini jika sudah siap.

Pada Selasa, 11 Februari 2020 pukul 18:22, Rati Dzidziguri [email protected]
menulis:

sementara itu, ini terjadi di sisi Azure tanpa server

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

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
, https://github.com/aws/aws-lambda-dotnet/issues/554?email_source=notifications&email_token=AAAZVJXAAYET4F7PFFOTO3LRCLUETA5CNFSM4JU5UTJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBWZ2NLOORQPWWZJ2NLOORQ5PWZW63LN5MVXH
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AAAZVJQK3NBVXBZALM4V5KLRCLUETANCNFSM4JU5UTJA
.

Maksud saya bukan untuk memberikan komentar tajam tetapi untuk menunjukkan bahwa bahkan MS mengumumkan ketersediaan GA untuk 3.1 baru-baru ini, jadi saya berharap untuk melihat AWS menyelesaikan pekerjaan mereka pada dukungan 3.1 segera.
.

sementara itu, ini terjadi di sisi Azure tanpa server
https://visualstudiomagazine.com/articles/2020/01/30/azure-functions-3-0-runtime.aspx

Mengingat ini adalah bahasa MS, tidak mengherankan jika Azure mengalahkan AWS untuk mendukung ini.

Menonton utas ini dengan cermat - menantikan untuk memutakhirkan C # Lambdas saya.

dotnet core 3.1.0 dirilis 2019-12-03
https://dotnet.microsoft.com/download/dotnet-core/3.1

itu tersedia di Azure pada 23-01-2020
https://azure.microsoft.com/en-us/updates/azure-functions-runtime-30-is-now-available/

kami sedikit kekurangan satu bulan tambahan dibandingkan dengan Azure

BTW, semua pengembangan inti .NET dilakukan di tempat terbuka di github
Jadi, menjadi "bahasa MS" seharusnya tidak banyak berpengaruh.
Atau Anda menyarankan Klien AWS yang menggunakan dotnet lebih baik di Azure :P ?

Bagaimanapun, kepada siapa pun yang mendengarkan di AWS:
ada kami menunggu 3.1 di Lambda, itu penting bagi kami.

BTW, semua pengembangan inti .NET dilakukan di tempat terbuka di github
Jadi, menjadi "bahasa MS" seharusnya tidak banyak berpengaruh.
Atau Anda menyarankan Klien AWS yang menggunakan dotnet lebih baik di Azure :P ?

Maksud saya, akan sedikit memalukan jika Platform Cloud Microsoft tidak mendukung fitur-fitur baru dari bahasa mereka sendiri. Sejujurnya, saya sedikit terkejut mereka membutuhkan waktu lebih dari satu setengah bulan! Sedikit lebih banyak komunikasi internal mungkin akan memungkinkan keduanya dirilis pada saat yang bersamaan.

Saya pikir AWS bekerja dengan baik dengan dukungan .Net mereka, terutama dengan paket pengembangan yang terhubung ke layanan mereka seperti CloudWatch + ILogging dan konfigurasi parameter SSM mereka terkait. Ini sangat membantu kami.

Berharap untuk melihat rilis 3.1 segera :)

Saya berharap ada implementasi konkret Cloudwatch yang lebih baik dari ILogger . Ini akan lebih baik diintegrasikan ke dalam ServiceCollection / ServiceProvider saat menggunakan Lambda SDK. Versi saat ini yang disediakan dalam konteks permintaan dan kelas LambdaLogger statis pada dasarnya tidak mungkin untuk menguji unit/memverifikasi keluaran log dan mengaitkan .netcore ConsoleLogProvider default menghasilkan log Cloudwatch yang berantakan.

Saya berharap ada implementasi konkret Cloudwatch yang lebih baik dari ILogger .

Sudahkah Anda mencoba https://github.com/aws/aws-logging-dotnet#aspnet -core-logging ?

Apa yang Anda inginkan agar log Anda terlihat seperti @CraigHead?

Kami telah menggunakan Serilog & https://github.com/structured-log/structured-log di masa lalu untuk menampilkan log konsol yang bagus dan juga log berbasis JSON yang diimpor ke Seq. https://datalust.co/ itu adalah cara terbaik bagi kami untuk mendapatkan log pusat dalam format yang sangat bagus.

@CraigHead Amazon.Lambda.Logging.AspNetCore adalah implementasi kami untuk mengintegrasikan logging Lambda ke dalam IServiceCollection. Apakah perpustakaan itu tidak berfungsi untuk Anda.

Saya tidak akan merekomendasikan paket AWS.Logger.AspNetCore dari

Saya tidak tahu tentang ini. Terima kasih atas tipnya!
Saya mengacu pada Amazon.Lambda.Core.LambdaLogger di SDK.
Saya pasti akan memeriksa paket itu ( Amazon.Lambda.Logging.AspNetCore ) keluar.

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

@clearwaterstream
Di lambda-land AFAIK tidak ada peristiwa yang akan memberi tahu Anda bahwa instance saat ini akan berhenti memproses atau akan dihentikan, jadi saran Anda akan tetap membuat peristiwa log buffered non-flushed (hilang).

Tolong jangan membajak thread ini untuk keperluan lain.
Utas ini dibuat untuk memberikan beberapa info kapan .NET Core 3.1 di AWS Lambda akan tersedia.
Dan untuk memberi tahu AWS bahwa kami ada di luar sana dan menunggu.

Apakah alat uji lambda akan disertakan dalam rilis 3.1? https://github.com/aws/aws-lambda-dotnet/tree/master/Tools/LambdaTestTool

Itu adalah niat saya. Pekerjaan sedang berlangsung di mock-testtool-31 . Peningkatan besar di cabang 3.1 adalah kode Lambda pengguna sekarang berjalan di AssemblyLoadContext terpisah yang seharusnya memperbaiki banyak konflik versi yang dimiliki pengguna dengan versi saat ini. Saya melihat kembali mem-porting fitur AssemblyLoadContext ke versi 2.1.

Sebagai catatan sampingan. Saya telah berdebat tentang mengubah UI tulang telanjang menjadi aplikasi Blazor sisi server. Apakah ada orang yang memiliki lebih banyak pengalaman Blazor memiliki umpan balik tentang apakah itu ide yang baik atau buruk?

Sebagai catatan sampingan. Saya telah berdebat tentang mengubah UI tulang telanjang menjadi aplikasi Blazor sisi server. Apakah ada orang yang memiliki lebih banyak pengalaman Blazor memiliki umpan balik tentang apakah itu ide yang baik atau buruk?

Apa pun Blazor saat ini adalah ide yang bagus, terutama bagi kita yang menggunakan DotNet!

"UI tulang telanjang" - ini adalah beberapa aplikasi lain, tidak terhubung ke .NET Core 3.1 Lambdas?
BTW, saya sama sekali tidak peduli dengan blazer

@petarrepac Ini mengacu pada AWS .NET Mock Lambda Test Tool yang kami kirimkan untuk membantu men-debug fungsi .NET Core 2.1 Lambda. Berikut adalah posting untuk referensi https://aws.amazon.com/blogs/developer/debugging-net-core-aws-lambda-functions-using-the-aws-net-mock-lambda-test-tool/

Saya sedang dalam proses memperbarui alat untuk .NET Core 3.1.

@normj
ah, tidak mengerti, terima kasih
itu pemikiran yang menarik, bahwa kami tidak pernah membutuhkan alat seperti itu

dari perspektif kami lambda adalah barebone AspNetCore HttpApi yang dapat Anda hubungi secara lokal dan uji secara lokal
satu-satunya perbedaan adalah file/kelas titik masuk yang berada di bawah 50 baris kode
juga, banyak hal yang hanya dapat diuji dengan benar saat diterapkan ke AWS:

• izin
• bentuk acara dan konteks JSON yang diterima
• ...
  jadi, kombinasi dari:
• tes unit/integrasi yang baik berjalan secara lokal
• pengujian http lokal
• mudah digunakan untuk menguji lingkungan aws
  bisa pergi jauh

atau saya melewatkan beberapa skenario yang jelas?

@petarrepac Itu adalah salah satu manfaat besar menggunakan ASP.NET Core bridge adalah sangat mudah dijalankan secara lokal. Saya setuju praktik terbaik adalah menggunakan pengujian unit/integrasi tetapi sering kali ada kebutuhan untuk pengujian adhoc cepat dari logika aplikasi dan itulah gunanya alat ini.

Terima kasih @normj. Mengenai Blazor, itu bisa menjadi sentuhan yang bagus. Untuk kasus penggunaan tim kami setidaknya mungkin akan kurang dimanfaatkan.

Kami hanya cukup lama di UI untuk mengirim muatan, lalu melangkah melalui kode di VS.

Anda pasti dapat mencapai beberapa fungsi lambda dari satu basis kode menggunakan Lambda Bootstrapper dan fitur runtime kustom.

Saya memiliki rangkaian 16 lambda yang digunakan dari satu aplikasi, bukan "monolit".

Ini dicapai dengan menggunakan variabel lingkungan _handler untuk memilih metode yang akan digunakan pada saat runtime, daripada pemetaan satu-ke-satu yang dikodekan secara keras yang ditunjukkan dalam kode sampel entri blog.

Saya menganggapnya sebagai aplikasi konsol yang menerima sakelar yang memberi tahu tindakan apa yang harus "menjadi" ketika dimulai.

@martincostello

Saya mengalami kesulitan melakukan ini berdasarkan penjelasan Anda. Saya memiliki sekitar 20 fungsi Lambda di Functions.cs saya yang terkait dengan definisi yang sesuai di serverless.template saya. Saya mengerti Anda akan melewati variabel lingkungan dengan setiap definisi untuk menunjukkan fungsi mana yang akan dipanggil. Sebagian besar fungsi ini adalah tanda tangan:

APIGatewayProxyResponse ThisLambdaFunction publik (permintaan APIGatewayProxyRequest, konteks ILambdaContext)
{

Bagaimana cara menambahkan dukungan untuk tanda tangan fungsi lambda yang berbeda, jika saya memiliki fungsi lain yang menggunakan argumen berbeda (selain APIGatewayProxyRequest ) dan tipe pengembalian yang berbeda?

Tolong jangan menggagalkan utas.

@twopointzero Saya telah menghabiskan berhari-hari Google mencari solusi untuk menjalankan beberapa fungsi lambda menggunakan proyek .NET Core 3.1 Custom Runtime. Tidak ada utas yang lebih relevan di internet dan saya membalas posting yang ada yang memberikan secercah harapan bahwa ada solusi untuk masalah saya.

Tidak memiliki dukungan .NET Core 3.1 asli di AWS membuat hidup menjadi sulit. Kami perlu memutakhirkan ke 3.1 untuk meningkatkan ke EntityFramewore Core 3.1.2 terbaru, yang memperbaiki masalah yang kami lihat dengan penyatuan koneksi di Aurora (PostgresSQL).

@normj Saya benar-benar mengerti sikap tanpa ETA tetapi dapatkah Anda memberi tahu saya jika kita sudah dekat? < 30 hari?

@antsaia Dengan hormat, komentar Anda terkait dengan penyebaran monolit terdistribusi menggunakan dukungan runtime kustom, tidak terkait dengan dukungan AWS Lambda untuk .NET Core 3.1. Jika Anda tidak dapat menemukan utas yang lebih relevan di internet, saya akan meminta Anda untuk membuatnya daripada menggagalkannya.

Agar tidak menggagalkan utas ini sendiri, ini adalah komentar terakhir saya tentang masalah ini.

@normj apakah ada sumber daya yang tersedia (blog, forum, dll.) di mana kami dapat memperoleh informasi tentang status implementasi dukungan .net core 3.1?

Saya mengunjungi halaman ini setiap hari dengan harapan mendapatkan informasi baru tetapi jelas tidak ada informasi yang cukup (karena tidak dimaksudkan untuk penggunaan itu). Akan jauh lebih mudah jika kami memiliki semacam pembaruan dasar sehingga kami dapat merencanakan ke depan.

Seperti banyak di sini, rencana kami untuk memberikan fitur sangat bergantung pada apakah kami dapat menggunakan 3.1 atau jika kami harus mengembangkannya menggunakan 2.1. Dalam kasus saya, 3.1 akan menyediakan dukungan untuk System.Draw dan ini berdampak besar pada fitur yang akan saya kerjakan.

Yang saya inginkan untuk.... Hari St. Patrick adalah lambda .net core 3.1 support

@liam-sage yang bisa saya temukan hanyalah beberapa posting di forum amazon yang menunjukkan bahwa itu akan siap pada Q1 2020. https://forums.aws.amazon.com/thread.jspa?threadID=313806

@liam-sage yang bisa saya temukan hanyalah beberapa posting di forum amazon yang menunjukkan bahwa itu akan siap pada Q1 2020. https://forums.aws.amazon.com/thread.jspa?threadID=313806

Ini berarti harus ditayangkan pada bulan Maret. aku menunggu.

Hai, saya tahu ini tidak sepenuhnya cocok tetapi Anda dapat memperbarui lambda Anda sendiri ke dotnetcore 3.1. Sementara itu sambil menunggu, saya sarankan jika Anda membuat banyak lambda untuk menulis template dotnetcore Anda sendiri. Saya melakukan itu untuk saya sendiri. Saya ingin memastikan bahwa saya tidak perlu membuang waktu berjam-jam dengan kode boilerplate. Contoh template dapat ditemukan di sini .

Dan Vincent, Bagaimana kita menyimpannya di sana? menggunakan waktu proses khusus?
Pada Kam, 5 Mar 2020 jam 19:40 Vincent van der Walt <
[email protected]> menulis:

Hai, saya tahu ini tidak sepenuhnya cocok tetapi Anda bisa mendapatkan lambda Anda sendiri
diperbarui ke dotnetcore 3.1. Sementara itu sambil menunggu saya akan menyarankan
jika Anda membuat banyak lambda untuk menulis template dotnetcore Anda sendiri. ya
itu untuk saya sendiri. Saya ingin memastikan bahwa saya tidak perlu membuang waktu berjam-jam dengan
kode boilerplate. Contoh template dapat ditemukan di sini
https://github.com/vincentvanderwalt/aws-lambda-dotnetcore-3-template .

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/aws/aws-lambda-dotnet/issues/554?email_source=notifications&email_token=AGIDH4OWUT7Y3HR3O5KARBDRF62V3A5CNFSM4JU5UTJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBGW63LNMVX26
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AGIDH4PLKFSDLNBX2QVMG63RF62V3ANCNFSM4JU5UTJA
.

Ya itu menggunakan runtime khusus.

Anda dapat menjalankannya secara lokal di mesin Anda atau menerapkannya ke aws.

F5 untuk lokal dan dotnet lambda deploy-serverless untuk penerapan ke aws

Readme menjelaskan cara menginstal template ke mesin lokal Anda (ini adalah template dotnetcore)

Waktu proses khusus memang keren, tetapi saya masih menunggu dukungan penuh AWS untuk .Net Core 3.1 agar lambda dapat menggunakannya di lingkungan produksi

Setiap kali saya melihat ini di kotak masuk saya, saya dengan bersemangat membukanya untuk melihat apakah @normj memiliki
mengumumkan apa pun hanya untuk menemukan posting yang setidaknya sedikit off
tema. Orang lain meminta orang lain untuk tidak membajak utas dan itu belum
bekerja. Dapatkah seseorang mengunci utas sampai seseorang siap untuk mengumumkan
rilis dukungan 3.1?

Pada Jum, 6 Mar 2020 jam 07:13 bartoszsiekanski [email protected]
menulis:

Waktu proses khusus memang keren, tetapi saya masih menunggu dukungan penuh AWS
untuk .Net Core 3.1 untuk lambda untuk menggunakannya di lingkungan produksi

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/aws/aws-lambda-dotnet/issues/554?email_source=notifications&email_token=AAVUT3SNDR4L2ZL5J4KQYDDRGDSHBA5CNFSM4JU5UTJKYY3PNVWWK3TUL52HS4DFVREXG43VMXVBW63LN5WH2JKTLN5
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AAVUT3TBH3NIBMGB54EFCR3RGDSHBANCNFSM4JU5UTJA
.

Harap buat masalah terpisah untuk hal lain selain membahas dukungan .NET Core 3.1. Bisakah saya menutup masalah ini sampai kami memiliki lebih banyak berita @normj ?

@hounddog22030 Saya tidak menyadari bahwa saya 'membajak'

Jika AWS mendukung opsi --self-contained dalam perintah paket lambda dotnet, fungsi lambda harus dapat dieksekusi terlepas dari versi SDK-nya. Baik? Mengapa tidak melakukan itu daripada menambahkan dukungan untuk setiap rilis .NET Core?

Jika AWS mendukung opsi --self-contained dalam perintah paket lambda dotnet, fungsi lambda harus dapat dieksekusi terlepas dari versi SDK-nya. Baik? Mengapa tidak melakukan itu daripada menambahkan dukungan untuk setiap rilis .NET Core?

Anda baru saja menjelaskan fitur runtime kustom lambda

@aussiearef Itu memang bekerja dengan baik, tetapi paket mandiri termasuk .Net Core itu sendiri, yang biasanya menambahkan hingga setidaknya 40MB (zip) untuk situs web -- tidak menyisakan banyak ruang untuk aplikasi dan dependensi itu sendiri.

Saat menggunakan versi inti .NET yang sama, runtime kustom juga lebih lambat (cold start) daripada runtime asli. 3.1 menambahkan banyak peningkatan kinerja, sehingga Anda dapat mengharapkan tingkat kinerja yang sama antara 3.1 kustom yang dioptimalkan sepenuhnya dan 2.1 asli. Saya memiliki harapan bahwa 3.1 native akan membawa peningkatan yang signifikan.

Q1 akan berakhir dalam 4 hari, tetapi sepertinya kita tidak akan melihat 3.1 di lambda.
Saya harap semua anggota tim aman di masa pandemi ini dan berharap untuk melihat rilis ini di Q2.

Jangan putus asa, masih ada beberapa hari lagi! Kita semua cukup sibuk menunggu penerapan akhir dan aktivitas menit terakhir lainnya. Ingatlah bahwa kita semua tahu perangkat lunak dan mungkin ada cegukan di menit-menit terakhir.

Saya sebenarnya berencana untuk memulai peluncuran pembaruan perkakas klien baru segera untuk memastikan semuanya tersedia setelah runtime dibuka. Jadi jika Anda melihat pembaruan paket NuGet baru keluar, jangan menganggap runtime ada di sana. Tunggu sampai posting blog keluar dan saya akan memposting pembaruan di sini.

Itu berita yang fantastis. Terima kasih @normj

Menantikan posting blog dan rilis.

Jangan putus asa, masih ada beberapa hari lagi! Kita semua cukup sibuk menunggu penerapan akhir dan aktivitas menit terakhir lainnya. Ingatlah bahwa kita semua tahu perangkat lunak dan mungkin ada cegukan di menit-menit terakhir.

Saya sebenarnya berencana untuk memulai peluncuran pembaruan perkakas klien baru segera untuk memastikan semuanya tersedia setelah runtime dibuka. Jadi jika Anda melihat pembaruan paket NuGet baru keluar, jangan menganggap runtime ada di sana. Tunggu sampai posting blog keluar dan saya akan memposting pembaruan di sini.

Kesabaran Anda dalam menghadapi sikap di utas ini sangat mengesankan. Terima kasih telah mengerjakan ini!

@normj senang membantu dengan pengujian apa pun yang mungkin ingin Anda lakukan sebelum menerbitkan ;)

2 hari lagi dan semoga saja.

Dan keluar dengan 13 jam tersisa di kuartal

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

Terima kasih semuanya atas kesabaran Anda. @raRaRa Saya akan memberi Anda kehormatan untuk menutup masalah ini.

Besar

Pada Selasa, 31 Maret 2020, 20:06 Norm Johanson, [email protected] menulis:

Dan keluar dengan 13 jam tersisa di kuartal

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

Terima kasih semuanya atas kesabaran Anda. @raRaRa https://github.com/raRaRa
Saya akan memberi Anda kehormatan untuk menutup masalah ini.

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/aws/aws-lambda-dotnet/issues/554#issuecomment-606785798 ,
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AGUX3OUR6LN5CERIBTDHXP3RKIWLVANCNFSM4JU5UTJA
.

Terima kasih!!!!

Dan.... Berhenti Berlangganan :-)

Terima kasih untuk semua yang terlibat!!!

Terima kasih!

Dan keluar dengan 13 jam tersisa di kuartal

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

Terima kasih semuanya atas kesabaran Anda. @raRaRa Saya akan memberi Anda kehormatan untuk menutup masalah ini.

Kerja bagus!

Itu adalah bayi AWS. Itulah AWS!!!
Tidak peduli apa yang terjadi, pada akhirnya, mereka menyelesaikannya.

Terima kasih banyak, tim!!!

Berita bagus dan terima kasih banyak @raRaRa @normj !!! Dengan risiko terdengar bodoh dan/atau serakah, apakah ini juga berarti Powershell 7 secara intrinsik? Hanya memeriksa dua kali ......

Kerja bagus @normj dan semua orang di AWS! 🥳

Berikut tautan ke blog untuk mereka yang menggulir ke bawah
https://aws.amazon.com/blogs/compute/announcing-aws-lambda-supports-for-net-core-3-1/

luar biasa, terima kasih banyak telah menambahkan dukungan ke dotnet core 3.1!!!

@andyKalman Belum di PowerShell 7. Saya melakukan beberapa sentuhan akhir pada modul AWSLambdaPSCore dan kemudian akan merilis versi 2.0.0 AWSLambdaPSCore ke galeri.

Saya menghargai balasan cepat @normj . Saya memang melihat #607 setelah fakta, sangat bagus untuk melihatnya sebagai tindak lanjut yang cepat. Apakah ada masalah lain untuk dilacak sehingga saya dapat menghentikan komentar di sini? :) Terima kasih lagi.

Selamat!
Dan terima kasih AWS dan Tim .NET!
Sangat dihargai.

Terima kasih kepada semua orang yang membantu mewujudkan ini! Ini adalah rilis besar dan ini menunjukkan banyak kerja keras untuk itu! Bagus! 🎉🥳

Terima kasih !! : tepuk:: tepuk:: tada:: tada:

Congrats guys, berharap untuk meng-upgrade.

Terima kasih!

Pekerjaan yang luar biasa, ingin memutakhirkan lambda ini.

Kerja bagus! Terima kasih @normj 👏 👏

Tim kerja yang hebat!

Ingin bergabung dengan pekerja Lambda dengan dotnet 3.1 Async Streams +langganan AWS AppSync/GraphQL.
Tim AWS, Terima Kasih Banyak!

OMG, kalian yang mengatur! Luar biasa! Woo hoo! 😄😄😄

TERIMA KASIH!

@andyKalman Saya mengeluarkan versi 2.0.0 dari modul AWSLambdaPSCore yang sekarang menggunakan PowerShell 7. Saya berencana untuk membuat posting blog tentang dukungan PS7 tetapi bertindak sama dengan dukungan PowerShell 6 yang ada hanya menggunakan 7.

@andyKalman Saya mengeluarkan versi 2.0.0 dari modul AWSLambdaPSCore yang sekarang menggunakan PowerShell 7. Saya berencana untuk membuat posting blog tentang dukungan PS7 tetapi bertindak sama dengan dukungan PowerShell 6 yang ada hanya menggunakan 7.

Apakah versi baru AWSLambdaPSCore memperbarui konfigurasi apa pun dalam fungsi Lambda saya yang ada jika saya menerbitkannya dengan versi baru? Seperti apakah itu akan mengarahkannya ke dotnet3.1 dan ps7?

@tr33squid Ya jika Anda menyebarkan dengan 2.0.0 itu akan menggunakan .NET Core 3.1 dan PS7

Terima kasih banyak dan kerja bagus tim AWS!!

Halo semuanya,

Saya secara aktif berupaya menghadirkan dukungan untuk .NET Core 3.1 di Lambda. Dibutuhkan beberapa waktu karena banyak pekerjaan yang dilakukan oleh Microsoft dalam cara mereka membangun runtime. Saya sedang berupaya menggabungkan perubahan ini untuk memberi Anda runtime asli.

Terima kasih kepada tim inti AWS-Lambda .NET

Hai,
Saya mendapatkan kesalahan ini saat mencoba menjalankan AWS-Lambda
Tidak mungkin menemukan versi kerangka kerja yang kompatibel.
Kerangka kerja yang ditentukan 'Microsoft.AspNetCore.App', versi '3.1.0' tidak ditemukan.
ada saran??

Hai,
Saya mendapatkan kesalahan ini saat mencoba menjalankan AWS-Lambda
Tidak mungkin menemukan versi kerangka kerja yang kompatibel.
Kerangka kerja yang ditentukan 'Microsoft.AspNetCore.App', versi '3.1.0' tidak ditemukan.
ada saran??

Anda perlu menginstal SDK 3.1.0.

Saya percaya Microsoft.AspNetCore.App harus dihapus dari proyek Anda
dependensi, tidak lagi diperlukan untuk Core 3.1.0, saya harus menghapusnya ke
membangun dan menerapkan layanan yang saya tingkatkan dari 2.1.

Pada Jum, 24 Apr 2020 jam 3:24 Gregory Lyons [email protected]
menulis:

Hai,
Saya mendapatkan kesalahan ini saat mencoba menjalankan AWS-Lambda
Tidak mungkin menemukan versi kerangka kerja yang kompatibel.
Kerangka kerja yang ditentukan 'Microsoft.AspNetCore.App', versi '3.1.0' adalah
tidak ditemukan.
ada saran??

Anda perlu menginstal SDK 3.1.0.

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/aws/aws-lambda-dotnet/issues/554#issuecomment-618850277 ,
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AMSHCOLW5WJDS7CCAFDMP4TROE5ENANCNFSM4JU5UTJA
.

--
Terbaik,
George

George Taskos
Arsitek Solusi Senior

Kami8
230 Park Avenue, lantai 3 Barat
New York, NY 10169
(917) 717-9067
weare8.com

Pintu Masuk Pribadi,
71 Vanderbilt Ave
lantai 3

Saya percaya Microsoft.AspNetCore.App harus dihapus dari dependensi proyek Anda, tidak lagi diperlukan untuk Core 3.1.0, saya harus menghapusnya untuk membangun dan menyebarkan layanan yang saya tingkatkan dari 2.1.
…
Pada Jum, 24 Apr 2020 jam 3:24 Gregory Lyons @ . * > menulis: Hai, saya mendapatkan kesalahan ini ketika mencoba menjalankan AWS-Lambda Tidak mungkin menemukan versi kerangka kerja yang kompatibel. Kerangka kerja yang ditentukan 'Microsoft.AspNetCore.App', versi '3.1.0' tidak ditemukan. ada saran?? Anda perlu menginstal SDK 3.1.0. — Anda menerima ini karena Anda berlangganan utas ini. Balas email ini secara langsung, lihat di GitHub < #554 (komentar) >, atau berhenti berlangganan https://github.com/notifications/unsubscribe-auth/AMSHCOLW5WJDS7CCAFDMP4TROE5ENANCNFSM4JU5UTJA .
-- Best, Arsitek Solusi Senior George George Taskos WeAre8 230 Park Avenue, 3th fl. West New York, NY 10169 (917) 717-9067 Pintu Masuk Pribadi weare8.com, 71 Vanderbilt Ave Lantai 3

Terima kasih untuk balasan Anda,
Sebenarnya kesalahan ini adalah karena kesalahan konyol saya. Saya lupa menghapus runtime: dotnetcore2.1 di serverless.yml saya. Sekarang masalah terpecahkan.

Adakah yang melakukan benchmark/perbandingan yang diperbarui tentang ini? Yang bisa saya temukan hanyalah yang lama dengan runtime khusus..

Adakah yang melakukan benchmark/perbandingan yang diperbarui tentang ini? Yang bisa saya temukan hanyalah yang lama dengan runtime khusus..

Ini yang bagus.
https://medium.com/@zaccharles/a -close-look-at-net-core-3-1-on-aws-lambda-9ccec4dd96be

Juga pengalaman pribadi saya memperbarui lambda 2.1 kompleks menjadi 3.1 pada ukuran lambda 512mb melihat kinerja yang hampir sama persis (awal dingin dan hangat). Baik lambda 2.1 dan 3.1 menggunakan lapisan lambda, publikasi yang dioptimalkan, newtonsoft (mungkin melihat peningkatan kinerja dengan Microsoft json di 3.1), kompilasi berjenjang tidak aktif, dan RTR untuk 3.1.

Dari metrik saya, tampaknya mendapatkan sedikit kinerja dengan runtime dotnet 3.1, tetapi kehilangan kinerja di Amazon Linux 2 dan inisialisasi dotnet 3.1. (2.1 menggunakan Amazon Linux 1.) Menghasilkan keuntungan.