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コンパイルなどの機能がいくつかあります。

• PublishReadyToRun
• PublishTrimmed

@normjは、更新のためにこの問題をサブスクライブする必要がありますか、それとも進行のために従う必要がある別の.NET Core 3.1の問題がありますか？

この問題を使用して、更新を追跡できます。 残念ながら、ステータスの更新は、リリースされるまで提供できない可能性があります。

コールドスタート時間のスピードアップはありますか？

.NET Core 3.1には、AOTコンパイルなどの機能がいくつかあります。

• PublishReadyToRun
• PublishTrimmed

コメントの答えが「はい」の場合、ローカル環境から「コンパイルされたラムダ」を実行してテストすることは可能ですか？ 私はそれのためにLinux環境を熱心に設定します:)

ここに更新はありますか？

@ rati-dzidziguri

上記のように@normjから

この問題を使用して、更新を追跡できます。 残念ながら、ステータスの更新は、リリースされるまで提供できない可能性があります。

@beeradmoore
私の質問はETAについてでした。 それに応じて準備できるので、このためのETAを知ることは役に立ちます。

@ rati-dzidziguri Amazonは、リリースに関してETAを開示することはめったにありません。

@ rati-dzidziguri ETAが必要なことを理解し、感謝しているので、それに応じて計画を立てることができます。 実際には、100％確実に維持できるとは限らないという約束をしないように一生懸命努力しているため、通常はETAを提供しません。 私はあなたにETAを与えることを嫌い、あなたはそれに基づいてあなたのロードマップを作成します、そして私たちはあなたがあなたの計画のすべてを混乱に投げ込むことを期待したそのETAを逃します。

今のところ、本当に.NET Core 3.1の機能が必要な場合は、ここで説明するLambdaカスタムランタイムとして.NET Core 3.1を使用することをお勧めします（.NET Core3.0から.NETCore 3.1への参照の変更を除く）。 次に、ネイティブの.NET Core 3.1サポートが登場すると、Lambda関数のいくつかの設定を変更するという非常に簡単な移行が可能になります。

@normj 「LambdaEntry」クラスでカスタムランタイム機能を使用できないと判断した理由の1つは、実装アプローチの「モノリシックアーキテクチャ」の側面です。 すべてのAPIリクエストは、1つのエントリラムダを介して送信され、ASP .netプロジェクトのコントローラーに「配布」されます。これは、カスタムランタイム構造が意図したものです。これは間違いなく便利ですが、必要な場合の構造上の欠点が含まれます。 すべてのコマンド/クエリリクエストをそれぞれラムダにしたいと思います。 それ以来、いくつかの機能を分割し、いつでもコードを管理できるデプロイメントパッケージの管理に関する拡張性を得ることができます。
これが、「runtime：.netcore 3.1」構成のテンプレートで記述されたSAMを使用して、「単一目的のラムダ」のバンドルを構築できる公式ランタイムがサポートされるのを待っている理由です。

私がうまくいかない場合は私にアドバイスをください:)

Lambda Bootstrapperとカスタムランタイム機能を使用すると、1つのコードベースから複数のラムダ関数を確実に実現できます。

「モノリス」ではなく、1つのアプリケーションからデプロイされる16個のラムダのスイートがあります。

これは、ブログ投稿のサンプルコードに示されているハードコードされた1対1のマッピングではなく、 _handler環境変数を使用して実行時に使用するメソッドを選択することで実現されます。

起動時に「なる」アクションを指示するスイッチを受け取るコンソールアプリだと思います。

@martincostello
親切な提案ありがとうございます！ 私はあなたのケースがどのように見えるかを理解することができます。 ランタイムの最初のステージで機能を判別できるように、スイッチロジックをMainクラスまたはStartupクラスに配置した可能性があります。 もちろん、「モノリシックのみ」の問題を解決することもできます。 非常に賢いアプローチ:)

しかし、それでも、特にチームとして働くことを想像するとき、私が考えなければならない1つの（多くではないにしても）考慮事項があります。 カスタムランタイムを使用し、起動時に「機能ID」を決定すると、SAMの可能性がなくなります。 簡単な例として、ラムダのデプロイ中にAPIゲートウェイを定義することはできません。つまり、ラムダ用に手動で生成する必要があります。
awsチュートリアルで説明されているように、ブートストラップスクリプトを使用してSAMのような構成を作成できるため、ここで誇張していることはわかっています。 しかし、Linuxスクリプトを使用しているため、完全に満足することはできません。
（1）新規参入者にとっては恥ずかしいことであり、学習曲線になることもあります。
（2）サーバーレステンプレートは文字通りドキュメントではなくスクリプトであるため、サーバーレステンプレートの表現力の利点を破棄します。

サーバーレステンプレートは、サーバーがどのように表示され、どのように機能するかについての半文書として機能すると思います。これは、開発チーム内だけでなく、洞察力のある非技術者でも共有されます。 SAMは明確に定義された概念であり、近い将来、アプリケーションの抽象的な表現により、まったく異なる言語とプラットフォームを使用する別のチームが再利用できるようになります。 これらの側面は、「サーバーレステンプレート」機能を使用することに固執する動機を私に与えていることは間違いありません。

これをリリースする前のいくつかの素晴らしい日付、12月25日、1月1日が頭に浮かぶ;）

みなさん、おめでとうございます。クリスマスにすべての.NET Core 3.1 Lambdaランタイムを提供できればと思いますが、2020年は.NETとAWSにとってエキサイティングなものになると思います。

みなさん、おめでとうございます。クリスマスにすべての.NET Core 3.1 Lambdaランタイムを提供できればと思いますが、2020年は.NETとAWSにとってエキサイティングなものになると思います。

心配いりません、休日を楽しんでください！ 2020年にあなたが私たちのために何を持っているかを見るのが待ちきれません！ :)

.NetCore3.1でのラムダネイティブサポートを待っています

ラムダ関数にはディスクサイズの制限があります。 250メガバイトだと思います。カスタムランタイムを使用する場合は、すべてのasp.netコアアセンブリをアプリと一緒に送信する必要があります。 AWSがzipパッケージを解凍しているときに、その制限に達しました。 アプリが使用するスペースを減らすために、クリーンアップを行う必要がありました。 ネイティブサポートがリリースされたら、アプリを.coreのアセンブリと一緒にパッケージ化する必要はありません。

これがいつリリースされると予想できるかについての見積もりはありますか？

ネイティブサポートが提供されるまで、.Net Core3.1へのアップグレードを待っています。

これがいつリリースされると予想できるかについての見積もりはありますか？

ネイティブサポートが提供されるまで、.Net Core3.1へのアップグレードを待っています。

戻って返信を読むと、normjから見積もりが得られないことがわかります。

戻って返信を読むと、normjから見積もりが得られないことがわかります。

うーん、通常-はい。 しかし、十分な数の人々がピッチフォークを持って現れた場合、不安を鎮めるためにリリース日のヒントが与えられるかもしれません：grin：

AWSが2.1ネイティブイメージの準備に長い時間を費やしたときのことをしばらく前に覚えています。 彼らは、将来のバージョンの展開をより簡単かつ迅速に立ち上げることができるようにプロセスを再設計したという趣旨の何かを言いました。 NetCore 3.1に入り、ほぼ2か月後、まだ利用できません:(

Azureがこの3.1イメージを1日目に利用できるようにしたことをご存知でしょう。米国政府がJEDIのクラウドプロバイダーとしてAzureを選択した理由がわかり始めています。

利害関係者から青信号を得て、AWSをバックアップとして残してプライマリプロバイダーとしてAzureをターゲットにし始めました。 このようなばかげた遅れがあるので、私たちだけではないと確信しています。

AWSが2.1ネイティブイメージの準備に長い時間を費やしたときのことをしばらく前に覚えています。 彼らは、将来のバージョンの展開をより簡単かつ迅速に立ち上げることができるようにプロセスを再設計したという趣旨の何かを言いました。 NetCore 3.1に入り、ほぼ2か月後、まだ利用できません:(

Azureがこの3.1イメージを1日目に利用できるようにしたことをご存知でしょう。米国政府がJEDIのクラウドプロバイダーとしてAzureを選択した理由がわかり始めています。

利害関係者から青信号を得て、AWSをバックアップとして残してプライマリプロバイダーとしてAzureをターゲットにし始めました。 このようなばかげた遅れがあるので、私たちだけではないと確信しています。

仰るとおりです。 私の組織はカスタムランタイムを許可しておらず、2.1で立ち往生しています。 空間操作と一緒にEFとPostgresになると、それはあまりにも苦痛です。 私たちはこれが行われるのを待っていました。 それがまだ行われていないのは残念です。

AWSが2.1ネイティブイメージの準備に長い時間を費やしたときのことをしばらく前に覚えています。 彼らは、将来のバージョンの展開をより簡単かつ迅速に立ち上げることができるようにプロセスを再設計したという趣旨の何かを言いました。 NetCore 3.1に入り、ほぼ2か月後、まだ利用できません:(

Azureがこの3.1イメージを1日目に利用できるようにしたことをご存知でしょう。米国政府がJEDIのクラウドプロバイダーとしてAzureを選択した理由がわかり始めています。

利害関係者から青信号を得て、AWSをバックアップとして残してプライマリプロバイダーとしてAzureをターゲットにし始めました。 このようなばかげた遅れがあるので、私たちだけではないと確信しています。

JEDIは.NETCoreを使用して、政府がAzureを採用した理由を推測していますか？

皆さんこんにちは、

私はLambdaで.NETCore3.1のサポートを提供することに積極的に取り組んでいます。 ランタイムの構築方法についてMicrosoftが多くの作業を行ったため、時間がかかります。 これらの変更を組み込んで、ネイティブランタイムを提供するよう取り組んでいます。

@assyadhありがとうございます！ 遅れが「ばかげている」とは思わない。 実際、私はむしろしっかりした動作バージョンを待ちたいと思います。 AWSLambdaが.NETCoreをサポートしていることを嬉しく思います。また、約束どおり、引き続きサポートしていただきありがとうございます。

私はその衝動を理解していません。 現在、LTS環境がないわけではありません。

明らかに新しいおもちゃを使いたいのですが、AWSの.NETチームには一定量のリソースしかなく、一度にすべてを行うことはできません。

その上、私はサービス条件から外れることを恐れて、すべての関数のランタイムを急いで更新する必要性を切望していません。

@Kralizekにとっては良いこと@JamesQMurphyが言うように、リリースがしっかりしていることも望んでいます。

@assyadhの作品を楽しみにしています。

「私はその衝動を理解していません。」

.NET Core2.1ラムダ関数で共有.NETCore 3.1を使用することはできません。実際、.NET Core2.1ラムダ関数で共有.NETCore 2.2コードを使用することすらできないため、最近、しぶしぶダウングレードする必要がありました。共有コンポーネントを.NETCore 2.1に接続して、関数でサポートされるようにします。

共有コンポーネントをnetstandard20でコンパイルできますか？ 次に、それらをnetcore2＆3で共有できます

このスレッドは.NET3.1に固有のものですが、この正確な会話は、.NET 5（または、次のLTSになる場合は6）が到着したときに再び再生されると確信しています。

不可能な特定の例がいくつか挙げられていますが（コードZIPファイルが大きすぎる、会社のポリシーなど）、今後「最新かつ最高の」.NET Coreを使用する場合は、次の方法でこれを行うことができます。少しのリファクタリングとカスタムランタイムサポートパッケージ。

現時点では、最新リリースがLTSリリースであることがたまたま発生しているため、Amazonからの「ASAP」の必要性が以前よりもはるかに「緊急」になっているように思われます。たとえば、2.2または3.0のサポートが組み込まれています。

最終的には、Lambdaで使用できる新機能と、PaaSソリューションに投入する必要のある開発作業との間にトレードオフがあります。

.NET Core 3.1は、リリース後2〜3週間、MicrosoftのAzure AppServiceで利用できませんでした。

一般的にできるだけ早く「最先端」になりたい場合は、短期間にカスタムランタイムサポートの使用に少額の投資を行うことで、Lambdaで将来のバージョンの.NETCoreを独自のタイムスケールで実行できるようになります。 もちろん、ここでのトレードオフは、パッケージが大きく、コードがわずかに多く、独自のパッチを適用する必要があることです。

すべてにおいて、バランスとトレードオフがあり、組み込みのサポートの場合、ソフトウェアには時間がかかるため、現実的には常に可用性に遅れが生じます。

.NETのメジャーリリースが11月に予定されているため、クリスマス/ホリデー期間は、ラムダチームの時間と利用可能な容量の観点から、これらのものを組み込みで利用できるようにするのにかかる時間に常に影響を及ぼします。

私の考えを追加するだけです。 このリリースがいかに重要であるかを理解しており、ご連絡いただきありがとうございます。 私はそのフィードバックを使用して、私たちの側に緊急性を押し付けます。 @martincostelloが述べたように、.NET Core 3.1が

私は過去2.1で、私たちが導入した自動化によって将来のリリースがスピードアップすることを期待していると述べた人でした。 @assyadhが導入した自動化は本当にCore2.1を実行してから状況が大きく変わりました。 その一部はMSが.NETCoreを構築する方法であり、他の部分はLambdaサービスがAmazon Linux2への移行でどのように機能するかです。

ですから、.NET Core 3.1は@assyadhであり、私自身や他の多くの人が最優先事項であると信じてください。

確認するために、それを組み込む作業は、Microsoftが最終リリースを待つのではなく、プレリリースをリリースすると開始されますか？ これにより、おそらくクリスマスの影響が軽減され、テストが必要になるだけなので、最終リリースがリリースされたらすぐに配信できるようになります。

私はそのフィードバックを使用して、私たちの側に緊急性を押し付けます

この@normjをありがとう。 これが私の0.02ドルです。それがあなたの伝道にも役立つことを願っています。

@martincostelloが述べたように、.NET Core 3.1が

@mungojamがほのめかしたように、.NET Core 3.1は、リリースの1か月以上前の10月15日からプレビュー形式で利用可能でした。 また、基本的には3.0のバグ修正リリースです。ツールはわかりませんが、 9月23日にリリースされて一年中プレビューされている3.0を使用して探索作業を開始できたと思います。 3.0のリリース発表で3.1にリリース予定日が指定されたことは注目に値します。

.NET Core 3.1は、リリース後2〜3週間、MicrosoftのAzure AppServiceで利用できませんでした。

.NET Core 3.1は、プレビュー1がリリースされてから2日後の10月17日にAzureFunctionsで利用可能になりました。

「最先端」やカスタムランタイムオプションなど、どの企業でも3.1が必要なことについてすぐに何を言うことができますが、これはAWSが.NETをどれほど真剣にサポートしたいかについての全体像の一部です。顧客。 AWS（Normのチームではなく、AWS全体）がそれを優先した場合、Azureと競合していることを確認して、AWSがこの前に出ていた可能性があると考えなければなりません。

個人的には、企業の教義ではなくメリットに基づいて選択できるクラウド製品の中からオプションを選択できることを非常に大切にしています。AWSが.NETサポートを改善するための次のステップを踏み出すことを望んでいます。

@ normj 、 @ assyadh 、およびこれに取り組んでいる他の人に感謝します。

AWSの.NETチームは、3.0プレビューのリリース時に.NET 3.1LTSの準備の旅を非常にうまく始めた可能性があります。 つまり、AWSは、カーテンの後ろで何に取り組んでいるのかについて固く口を閉ざす傾向があります。 この透明性の欠如は、推測を生みます。 仮のロードマップや、日程が変更される可能性がある場合などでも、なんらかのロードマップがあっても問題ないと思います。

問題は、AWSチームがいかなる種類のETAも出したくないため、開発者が暗闇に置かれていることだと思います。 @normjは、これらのETAに基づいて将来の計画を立ててほしいとは思わないからだと言っています。 ETAは単なる見積もりであり、他の会社の見積もりに基づいて真剣な計画を立てるべきではないという一般的な理解ではありません。たとえそうだとしても、会社はAWSを非難したり、ETAを見逃したことで怒ったりすることはできません。

ETAも特定の日ではありません。 1か月になることもあります。 四半期。 そして、ETAは問題なく、見逃した場合は問題ないはずです。

見つめている
https://docs.aws.amazon.com/lambda/latest/dg/runtime-support-policy.html
AWSは、そのランタイムバージョンのサポートが終了した直後にランタイムを非推奨にしているようです。

.NET Core LTSバージョンは3年間サポートされているため、すでに
「.NETCore3.1ラムダを使用できる時間を費やしています」。
したがって、ラムダで.NET Core3.1を入手するのに入院している人がいることを理解しています。
ところで、私はまた、堅実なリリースを好み、それから何かが急いでいました。

来月か2か月で利用可能になると思いますが、AWSからのコミットメントもあります。
たとえ非常に保守的であっても、チームが業務を計画するのに有益である可能性があります。

もう1つは、このOSSの時代に、.NETコミュニティが役立つかどうかということです。 結局、私たちはgithubで話しているのです。
この「組み込み」ランタイムはいくつかの閉じたコードですか？

また、展開プロセスにReadyToRunおよびその他のAOTコンパイル機能を実行するスイッチがあり、コールドスタート時間が大幅に短縮された場合、それはKILLER機能になります。
これにより、.NETCoreはAWSLambda、IMOで非常に魅力的になります。

@normjとチーム：
AWSで.NETコアを素晴らしいものにしてくれてありがとう

私の考えを追加するだけです。 このリリースがいかに重要であるかを理解しており、ご連絡いただきありがとうございます。 私はそのフィードバックを使用して、私たちの側に緊急性を押し付けます。

この投稿を使用して、緊急性を高めてください。 それを念頭に置いて、ここに私の2つのペニーがあります。

確認するために、それを組み込む作業は、Microsoftが最終リリースを待つのではなく、プレリリースをリリースすると開始されますか？

質問：この質問に対する正直な答えは得られますか？

答えは自明のようです。 .NETの優先順位は「趣味レベル」であり、本来あるべき「企業レベル」ではないように感じます。

1）Net Core全体がオープンソースになっていること、2）実際のリリース時に「着実に実行」できるアーリーアダプタープログラムがいくつか存在することをどこかで聞いたことがあります。 （詳細については、Googleを参照してください。）

私はここで面白いですが、真実は、.NETをフォローしている人は誰でもこれを知っているので、それは私が話す自己証拠に追加されます。

正直なところ、リリースが2.1遅れた後、当時行われた変更により、今回（3.1）頃に、実際のリリースから2週間以内に新しいフレームワークがサポートされることを期待していました。 つまり、リリースから数時間以内が理想的ですが、2週間以内に最後の仕上げ/磨きの余地を与えることは、ほぼ正しいと感じます。

でもここはもうすぐ2ヶ月で「趣味っぽい」感じがします。

@ rati-dzidziguri ETAが必要なことを理解し、感謝しているので、それに応じて計画を立てることができます。 実際には、100％確実に維持できるとは限らないという約束をしないように一生懸命努力しているため、通常はETAを提供しません。

@abukresが非常にエレガントに述べているように、これは「趣味レベル」の考え方です。

問題は、AWSチームがいかなる種類のETAも出したくないため、開発者が暗闇に置かれていることだと思います。 @normjは、これらのETAに基づいて将来の計画を立ててほしいとは思わないからだと言っています。 ETAは単なる見積もりであり、他の会社の見積もりに基づいて真剣な計画を立てるべきではないという一般的な理解ではありません。たとえそうだとしても、会社はAWSを非難したり、ETAを見逃したことで怒ったりすることはできません。

ETAも特定の日ではありません。 1か月になることもあります。 四半期。 そして、ETAは問題なく、見逃した場合は問題ないはずです。

AWSがAzureとのJEDI契約を失ったという事実は、.NETが「エンタープライズレベル」の取り組みであり、そのように扱われるべきであることを証明しているため、いくつかの優先順位付け会議を内部的に開始するのに十分だったはずです。 決定を「訴え」ようとしてリソースを浪費する代わりに、それらのリソースを内部で使用して、.NETコミュニティに愛を与えます。 これを瞬間として使用して、.NETの優先順位を再設定し、次の.NETリリースであるAWSがその上にあり、実行の準備ができていることを自明にします。

@ normj 、 @ martincostello 、およびAWSの残りのワーカー

私は主に、これをAWSが輝く機会を逃したと考えています。 新しいLTSリリースに従うことが優先度が高いと想像してみてください。 それはなんと強力な声明でしょう。

このようなことにより、開発者/アーキテクトは、次のプロジェクトに使用するクラウドを決定する必要があるときに、技術的でない意思決定者に対する議論を失うことになります。 AzureとAWSの両方がほぼ同等のコストと機能を提供している最近では、政治と認識に基づいて意思決定が行われるようになっています。 「公式リリースからX週間/月が経過し、AWSの準備がまだ整っていない」と言われた場合、私は何も持ってきません。

繰り返しになりますが、 @ VagyokC4が言うように、これは実際の作業を行う従業員に対して個人的なものではなく、AWSの上位管理者に対する目覚めの呼びかけです。

.NET Core 3.1 Lambdaを実行しているすべての人は、ILトリミングを有効にすることを検討するかもしれません。 ほとんどの場合、zipファイルのサイズを小さくする予定です。
https://www.hanselman.com/blog/MakingATinyNETCore30EntirelySelfcontainedSingleExecutable.aspx

.NETコアラムダ3.1はRuntimeAPIを使用して構築されていますか？
オープンで、githubで？
いいえの場合、なぜですか？

私が欲しいのは....バレンタインデーはlambda.net core3.1のサポートです

私が欲しいのは....バレンタインデーはlambda.net core3.1のサポートです

正確に舌を転がすわけではありませんが、それは謙虚です：

クリスマスバレンタインデーはあまり欲しくない
必要なものが1つだけあります
プレゼントは気にしない
AWSツリーの下
自分だけで欲しい
あなたが今までに知ることができた以上に
私の願いを叶えましょう
バレンタインデーに欲しいのは.NETCore 3.1 suppooooort ..です。

：ニヤリ：

マイクロソフトは、プレビューサイクルの終わりに向けて、重大な変更を導入しないGoLiveライセンスを含めています。 その時点で、彼らはその次のリリースの本番サポートを提供します。 Go Liveライセンスでリリースされるまで待ってから、ツールの作業を開始することをお勧めします。 .NET Core 3.1では、11/14にリリースされたプレビュー3で提供されました。 この場合、RTMは3週間後の12/3でもありませんでしたが、RTMがヒットし、顧客が期待を高め始めたときに、機能の展開に近づくことになります。

ちょうど私の0.02ドル

私が欲しいのは....バレンタインデーはlambda.net core3.1のサポートです

正確に舌を転がすわけではありませんが、それは謙虚です：

〜クリスマス〜バレンタインデーはあまり欲しくない
必要なものが1つだけあります
プレゼントは気にしない
AWSツリーの下
自分だけで欲しい
あなたが今までに知ることができた以上に
私の願いを叶えましょう
バレンタインデーに欲しいのは.NETCore 3.1 suppooooort ..です。

😁

+1 :)

Lambdaの.NETCore 3.1ランタイムのアップデートはありますか？

私たちは新しいプロジェクトを開始しており、サーバーレスの大部分でLambaを使用することに大きく傾いていましたが、LTSバージョンがサポートされるまでにかかる時間を確認することで、アーキテクチャやプロバイダーを変更する可能性があることを再考しました。

<Rant>
このような機能が30日より長く要求される場合、AWSLambdaランタイムサポートポリシーが約30日ウィンドウで非常に厳格であることは苛立たしいことです。 その後、魔法のようにいつかAWSがこの機能をデプロイし、他のすべての人が.NET Core3.1に切り替えるためにスクランブルをかける必要があります。 これにより、MOST組織は、修正、テスト、および実稼働環境への展開に1か月以上かかることが多いため、悪い状況に置かれます。 私は個人的にこの方針に少しばかり悩まされてきました。 かつて（リソースの制約やその他の優先順位が高いため）、私はこの時期に会社を失ってしまいました。 Lambdaを.NETCore 2.1にアップグレードできるようになったのは、3か月後のことでした。 CloudFrontを使用して特定のラムダをデプロイしようとすると、何か悪いことが起こり（CFログがガベージであるため誰が知っているのか）、ロールバックする必要がありました。 ロールバックするランタイムがなかったことを除いて。 したがって、それはLOCKED展開です。 すぐにチケットを開きました。 24時間後、「スタック全体を削除して最初からやり直す」という最初の応答が返されました。 これは、「削除」操作でDynamoDbテーブルを取得したことを考えると、まったく無知な応答です。 私たちはそのロールバックに2週間半以上閉じ込められました。 最終的には、コンテナテクノロジーを理解し、ロールバックを支援してくれたサポートエンジニアを獲得し、CloudFormationが成功するまで回線を維持しました。 それはうまくいきました、最初の試みに変更はありません。 気性が高すぎて使用できないので、CFが嫌いなのはそのためです。
</Rant>

TL; DR; AWS Lambdaランタイムサポートポリシーは、使用するのが不快であり、お湯に浸かることがあります。
https://docs.aws.amazon.com/lambda/latest/dg/runtime-support-policy.html

@CraigHeadごCore2.1ランタイムは少なくとも2021年8月21日までLambdaでサポートされます。 2.1関数を3.1に変換するために急ぐ必要はありません。 以前の経験は、Lambdaに入る唯一の非LTSバージョンであったため、Lambdaの異常であった.NET Core2.0であったと思います。 これは、.NET Core1.0のいくつかの大きな問題が原因でのみ発生しました。

はい、それは.NET Core2.0から.NETCore2.1への移行でした。 暴言について申し訳ありません。 30日は私たちの中にはちょっと厳しいです。 全体の長さを見ると、ラムダは大幅なメンテナンスや追加のQAなしで実行できる可能性があります。

一方、これはサーバーレスのAzure側で発生しています
https://visualstudiomagazine.com/articles/2020/01/30/azure-functions-3-0-runtime.aspx

その間、AWSチームはそれに取り組んでいます。 卑劣なコメントは役に立たない
彼ら。 準備ができたら、この問題を更新します。

18：22時火曜、2020年2月11日には、ラティDzidziguri [email protected]
書きました：

一方、これはサーバーレスの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=AAAZVJXAAYET4F7PFFOTO3LRCLUETA5CNFSM4JU5UTJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AAAZVJQK3NBVXBZALM4V5KLRCLUETANCNFSM4JU5UTJA
。

私のポイントは、卑劣なコメントをすることではなく、MSでさえ最近3.1のGAの可用性を発表したことを指摘することでした。したがって、AWSが3.1サポートに関する作業をまもなく完了することを期待しています。
。

一方、これはサーバーレスのAzure側で発生しています
https://visualstudiomagazine.com/articles/2020/01/30/azure-functions-3-0-runtime.aspx

MS言語を考えると、AzureがAWSを打ち負かしてこれをサポートするのは当然のことです。

このスレッドを注意深く見てください-私のC＃ラムダをアップグレードするのを楽しみにしています。

dotnet core3.1.0がリリースされました2019-12-03
https://dotnet.microsoft.com/download/dotnet-core/3.1

2020-01-23にAzureで利用可能になりました
https://azure.microsoft.com/en-us/updates/azure-functions-runtime-30-is-now-available/

Azureと比較して1か月足りません

ところで、すべての.NETコア開発はgithubのオープンで行われます
したがって、「MS言語」であることはあまり効果がないはずです。
または、dotnetを使用するAWSクライアントがAzure：Pで優れていることを提案しますか？

とにかく、AWSで聞いている人には：
Lambdaで3.1を待っている私たちがいます。それは私たちにとって重要です。

ところで、すべての.NETコア開発はgithubのオープンで行われます
したがって、「MS言語」であることはあまり効果がないはずです。
または、dotnetを使用するAWSクライアントがAzure：Pで優れていることを提案しますか？

つまり、Microsoftのクラウドプラットフォームが自国語の新機能をサポートしないのは少し恥ずかしいことです。 正直、1ヶ月半強かかってびっくり！ もう少し内部通信を行うことで、両方を同時にリリースできたはずです。

AWSは、.Netサポート、特にCloudWatch + ILoggingなどのサービスにフックする開発パッケージとSSMパラメーター構成の連携でうまく機能していると思います。これは非常に役立ちました。

しかし、3.1リリースがすぐに見られることを願っています:)

ILoggerより良いCloudwatchの具体的な実装があったらいいのにと思います。 Lambda SDKを使用する場合、これはServiceCollection / ServiceProviderに統合する方が適切です。 リクエストコンテキストと静的LambdaLoggerクラスで提供されている現在のバージョンでは、ログ出力の単体テスト/検証が基本的に不可能であり、デフォルトの.netcore ConsoleLogProviderをフックするとCloudwatchログが乱雑になります。

ILoggerより良いCloudwatchの具体的な実装があったらいいのにと思います。

https://github.com/aws/aws-logging-dotnet#aspnet -core-loggingを試しましたか？

ログを@CraigHeadのように見せたいですか？

過去にSerilogとhttps://github.com/structured-log/structured-logを使用して、Seqにインポートされた素敵なコンソールログとJSONベースのログを出力しました。 https://datalust.co/これは、中央ログを非常に優れた形式で取得するための最良の方法でした。

@CraigHead Amazon.Lambda.Logging.AspNetCoreは、LambdaのロギングをIServiceCollectionに統合するための実装です。 そのライブラリはあなたのために機能しませんか？

Lambdaのttps：//github.com/aws/aws-logging-dotnet#aspnet-core-loggingのAWS.Logger.AspNetCoreパッケージはお勧めしません。 そのライブラリは、バックグラウンドスレッドを使用してログをCloudWatchLogsにプッシュします。 このようなバックグラウンドスレッドを使用すると、Lambdaではうまく機能しません。Lambdaは、関数ハンドラーが戻るとすぐにLambdaコンピューティング環境をフリーズします。つまり、バックグラウンドスレッドがキューに入れられたメッセージをフラッシュする機会がない可能性があります。

私はこれについて知りませんでした。 ヒントありがとうございます！
SDKでAmazon.Lambda.Core.LambdaLoggerを
私は間違いなくそのパッケージ（ Amazon.Lambda.Logging.AspNetCore ）をチェックアウトします。

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

@clearwaterstream
ラムダランドAFAIKには、現在のインスタンスが処理を停止するか終了することを通知するイベントがないため、提案ではバッファリングされたログイベントがフラッシュされない（失われる）ままになります。

他のニーズのためにこのスレッドを乗っ取らないでください。
このスレッドは、AWSLambda上の.NETCore3.1が利用可能になる時期に関する情報を提供するために作成されました。
そして、AWSに私たちがそこにいて待っていることを知らせるために。

ラムダテストツールは3.1リリースに含まれますか？ https://github.com/aws/aws-lambda-dotnet/tree/master/Tools/LambdaTestTool

それが私の意図です。 作業はmock-testtool-31で進行中です。 3.1ブランチの大きな改善点は、ユーザーのLambdaコードが別のAssemblyLoadContextで実行されるようになったことです。これにより、ユーザーが現在のバージョンと持っていたバージョンの競合の多くが修正されます。 AssemblyLoadContext機能を2.1バージョンにバックポートすることを検討しています。

補足として。 必要最低限​​のUIをサーバー側のBlazorアプリに変換することについて議論しています。 Blazorの経験が豊富な人は、それが良いアイデアか悪いアイデアかについてフィードバックを持っていますか？

補足として。 必要最低限​​のUIをサーバー側のBlazorアプリに変換することについて議論しています。 Blazorの経験が豊富な人は、それが良いアイデアか悪いアイデアかについてフィードバックを持っていますか？

この時点でBlazorを使用することは、特にDotNetを使用している私たちにとっては良い考えです。

「ベアボーンUI」-これは、.NET Core 3.1 Lambdasに接続されていない他のアプリですか？
ところで、私はブレイザーをまったく気にしません

@petarrepacこれは、.NET Core AWS.NET MockLambdaテストツールを参照していました。 これが参照用の投稿ですhttps://aws.amazon.com/blogs/developer/debugging-net-core-aws-lambda-functions-using-the-aws-net-mock-lambda-test-tool/

.NET Core3.1のツールを更新中です。

@normj
ああ、わかりませんでした、ありがとう
そのようなツールは必要なかったというのは興味深い考えです

私たちの観点からすると、ラムダは、ロ​​ーカルで呼び出してローカルでテストできるベアボーンAspNetCoreHttpApiです。
唯一の違いは、50行未満のコードであるエントリポイントファイル/クラスです。
また、AWSにデプロイした場合にのみ、適切にテストできるものがたくさんあります。

• 権限
• 受信したJSONイベントの形状とコンテキスト
• ..。
  したがって、次の組み合わせ：
• ローカルで実行される優れたユニット/統合テスト
• ローカルhttpテスト
• AWS環境をテストするために簡単にデプロイできます
  遠くまで行くことができます

または私はいくつかの明白なシナリオを逃していますか？

@petarrepac ASP.NET Coreブリッジを使用する大きな利点の1つは、ローカルでの実行が非常に簡単なことです。 ベストプラクティスはユニット/統合テストを使用することであることに同意しますが、アプリケーションロジックの迅速なアドホックテストが必要になることが多く、それがこのツールに適しています。

@normjありがとうございます。 Blazorに関しては、いい感じかもしれません。 私たちのチームのユースケースでは、少なくともそれは十分に活用されていないでしょう。

ペイロードを送信するのに十分な長さのUIにいるだけで、VSのコードをステップスルーします。

Lambda Bootstrapperとカスタムランタイム機能を使用すると、1つのコードベースから複数のラムダ関数を確実に実現できます。

「モノリス」ではなく、1つのアプリケーションからデプロイされる16個のラムダのスイートがあります。

これは、ブログ投稿のサンプルコードに示されているハードコードされた1対1のマッピングではなく、 _handler環境変数を使用して実行時に使用するメソッドを選択することで実現されます。

起動時に「なる」アクションを指示するスイッチを受け取るコンソールアプリだと思います。

@martincostello

あなたの説明に基づいて、これをうまくやってのけるのに苦労しています。 Functions.csに約20個のLambda関数があり、serverless.templateの対応する定義に関連付けられています。 呼び出す関数を示すために、各定義で環境変数を渡すことになると思います。 これらの関数のほとんどは署名です：

public APIGatewayProxyResponse ThisLambdaFunction（APIGatewayProxyRequestリクエスト、ILambdaContextコンテキスト）
{{

異なる引数（APIGatewayProxyRequest以外）と異なる戻り値を受け取る他の関数がある場合、異なるラムダ関数シグネチャのサポートを追加するにはどうすればよいですか？

糸を狂わせないでください。

@twopointzero .NET Core3.1カスタムランタイムプロジェクトを使用して複数のラムダ関数を実行するためのソリューションをGoogleが検索するのに何日も費やしました。 インターネット上にこれ以上関連するスレッドはありません。私の問題の解決策があるという希望を垣間見せてくれた既存の投稿に返信しています。

AWSでネイティブの.NETCore 3.1をサポートしていないと、生活が困難になります。 最新のEntityFrameworeCore 3.1.2にアップグレードするには、3.1にアップグレードする必要があります。これにより、Aurora（PostgresSQL）の接続プールで発生している問題が修正されます。

@normj私はETAなしのスタンスを完全に理解していますが、私たちが近いかどうか教えていただけますか？ <30日？

@antsaiaに関して、あなたのコメントは、

このスレッドを自分で狂わせないように、これがこの問題に関する私の最後のコメントです。

@normj .netコア3.1サポートの実装のステータスに関する情報を入手できるリソース（ブログ、フォーラムなど）はありますか？

私は毎日このページにアクセスして新しい情報を入手したいと思っていますが、明らかに十分な情報がありません（その使用を目的としていないため）。 ある種の基本的な更新があれば、事前に計画を立てることができるので、はるかに簡単になります。

ここにある多くの場合と同様に、機能を提供するための計画は、3.1を使用できるかどうか、または2.1を使用して開発する必要があるかどうかに大きく依存します。 私の場合、3.1はSystem.Drawのサポートを提供し、これは私が取り組む機能に大きな影響を与えます。

私が欲しいのは....聖パトリックの日はラムダ.netコア3.1のサポートです

@リアム-セージ私は見つけることができるすべては、それがQ1 2020年には準備ができてしまう表すアマゾンのフォーラムでいくつかの記事であったhttps://forums.aws.amazon.com/thread.jspa?threadID=313806

@リアム-セージ私は見つけることができるすべては、それがQ1 2020年には準備ができてしまう表すアマゾンのフォーラムでいくつかの記事であったhttps://forums.aws.amazon.com/thread.jspa?threadID=313806

これは、3月に公開する必要があることを意味します。 お待ちしております。

こんにちは、私はそれが完全に適切ではないことを知っていますが、あなたはあなた自身のラムダをdotnetcore3.1にアップデートすることができます。 それまでの間、独自のdotnetcoreテンプレートを作成するためにラムダをたくさん作成することをお勧めします。 私は自分でそれをしました。 ボイラープレートコードで時間を無駄にする必要がないことを確認したかったのです。 テンプレートの例はここにあります。

そしてヴィンセント、どうやってそこでホストするの？ カスタムランタイムを使用していますか？
2020年3月5日木曜日午後7時40分Vincentvan der Walt <
[email protected]>は次のように書いています：

こんにちは、私はそれが完全に適切ではないことを知っていますが、あなたはあなた自身のラムダを手に入れることができます
dotnetcore3.1に更新されました。 その間、あなたが待っている間、私は提案します
独自の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=AGIDH4OWUT7Y3HR3O5KARBDRF62V3A5CNFSM4JU5UTJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKT
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AGIDH4PLKFSDLNBX2QVMG63RF62V3ANCNFSM4JU5UTJA
。

はい、カスタムランタイムを利用します。

マシン上でローカルに実行することも、awsにデプロイすることもできます。

ローカルの場合はF5、awsへのデプロイの場合はdotnet lambda deploy-serverless

readmeは、テンプレートをローカルマシンにインストールする方法を説明しています（これはdotnetcoreテンプレートです）。

カスタムランタイムはかっこいいですが、ラムダが本番環境で使用するための.Net Core3.1の完全なAWSサポートをまだ待っています😄

受信トレイにこれが表示されるたびに、
少なくとも少しずれている投稿を見つけるためだけに何かを発表しました
トピック。 他の誰かが他の人にスレッドを乗っ取らないように頼みましたが、それはしませんでした
働いた。 誰かがアナウンスする準備ができるまで、誰かがスレッドをロックできますか？
3.1サポートのリリース？

7:13 bartoszsiekanskiで金、2020年3月6日には[email protected]
書きました：

カスタムランタイムはかっこいいですが、AWSの完全なサポートをまだ待っています
ラムダが本番環境で使用するための.NetCore3.1の場合😄

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/aws/aws-lambda-dotnet/issues/554?email_source=notifications&email_token=AAVUT3SNDR4L2ZL5J4KQYDDRGDSHBA5CNFSM4JU5UTJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKT
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AAVUT3TBH3NIBMGB54EFCR3RGDSHBANCNFSM4JU5UTJA
。

.NET Core 3.1のサポートについて説明する以外の場合は、別の問題を作成してください。 @normjのニュースが増えるまで、この問題を解決できますか？

@ hounddog22030スレッドを「ハイジャック」していることに気づきませんでした。 私は、準備ができているかどうかを常に尋ねるのではなく、人々がdotnetcore3.1への移行を切望している場合は別のアプローチがあることを提案していました。 公式の非カスタムランタイムサポートは、準備ができたら準備が整います。 人々はもう少し辛抱強くなるか、別のアプローチを模索する必要があります。

AWSがdotnetlambda packageコマンドで--self-containedオプションをサポートしている場合、ラムダ関数はSDKのバージョンに関係なく実行可能である必要があります。 右？ すべての.NETCoreリリースのサポートを追加する代わりに、それを実行しないのはなぜですか？

AWSがdotnetlambda packageコマンドで--self-containedオプションをサポートしている場合、ラムダ関数はSDKのバージョンに関係なく実行可能である必要があります。 右？ すべての.NETCoreリリースのサポートを追加する代わりに、それを実行しないのはなぜですか？

ラムダカスタムランタイム機能について説明しました

@aussiearefこれは確かにうまく機能しますが、自己完結型のパッケージには.Net Core自体が含まれています。これは通常、Webサイトに少なくとも40MB（zip形式）で追加され、アプリケーションと依存関係自体のためのスペースがあまりありません。

同じバージョンの.NETCoreを使用する場合、カスタムランタイムもネイティブランタイムよりも遅くなります（コールドスタート）。 3.1ではパフォーマンスが大幅に向上するため、完全に最適化された3.1カスタムとネイティブの2.1の間で同じレベルのパフォーマンスを期待できます。 3.1ネイティブが大幅な改善をもたらすことを期待しています。

Q1は4日で終了しますが、ラムダで3.1が表示されないようです。
チームのすべてのメンバーがこのパンデミックの時期に安全であり、第2四半期にこのリリースが見られることを願っています。

あと数日残っているという希望をあきらめないでください！ 私たちは皆、最終的な展開やその他の土壇場での活動を待っていることにほぼ包まれています。 私たちは皆ソフトウェアを知っており、ぎりぎりの問題が発生する可能性があることを忘れないでください。

私は実際に、ランタイムが開いたらすべてが利用可能であることを確認するために、新しいクライアントツールの更新のロールアウトをすぐに開始することを計画しています。 したがって、新しいNuGetパッケージの更新が送信された場合は、ランタイムが存在するとは限りません。 ブログの投稿が出るまで待ってください。ここに更新を投稿します。

それは素晴らしいニュースです。 ありがとう@normj

ブログ投稿とリリースを楽しみにしています。

あと数日残っているという希望をあきらめないでください！ 私たちは皆、最終的な展開やその他の土壇場での活動を待っていることにほぼ包まれています。 私たちは皆ソフトウェアを知っており、ぎりぎりの問題が発生する可能性があることを忘れないでください。

私は実際に、ランタイムが開いたらすべてが利用可能であることを確認するために、新しいクライアントツールの更新のロールアウトをすぐに開始することを計画しています。 したがって、新しいNuGetパッケージの更新が送信された場合は、ランタイムが存在するとは限りません。 ブログの投稿が出るまで待ってください。ここに更新を投稿します。

このスレッドの態度に直面したあなたの忍耐は印象的ではありません。 これに取り組んでくれてありがとう！

@normjは、公開前に実行したいテストを喜んでサポートします;）

あと2日で、指が交差しました。

そして、四半期の残り時間は13時間です😅

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

ご理解のほどよろしくお願いいたします。 @raRaRaこの号を閉じることを光栄に思います。

素晴らしい

2020年3月31日火曜日、20：06 Norm Johanson、 notifications @ github.comは次のように書いています。

そして、四半期の残り時間は13時間です😅

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

ご理解のほどよろしくお願いいたします。 @raRaRa https://github.com/raRaRa
この号を閉じることを光栄に思います。

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/aws/aws-lambda-dotnet/issues/554#issuecomment-606785798 、
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AGUX3OUR6LN5CERIBTDHXP3RKIWLVANCNFSM4JU5UTJA
。

ありがとうございました！！！！

そして....購読解除:-)

関係者全員に感謝します!!!

ありがとう！

そして、四半期の残り時間は13時間です😅

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

ご理解のほどよろしくお願いいたします。 @raRaRaこの号を閉じることを光栄に思います。

よくやった！

それがAWSベイビーです。 それがAWSです!!!
何が起こっても、結局、彼らはそれを成し遂げます。

どうもありがとう、チーム!!!

素晴らしいニュースとありがとう@ raRaRa @ normj !!! 愚かで貪欲に聞こえるリスクがありますが、これは本質的にPowershell 7も意味しますか？ もう一度確認するだけです......

@normjとAWSの皆さん、

下にスクロールする人のためのブログへのリンクは次のとおりです
https://aws.amazon.com/blogs/compute/announcing-aws-lambda-supports-for-net-core-3-1/

素晴らしい、dotnet core3.1にサポートを追加してくれてありがとう!!!

@andyKalmanまだPowerShell7を使用していません。AWSLambdaPSCoreモジュールで最終的な修正を行ってから、リリースされたAWSLambdaPSCoreの2.0.0バージョンをギャラリーに取得します。

迅速な返信@normjに感謝します。 事後に＃607を見たので、すぐにフォローアップできるように見えました。 ここでコメントを停止できるように追跡する別の問題はありますか？ ：） 再度、感謝します。

おめでとうございます！
そして、AWSと.NETチームに感謝します！
とても有難い。

これを実現するのを手伝ってくれたすべての人に感謝します！ これは巨大なリリースであり、多くのハードワークがそれに費やされたことを示しています！ 良い！ 🎉🥳

ありがとう ！！ ：拍手：：拍手：：多田：：多田：

皆さん、おめでとうございます。アップグレードを楽しみにしています。

ありがとう！

これらのラムダをアップグレードすることに熱心な素晴らしい仕事。

すごい仕事！ あなた@normj👏👏ありがとう

素晴らしい作業チーム！

dotnet 3.1 Async Streams + AWS AppSync / GraphQLサブスクリプションでLambdaワーカーに飛びつきたがっています。
AWSチーム、どうもありがとうございました！

OMG、あなたが支配する人たち！ すばらしい！ ウーフー！ 😄😄😄

ありがとう！

@andyKalman PowerShell 7を使用するAWSLambdaPSCoreモジュールのバージョン2.0.0をプッシュしました。PS7サポートに関するブログ投稿を公開する予定ですが、既存のPowerShell6サポートが7を使用するのと同じように機能します。

@andyKalman PowerShell 7を使用するAWSLambdaPSCoreモジュールのバージョン2.0.0をプッシュしました。PS7サポートに関するブログ投稿を公開する予定ですが、既存のPowerShell6サポートが7を使用するのと同じように機能します。

新しいバージョンのAWSLambdaPSCoreは、新しいバージョンで公開した場合、既存のLambda関数内の構成を更新しますか？ それはdotnet3.1とps7に向けられるのでしょうか？

@ tr33squidはい、2.0.0でデプロイすると、.NET Core3.1およびPS7が使用されます。

AWSチームの素晴らしい仕事に感謝します!!

皆さんこんにちは、

私はLambdaで.NETCore3.1のサポートを提供することに積極的に取り組んでいます。 ランタイムの構築方法についてMicrosoftが多くの作業を行ったため、時間がかかります。 これらの変更を組み込んで、ネイティブランタイムを提供するよう取り組んでいます。

AWS-Lambda.NETコアチームに感謝します

やあ、
AWS-Lambdaを実行しようとすると、このエラーが発生します
互換性のあるフレームワークバージョンを見つけることができませんでした。
指定されたフレームワーク「Microsoft.AspNetCore.App」、バージョン「3.1.0」が見つかりませんでした。
助言がありますか ？？

やあ、
AWS-Lambdaを実行しようとすると、このエラーが発生します
互換性のあるフレームワークバージョンを見つけることができませんでした。
指定されたフレームワーク「Microsoft.AspNetCore.App」、バージョン「3.1.0」が見つかりませんでした。
助言がありますか ？？

3.1.0SDKをインストールする必要があります。

Microsoft.AspNetCore.Appをプロジェクトから削除する必要があると思います
依存関係、Core 3.1.0にはもう必要ないので、削除する必要がありました。
2.1からアップグレードしたサービスをビルドしてデプロイします。

金曜、午前3時24分AMグレゴリー・リヨンで2020年4月24日には[email protected]
書きました：

やあ、
AWS-Lambdaを実行しようとすると、このエラーが発生します
互換性のあるフレームワークバージョンを見つけることができませんでした。
指定されたフレームワーク「Microsoft.AspNetCore.App」、バージョン「3.1.0」は
見つかりません。
助言がありますか ？？

3.1.0SDKをインストールする必要があります。

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/aws/aws-lambda-dotnet/issues/554#issuecomment-618850277 、
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AMSHCOLW5WJDS7CCAFDMP4TROE5ENANCNFSM4JU5UTJA
。

-
一番、
ジョージ

ジョージ・タスコス
シニアソリューションアーキテクト

WeAre8
230パークアベニュー、3階西
ニューヨーク州ニューヨーク10169
（917）717-9067
weare8.com

専用エントランス、
71ヴァンダービルトアベニュー
3階

Microsoft.AspNetCore.Appはプロジェクトの依存関係から削除する必要があり、Core 3.1.0では不要になったと思います。2.1からアップグレードしたサービスをビルドして展開するには、Microsoft.AspNetCore.Appを削除する必要がありました。
…
2020年4月24日金曜日午前3時24分グレゴリーライオンズ@ 。 * >書き込み：こんにちは、AWS-Lambdaを実行しようとすると、このエラーが発生します。互換性のあるフレームワークバージョンを見つけることができませんでした。 指定されたフレームワーク「Microsoft.AspNetCore.App」、バージョン「3.1.0」が見つかりませんでした。 助言がありますか ？？ 3.1.0SDKをインストールする必要があります。 —このスレッドにサブスクライブしているため、これを受け取っています。 このメールに直接返信するか、GitHub < ＃554（コメント） >で表示するか、 https：//github.com/notifications/unsubscribe-auth/AMSHCOLW5WJDS7CCAFDMP4TROE5ENANCNFSM4JU5UTJAの登録を解除して
-ベスト、ジョージジョージタスコスシニアソリューションアーキテクトWeAre8 230パークアベニュー、3階。 ニューヨーク州ウェストニューヨーク10169（917）717-9067 weare8.com専用エントランス、71ヴァンダービルトアベニュー3階

お返事をありがとうございます、
実際、このエラーは私のばかげた間違いによるものでした。 serverless.ymlのランタイム：dotnetcore2.1を削除するのを忘れました。 問題が解決しました。

誰かがこれについて更新されたベンチマーク/比較をしますか？ 私が見つけることができるのは、カスタムランタイムを備えた古いものだけです。

誰かがこれについて更新されたベンチマーク/比較をしますか？ 私が見つけることができるのは、カスタムランタイムを備えた古いものだけです。

これは良いものです。
https://medium.com/@zaccharles/a -close-look-at-net-core-3-1-on-aws-lambda-9ccec4dd96be

また、512mbのラムダサイズで2.1の複雑なラムダを3.1に更新した私の個人的な経験では、ほぼ同じパフォーマンス（コールドスタートとウォームスタート）が見られました。 2.1ラムダと3.1ラムダはどちらも、ラムダレイヤー、最適化された公開、newtonsoft（3.1のMicrosoft jsonでパフォーマンスが向上する可能性があります）、階層型コンパイルオフ、および3.1のRTRを使用します。

私のメトリックからは、dotnet 3.1ランタイムでわずかなパフォーマンスが得られるようですが、Amazon Linux2およびdotnet3.1の初期化ではパフォーマンスが低下します。 （2.1はAmazon Linux 1を使用します。）作成は洗浄効果があります。