aws-lambda-dotnet 🚀 - .NET Core 3.1 (LTS) 已经发布

它是一个 LTS，将得到支持。将 .NET Core 3.1 准备好用于 Lambda 并进行部署需要一些时间。

normj 于 2019-12-03

👍53 ❤9 🎉2 🚀1

它是一个 LTS，将得到支持。将 .NET Core 3.1 准备好用于 Lambda 并进行部署需要一些时间。

如果有什么我可以帮忙的，请告诉我。

hounddog22030 于 2019-12-04

冷启动时间会有加速吗？

.NET Core 3.1 有一些特性，比如 AOT 编译

发布准备运行
发布修剪

ckuetbach 于 2019-12-04

👀15 👍7 ❤2

@normj人们应该订阅此问题以获取更新，还是我们应该关注另一个 .NET Core 3.1 问题以取得进展？

beeradmoore 于 2019-12-04

👍4

我们可以使用此问题来跟踪更新。不幸的是，在它出来之前，我可能无法提供很多状态更新。

normj 于 2019-12-08

👍11

冷启动时间会有加速吗？
.NET Core 3.1 有一些特性，比如 AOT 编译
发布准备运行
发布修剪

如果评论的答案是肯定的，是否可以从本地环境运行和测试“编译的 lambda”？我会急切地为它设置一个 linux 环境:)

daseintheworld 于 2019-12-12

这里有更新吗？

rati-dzidziguri 于 2019-12-13

@rati-dzidziguri

如上来自@normj

我们可以使用此问题来跟踪更新。不幸的是，在它出来之前，我可能无法提供很多状态更新。

beeradmoore 于 2019-12-13

@比拉德摩尔
我的问题是关于 ETA。这将有助于了解 ETA，因为我们可以进行相应的准备。

rati-dzidziguri 于 2019-12-13

@rati-dzidziguri 亚马逊很少在发布时透露他们的预计到达时间。

Kralizek 于 2019-12-13

@rati-dzidziguri 我理解并感谢您想要一个预计到达时间，以便您可以做出相应的计划。实际上正是出于这个原因，我们通常不会给出预计到达时间，因为我们非常努力地不做出我们不能 100% 确定我们可以兑现的承诺。我不想给你一个预计到达时间，你根据它制定你的路线图，然后我想念你期望将所有计划打乱的预计到达时间。

现在，如果您确实需要 .NET Core 3.1 功能，那么我建议将 .NET Core 3.1 用作 Lambda 自定义运行时，此处对此进行了说明（从 .NET Core 3.0 到 .NET Core 3.1 的更改引用除外）。然后，当原生 .NET Core 3.1 支持出现时，您将有一个非常简单的迁移，即更改 Lambda 函数上的一些设置。

normj 于 2019-12-13

👍9

@normj让我决定不能将自定义运行时功能与“LambdaEntry”类一起使用的一个原因是实现方法的“单体架构”方面。每个 API 请求都通过唯一的一个入口 lambda 并“分发”到 ASP .net 项目的控制器，这是自定义运行时结构的意图，这绝对方便，但包括像我想要的情况的结构缺点。我希望每个命令/查询请求都变成 lambda。从那时起，我可以获得管理部署包的可扩展性，我可以随时拆分一些功能和管理代码。
这就是为什么我在等待官方运行时得到支持，我可以使用在模板中编写的 SAM 构建一组“单一用途的 lambdas”，其中包含“运行时：.netcore 3.1”配置。

如果我出错了，请给我建议:)

daseintheworld 于 2019-12-15

👍1

您绝对可以使用 Lambda Bootstrapper 和自定义运行时功能从一个代码库实现多个 lambda 函数。

我有一套 16 个 lambda 表达式，它们是从一个应用程序而不是“单体”部署的。

这是通过使用_handler环境变量来选择在运行时使用的方法来实现的，而不是博客文章示例代码中显示的硬编码一对一映射。

我认为它是一个控制台应用程序，它接收一个开关，告诉它在启动时“变成”什么动作。

martincostello 于 2019-12-15

👍6

@martincostello
谢谢你的好建议！我可以弄清楚你的情况可能是什么样子。您可能已将开关逻辑放置在 Main 或 Startup 类中，以便在运行时的第一阶段确定它的功能。当然，它可以解决“唯一的单体”问题。非常聪明的方法:)

但是，我必须考虑一个（如果不是很多）考虑因素，尤其是当我想象作为一个团队工作时。使用自定义运行时并在启动时确定“功能标识”将消除 SAM 的可能性。举个简单的例子，在部署 lambda 时不能定义 API 网关，这意味着我们必须为它手动生成一个。
我知道我在这里夸大其词，因为我们可以使用aws 教程解释的引导脚本进行类似 SAM 的配置。但它不会完全满足我们，因为它使用的是 linux 脚本，这意味着
(1) 对于新人来说可能会很尴尬，有时会成为学习曲线。
(2) 它将放弃无服务器模板的表达能力的好处，因为它实际上是一个脚本，而不是一个文档。

我认为无服务器模板可以作为服务器外观及其工作方式的半文档，它不仅会在开发团队内共享，甚至会与一些有见地的非技术人员共享。 SAM 是一个定义明确的概念，在不久的将来，一个应用程序的抽象表示将使另一个使用完全不同语言和平台的团队重用成为可能。不可否认，这些方面仍然激励我坚持使用“无服务器模板”功能。

daseintheworld 于 2019-12-15

👍3

一些不错的发布日期，12 月 25 日，1 月 1 日浮现在脑海中；)

CumpsD 于 2019-12-20

😄1

祝大家节日快乐，我希望我能在圣诞节为您提供所有 .NET Core 3.1 Lambda 运行时，但我认为 2020 年对于 .NET 和 AWS 来说将是令人兴奋的。

normj 于 2019-12-22

👍36 🚀5 🎉1

祝大家节日快乐，我希望我能在圣诞节为您提供所有 .NET Core 3.1 Lambda 运行时，但我认为 2020 年对于 .NET 和 AWS 来说将是令人兴奋的。

不用担心，享受假期！迫不及待想看看您在 2020 年为我们准备了什么！ :)

raRaRa 于 2019-12-22

等待 .NetCore3.1 上的 lambda 原生支持

neetika123 于 2020-01-07

👍93

lambda 函数有磁盘大小限制。我认为它是 250 megs，当使用自定义运行时，我们必须将所有 asp.net 核心程序集与我们的应用程序一起发送。当 AWS 解压缩我的 zip 包时，我达到了这个限制。我不得不进行一些清理以减少我的应用程序使用的空间。当本机支持出现时，我们不必将我们的应用程序与 .core 的程序集打包在一起。

abukres 于 2020-01-23

有没有估计什么时候可以发布？

我们正在等待升级到 .Net core 3.1，直到对它的原生支持。

erikdac 于 2020-01-23

👍17 ❤1

有没有估计什么时候可以发布？
我们正在等待升级到 .Net core 3.1，直到对它的原生支持。

如果你回去阅读回复，你会从 normj 中读到他们不会给出任何估计。

abukres 于 2020-01-23

👍2

如果你回去阅读回复，你会从 normj 中读到他们不会给出任何估计。

嗯，通常 - 是的。但是，如果有足够多的人拿着音叉出现，那么也许会给出发布日期的暗示以平息骚乱：grin：

clearwaterstream 于 2020-01-23

👎8 👍7

我记得不久前，AWS 花了很长时间准备 2.1 原生映像。他们说了一些大意是他们重新设计了流程，以使部署未来版本更容易、更快地站起来。进入 NetCore 3.1，差不多两个月后，它仍然不可用:(

你知道 Azure 在第一天就提供了这个 3.1 映像。我开始明白为什么美国政府选择 Azure 作为他们的 JEDI 云提供商。

我们刚刚获得利益相关者的批准，开始将 Azure 作为我们的主要供应商，而将 AWS 作为备份。像这样愚蠢的延迟，我敢肯定我们不是唯一的。

VagyokC4 于 2020-01-23

👍5 😕4

我记得不久前，AWS 花了很长时间准备 2.1 原生映像。他们说了一些大意是他们重新设计了流程，以使部署未来版本更容易、更快地站起来。进入 NetCore 3.1，差不多两个月后，它仍然不可用:(
你知道 Azure 在第一天就提供了这个 3.1 映像。我开始明白为什么美国政府选择 Azure 作为他们的 JEDI 云提供商。
我们刚刚获得利益相关者的批准，开始将 Azure 作为我们的主要供应商，而将 AWS 作为备份。像这样愚蠢的延迟，我敢肯定我们不是唯一的。

我同意你的看法。我的组织不允许自定义运行时，我们有点卡在 2.1 上。说到EF&Postgres加上空间操作，实在是太痛苦了。我们一直在等待这件事完成。太糟糕了，它还没有完成。

Rajaniyer 于 2020-01-23

我记得不久前，AWS 花了很长时间准备 2.1 原生映像。他们说了一些大意是他们重新设计了流程，以使部署未来版本更容易、更快地站起来。进入 NetCore 3.1，差不多两个月后，它仍然不可用:(
你知道 Azure 在第一天就提供了这个 3.1 映像。我开始明白为什么美国政府选择 Azure 作为他们的 JEDI 云提供商。
我们刚刚获得利益相关者的批准，开始将 Azure 作为我们的主要供应商，而将 AWS 作为备份。像这样愚蠢的延迟，我敢肯定我们不是唯一的。

JEDI 是否使用 .NET Core 来做出政府选择 Azure 的假设？

abukres 于 2020-01-23

😄1

嗨，大家好，

我正在积极致力于在 Lambda 中引入对 .NET Core 3.1 的支持。这需要一些时间，因为 Microsoft 在构建运行时方面做了大量工作。我正在努力合并这些更改，以便为您带来本机运行时。

assyadh 于 2020-01-23

👍38 ❤9 🚀4 🎉3

@assyadh谢谢！我不相信延迟是“愚蠢的”；事实上，我宁愿等待一个可靠的工作版本。我喜欢 AWS Lambda 支持 .NET Core，我很感激您按照承诺继续支持它。

JamesQMurphy 于 2020-01-24

👍5

我不明白那种冲动。并不是说我们现在没有 LTS 环境。

显然，我们想使用新玩具，但 AWS 的 .NET 团队只有固定数量的资源，他们不能同时做所有事情。

此外，我并不渴望因为担心超出服务条款而匆忙更新所有函数的运行时间。

Kralizek 于 2020-01-24

👎15 👍3

对你有好处@Kralizek但你的情况是你的，不代表其他人。现在它不是真正的“新玩具”，对吧。 .NET Core 3.x（和 ASP.NET Core）在各种方面比 2.x 有了显着改进，早期采用者热衷于采用和利用。正如@JamesQMurphy所说，我们也希望发布是可靠的。

我期待看到你的作品@assyadh。

damianh 于 2020-01-24

👍5 👎1

“我不明白那种冲动。”
我们不能在 .NET Core 2.1 lambda 函数中使用共享的 .NET Core 3.1，事实上我们甚至不能在 .NET Core 2.1 lambda 函数中使用共享的 .NET Core 2.2 代码，所以我们最近不得不不情愿地降级我们的将组件共享到 .NET Core 2.1 以使其在函数中受支持。

你的共享组件可以在netstandard20中编译吗？然后你可以在netcore2&3中分享它们

hounddog22030 于 2020-01-24

👍3

虽然此线程特定于 .NET 3.1，但我确信当 .NET 5 到来时（如果将是下一个 LTS，则为 6），这个确切的对话将再次上演。

虽然已经引用了一些不可能实现的具体示例（例如代码 ZIP 文件太大、公司政策），但_一般_如果您想使用“最新最好的”.NET Core，您可以使用很少重构和自定义运行时支持包。

在这个时候，我们刚好处于最新版本_也恰好_是 LTS 版本的地步，这似乎使得从亚马逊“尽快”获得它的需求似乎比它更“紧迫”，比如说，有内置的 2.2 或 3.0 支持。

最终，需要在 Lambda 上可用的新功能与 PaaS 解决方案所需的开发工作之间进行权衡。

.NET Core 3.1 在发布后的 2-3 周内甚至无法在 Microsoft 的 Azure 应用服务上使用。

如果您通常希望尽快处于“流血边缘”，那么在短期内对使用自定义运行时支持进行少量投资将使您有可能在自己的时间范围内在 Lambda 中运行任何未来版本的 .NET Core。当然，这里的权衡是更大的包、稍多的代码以及需要自己打补丁。

对于所有事情，都有一个平衡和权衡，对于内置支持，可用性实际上总是会有延迟，因为软件需要时间。

随着 .NET 的主要版本将在 11 月发布，圣诞节/假期期间可能总是会影响内置这些东西需要多长时间，就 Lambda 团队的时间和可用容量而言。

martincostello 于 2020-01-24

👍6

只是补充一下我的想法。我确实理解此版本的重要性，感谢您告诉我们。我利用这些反馈来推动我们这边的紧迫性。正如@martincostello提到的那样，.NET Core 3.1 发布的时间不是很好，因为假期和 reInvent 期间也是如此。

我是过去在 2.1 中提到的那个人，我希望我们实施的自动化会加速未来的发布。 @assyadh 实现的自动化确实帮助了我们，但不幸的是，自从我们使用 .NET Core 2.1 以来，随着软件的发展，情况发生了很大变化。一部分是 MS 构建 .NET Core 的方式，另一部分是 Lambda 服务如何与迁移到 Amazon Linux 2 一起工作。

所以请相信我，.NET Core 3.1 是@assyadh ，我和其他许多人最优先完成的工作。

normj 于 2020-01-24

👍23 ❤8

只是为了检查一下，是否在 Microsoft 发布预发布版而不是等待最终发布版后开始合并它的工作？这大概会减少圣诞节的影响，并允许它在最终版本发布后更快地交付，因为它只需要测试。

mungojam 于 2020-01-24

👍1

我利用这些反馈来推动我们这边的紧迫性

谢谢你这个@normj。这是我的 0.02 美元，希望它也能帮助您传福音。

正如@martincostello提到的那样，.NET Core 3.1 发布的时间不是很好，因为假期和 reInvent 期间也是如此。

正如@mungojam 所暗示的那样，.NET Core 3.1 从 10 月 15 日开始以预览形式提供，比发布前一个多月。此外，它基本上是 3.0 的错误修复版本 - 我不知道您的工具，但我想探索性工作可能已经开始使用 3.0，该版本于9 月 23 日发布并全年预览。值得注意的是，在 3.0 发布公告中给出了 3.1 的预计发布日期。

.NET Core 3.1 在发布后的 2-3 周内甚至无法在 Microsoft 的 Azure 应用服务上使用。

.NET Core 3.1 于10 月 17 日在 Azure Functions 上可用，预览版 1 发布两天后。

您可以对任何公司立即拥有 3.1 的需求发表意见，无论是“出血边缘”、自定义运行时选项等等，但这实际上是关于 AWS 希望支持我们 .NET 的更大图景的一部分顾客。如果 AWS——不是 Norm 的团队，而是整个 AWS——把它作为优先事项，我不得不认为他们本可以领先于此，确保他们与 Azure 竞争。

就个人而言，我真的很重视在云产品中的选择，我可以根据优点而不是公司教条来选择，我很想看到 AWS 在改进 .NET 支持方面迈出下一步。

感谢@normj 、 @assyadh以及任何其他为此所做的努力。

morquan 于 2020-01-24

👍10 🚀1

很可能 AWS 的 .NET 团队在 3.0 预览版发布后就开始了为 .NET 3.1 LTS 做准备的旅程。事实是，AWS 往往对他们在幕后所做的工作守口如瓶。这种缺乏透明度会产生假设。我认为制定某种路线图不会有什么坏处，即使它是暂定的并且日期可能会发生变化等等。

clearwaterstream 于 2020-01-24

我认为问题在于 AWS 团队不想推出任何类型的 ETA，因此开发人员被蒙在鼓里。 @normj说那是因为他不希望任何人或任何公司根据这些 ETA 制定未来计划。 ETA 只是一个估计，任何公司都不应该根据另一家公司的估计制定认真的计划，即使他们这样做了，公司也不能因为错过 ETA 而责怪 AWS 或生气，这难道不是普遍的理解吗？

ETA 也不是特定的一天。可以是一个月。四分之一。我们应该对任何 ETA 没问题，如果错过了也没关系。

abukres 于 2020-01-24

👍2

看着
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 的 lambda 抱有耐心。
顺便说一句，我也更喜欢坚如磐石的发布，然后有些匆忙。

我假设它将在下一两个月内推出，但 AWS 做出了一些承诺，
即使非常保守也可能有利于团队计划其运营。

另一件事是，在这个 OSS 时代：.NET 社区可以提供帮助吗？毕竟我们是在 github 上讨论的。
这个“内置”运行时是一些封闭的代码吗？

此外，如果部署过程切换到执行 ReadyToRun 和其他 AOT 编译功能，那么这将是一个杀手级功能，因此冷启动时间会严重减少。
这将使 .NET Core 在 IMO 的 AWS Lambda 上非常有吸引力。

@normj和团队：
感谢您让 .NET 核心在 AWS 上变得出色

petarrepac 于 2020-01-24

👍4

只是补充一下我的想法。我确实理解此版本的重要性，感谢您告诉我们。我利用这些反馈来推动我们这边的紧迫性。

请使用这篇文章来推动你的紧迫感。考虑到这一点，这是我的两便士。

只是为了检查一下，是否在 Microsoft 发布预发布版而不是等待最终发布版后开始合并它的工作？

问题：我们会得到这个问题的诚实答案吗？

感觉答案是不言而喻的。感觉 .NET 的优先级是“爱好级别”而不是“企业级别”，因为它应该是。

我在某处听说过 1) 整个 Net Core 的东西已经开源，2) 存在一些早期采用者程序，允许您在实际发布时“立即开始运行”。（有关详细信息，请参阅 Google。）

我在这里很有趣，但事实是，每个关注 .NET 的人都知道这一点，因此它增加了我所说的不言而喻。

老实说，在 2.1 发布延迟之后，我希望当时所做的更改意味着这一次（3.1）我们将在实际发布后两周内获得对新框架的支持。我的意思是在发布后的几个小时内是理想的，但在两周内为最后的润色/润色留出一些空间感觉是正确的。

但在这里，我们已经快两个月了，感觉只是“业余爱好”。

@rati-dzidziguri 我理解并感谢您想要一个预计到达时间，以便您可以做出相应的计划。实际上正是出于这个原因，我们通常不会给出预计到达时间，因为我们非常努力地不做出我们不能 100% 确定我们可以兑现的承诺。

这是“业余爱好”的想法，正如@abukres优雅地指出的那样：

我认为问题在于 AWS 团队不想推出任何类型的 ETA，因此开发人员被蒙在鼓里。 @normj说那是因为他不希望任何人或任何公司根据这些 ETA 制定未来计划。 ETA 只是一个估计，任何公司都不应该根据另一家公司的估计制定认真的计划，即使他们这样做了，公司也不能因为错过 ETA 而责怪 AWS 或生气，这难道不是普遍的理解吗？
ETA 也不是特定的一天。可以是一个月。四分之一。我们应该对任何 ETA 没问题，如果错过了也没关系。

我认为 AWS 失去了与 Azure 的 JEDI 合同这一事实应该足以在内部启动一些优先级会议，因为从表面上看，它证明 .NET 是一项“企业级”努力，应该被如此对待。不要浪费资源试图“起诉”决定，而是在内部使用这些资源来给 .NET 社区一些爱。借此机会重新确定 .NET 的优先级，以便在下一个 .NET 版本中，AWS 处于领先地位，并且不言而喻，他们已准备好开始运行。

@normj 、 @martincostello以及 AWS 那边的其他工蜂，非常努力地提供 SOLID .NET 产品，请理解这些（社区）投诉本身并不是针对您，而是针对文化/政治这决定了您在 .NET 方面的优先任务。请使用这篇文章来帮助实现“企业级”支持。

VagyokC4 于 2020-01-24

👍11

我主要认为这是 AWS 错失的大放异彩的机会。想象一下，如果遵循新的 LTS 版本将是一个高优先级。这将是多么强烈的声明。

当我们需要决定下一个项目使用哪种云时，这样的事情让我们的开发人员/架构师失去了与非技术决策者的争论。现在，当 Azure 和 AWS 的成本和功能产品基本相同时，决策更多地取决于政治和看法。当他们说“正式发布后已经 X 周/月了，AWS 还没有准备好”时，我没有什么可带的

同样，就像@VagyokC4所说的那样，这不是针对从事实际工作的员工的个人行为，而是对 AWS 上层管理人员的警钟。

CumpsD 于 2020-01-24

👍15

每个使用 .NET Core 3.1 Lambda 的人都可以考虑启用 IL Trimming。您很可能会减少 zip 文件的大小。
https://www.hanselman.com/blog/MakingATinyNETCore30EntirelySelfcontainedSingleExecutable.aspx

CraigHead 于 2020-01-24

👍3

.NET 核心 lambda 3.1 是使用 RuntimeAPI 构建的吗？
在公开场合，在 github 上？
如果没有，为什么不呢？

petarrepac 于 2020-01-25

我想要的只是......情人节是 lambda .net 核心 3.1 支持

cdesallegdf 于 2020-01-28

❤8

我想要的只是......情人节是 lambda .net 核心 3.1 支持

不会完全从舌头上滚下来，但它很谦虚：

~~圣诞节~~情人节我想要的不多
我只需要一件事
我不在乎礼物
在 AWS 树下
我只想要我自己的
比你知道的还要多
实现我的愿望哦
情人节那天我想要的只是 .NET Core 3.1 支持...

：咧嘴笑：

clearwaterstream 于 2020-01-28

😄19 👍5 👀2

微软在预览周期即将结束时包含 Go Live 许可证，届时他们不会引入任何重大更改。到那时，他们会为即将发布的版本提供生产支持。我的建议是等到他们使用 Go Live 许可证发布版本，然后开始开发工具。随着 .NET Core 3.1，它出现在预览版 3 中，该预览版于 11/14 发布。在这种情况下，RTM 甚至比 12/3 晚了 3 周，但当 RTM 出现并且客户开始建立期望时，您仍然会更接近推出这些功能。

只是我的 0.02 美元

buvinghausen 于 2020-01-29

👍2

我想要的只是......情人节是 lambda .net 核心 3.1 支持
不会完全从舌头上滚下来，但它很谦虚：
我不要太多~圣诞节~情人节
我只需要一件事
我不在乎礼物
在 AWS 树下
我只想要我自己的
比你知道的还要多
实现我的愿望哦
情人节那天我想要的只是 .NET Core 3.1 支持...
😁

+1 :)

keserwan 于 2020-01-30

👍1

Lambda 的 .NET Core 3.1 运行时有任何更新吗？

a-patel 于 2020-02-05

👍22

我们正在启动一个新项目，并且非常倾向于将 Lamba 用于大多数无服务器，但是看到支持 LTS 版本需要多长时间让我们重新思考，可能会改变架构或提供商。

CumpsD 于 2020-02-05

<Rant>
令人沮丧的是，AWS Lambda 运行时支持政策对 30 天窗口非常严格，而此类功能的要求时间超过 30 天。然后神奇地有一天，AWS 将部署此功能，而其他所有人都将不得不争先恐后地切换到 .NET Core 3.1。这使大多数组织陷入困境，因为修复、测试和部署某些东西到生产环境通常需要超过一个月的时间。我个人对这项政策深恶痛绝。曾经（因为资源限制和其他更高的优先事项）我在这个时候错过了一家公司。直到 3 个月后，我们才可以将 Lambda 升级到 .NET Core 2.1。一旦我们尝试使用 CloudFront 部署特定的 lambda，就会发生一些不好的事情（什么？谁知道因为 CF 日志是垃圾）并且需要回滚。除了没有可以回滚到的运行时。因此它LOCKED部署。我们立马开了票。 24 小时后，我们得到了第一个响应，即“删除整个堆栈并重新开始”。考虑到它会将我们的 DynamoDb 表与“删除”操作一起使用，这是一个完全无知的响应。我们被锁定在回滚中超过 2 个半星期。最终，我们找到了一位了解容器技术的支持工程师，并帮助我们回滚，然后一直在线直到我们的 CloudFormation 成功。它做得很好，第一次尝试没有改变。这就是为什么我现在讨厌 CF，因为它太容易使用了。
</Rant>

TL; 博士; AWS Lambda 运行时支持政策使用起来很不愉快，可能会让您陷入困境。
https://docs.aws.amazon.com/lambda/latest/dg/runtime-support-policy.html

CraigHead 于 2020-02-05

@CraigHead对您令人沮丧的经历感到抱歉，但要明确的是，无论 .NET Core 3.1 何时在 Lambda 上发布，Lambda 都将支持 .NET Core 2.1 运行时，至少到 2021 年 8 月 21 日为止，基于 Microsoft 支持周期。无需急于将 2.1 功能转换为 3.1。我假设您之前的经验是使用 .NET Core 2.0，这对 Lambda 来说是一个异常，因为它是唯一一个进入 Lambda 的非 LTS 版本。这只是由于 .NET Core 1.0 的一些重大问题才完成的。

normj 于 2020-02-06

👍4

是的，这是从 .NET Core 2.0 迁移到 .NET Core 2.1。对不起，咆哮。 30 天对我们中的一些人来说有点紧张。查看 lambda 的总长度，可能无需大量维护和额外的 QA 即可运行。

CraigHead 于 2020-02-06

同时，这发生在无服务器的 Azure 方面
https://visualstudiomagazine.com/articles/2020/01/30/azure-functions-3-0-runtime.aspx

rati-dzidziguri 于 2020-02-11

与此同时，AWS 团队正在致力于此。尖刻的评论无济于事
他们。当它准备好时，他们会更新这个问题。

2020 年 2 月 11 日星期二 18:22，Rati 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=AAAZVJXAAYET4F7PFFOTO3LRCLUETA5CNFSM4JU5UTJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELNQMBY#issuecomment-584779271 ，
或取消订阅
https://github.com/notifications/unsubscribe-auth/AAAZVJQK3NBVXBZALM4V5KLRCLUETANCNFSM4JU5UTJA
.

jchannon 于 2020-02-11

👍9

我的意思不是发表尖刻的评论，而是指出即使是 MS 最近也宣布了 3.1 的 GA 可用性，所以我希望看到 AWS 尽快完成他们在 3.1 支持方面的工作。
.

rati-dzidziguri 于 2020-02-11

👍5

同时，这发生在无服务器的 Azure 方面
https://visualstudiomagazine.com/articles/2020/01/30/azure-functions-3-0-runtime.aspx

考虑到它是一种 MS 语言，Azure 击败 AWS 来支持这一点并不奇怪。

密切关注此线程 - 期待升级我的 C# Lambdas。

Jono20201 于 2020-02-19

👀1

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

它于 2020-01-23 在 Azure 中可用
https://azure.microsoft.com/en-us/updates/azure-functions-runtime-30-is-now-available/

与 Azure 相比，我们还差一个月

顺便说一句，所有 .NET 核心开发都是在 github 上公开完成的
因此，成为“MS 语言”应该没有太大影响。
或者您建议使用 dotnet 的 AWS 客户端在 Azure 上更好：P？

无论如何，对于任何在 AWS 上收听的人：
我们正在等待 Lambda 的 3.1，这对我们很重要。

petarrepac 于 2020-02-19

👍7

顺便说一句，所有 .NET 核心开发都是在 github 上公开完成的
因此，成为“MS 语言”应该没有太大影响。
或者您建议使用 dotnet 的 AWS 客户端在 Azure 上更好：P？

我的意思是，微软的云平台不支持他们自己语言的新功能会有点尴尬。说实话，我有点惊讶他们花了一个半月多一点的时间！多一点内部沟通也许可以让两者同时发布。

我认为 AWS 在他们的 .Net 支持方面做得很好，尤其是与他们的服务挂钩的开发包，例如 CloudWatch + ILogging和他们的 SSM 参数配置。这对我们帮助很大。

希望尽快看到 3.1 版本:)

Jono20201 于 2020-02-19

👍13

我确实希望有一个更好的 Cloudwatch 具体实现ILogger 。使用 Lambda SDK 时，这会更好地集成到ServiceCollection / ServiceProvider 。请求上下文中提供的当前版本和静态 LambdaLogger 类基本上不可能对日志输出进行单元测试/验证并挂钩默认的 .netcore ConsoleLogProvider导致 Cloudwatch 日志混乱。

CraigHead 于 2020-02-22

我确实希望有一个更好的 Cloudwatch 具体实现ILogger 。

您是否尝试过https://github.com/aws/aws-logging-dotnet#aspnet -core-logging ？

Jono20201 于 2020-02-22

您希望您的日志看起来像@CraigHead？

我们过去曾使用 Serilog 和https://github.com/structured-log/structured-log来输出不错的控制台日志以及导入到 Seq 中的基于 JSON 的日志。 https://datalust.co/这是我们以非常好的格式获取中央日志的最佳方式。

andymac4182 于 2020-02-22

@CraigHead Amazon.Lambda.Logging.AspNetCore是我们将 Lambda 的日志记录集成到 IServiceCollection 的实现。那个图书馆不适合你。

我不会为 Lambda 推荐来自ttps://github.com/aws/aws-logging-dotnet#aspnet -core-logging 的 AWS.Logger.AspNetCore 包。该库使用后台线程将日志推送到 CloudWatch Logs。使用这样的后台线程并不能很好地与 Lambda 配合使用，Lambda 会在函数处理程序返回后立即冻结 Lambda 计算环境，这意味着后台线程可能没有机会刷新排队的消息。

normj 于 2020-02-23

👍3

我不知道这件事。谢谢你的提示！
我指的是 SDK 中的Amazon.Lambda.Core.LambdaLogger 。
我一定会检查那个包（ Amazon.Lambda.Logging.AspNetCore ）。

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

CraigHead 于 2020-02-23

@clearwaterstream
在 lambda-land AFAIK 中，没有事件会通知您当前实例将停止处理或将被终止，因此您的建议仍将保留缓冲日志事件未刷新（丢失）。

petarrepac 于 2020-02-24

请不要为了其他需要劫持这个线程。
创建此线程是为了在 AWS Lambda 上的 .NET Core 3.1 可用时提供一些信息。
并让 AWS 知道我们在那里等待。

petarrepac 于 2020-02-24

👍23

3.1 版本中会包含 lambda 测试工具吗？ https://github.com/aws/aws-lambda-dotnet/tree/master/Tools/LambdaTestTool

BrendenAZ 于 2020-02-25

这就是我的意图。该工作正在mock-testtool-31 中进行。 3.1 分支的重大改进是用户 Lambda 代码现在在单独的 AssemblyLoadContext 中运行，这应该可以解决用户与当前版本之间的许多版本冲突。我正在考虑将 AssemblyLoadContext 功能反向移植到 2.1 版本中。

作为旁注。我一直在争论将裸机 UI 转换为服务器端 Blazor 应用程序。有没有更多 Blazor 经验的人对这是一个好主意还是坏主意有任何反馈？

normj 于 2020-02-25

👍2

作为旁注。我一直在争论将裸机 UI 转换为服务器端 Blazor 应用程序。有没有更多 Blazor 经验的人对这是一个好主意还是坏主意有任何反馈？

在这一点上，任何 Blazor 都是一个好主意，尤其是对于我们这些摇摆 DotNet 的人！

VagyokC4 于 2020-02-25

“裸机 UI” - 这是其他一些应用程序，未连接到 .NET Core 3.1 Lambdas？
顺便说一句，我根本不在乎 blazor

petarrepac 于 2020-02-25

@petarrepac这是对我们提供的 AWS .NET Mock Lambda 测试工具的参考，该工具用于帮助调试 .NET Core 2.1 Lambda 函数。这是供参考的帖子https://aws.amazon.com/blogs/developer/debugging-net-core-aws-lambda-functions-using-the-aws-net-mock-lambda-test-tool/

我正在更新 .NET Core 3.1 的工具。

normj 于 2020-02-25

@normj
啊，没看懂，谢谢
有趣的是，我们从来不需要这样的工具

从我们的角度来看，lambda 是一个准系统的 AspNetCore HttpApi，您可以在本地调用并在本地进行测试
唯一的区别是入口点文件/类少于 50 行代码
此外，很多事情只有在部署到 AWS 时才能正确测试：

权限
接收到的 JSON 事件和上下文的形状
...
所以，组合：
在本地运行良好的单元/集成测试
本地http测试
易于部署以测试 aws 环境
可以走很远

或者我错过了一些明显的场景？

petarrepac 于 2020-02-25

@petarrepac使用 ASP.NET Core 桥接器的一大好处是它真的很容易在本地运行。我同意最佳实践是使用单元/集成测试，但通常需要对应用程序逻辑进行快速的临时测试，而这正是该工具的优势所在。

normj 于 2020-02-25

👍6

谢谢@normj。关于 Blazor，这可能是一个不错的选择。对于我们团队的用例，至少它可能会被利用不足。

我们只在 UI 中停留足够长的时间来发送有效负载，然后在 VS 中逐步执行代码。

BrendenAZ 于 2020-02-25

👍1

您绝对可以使用 Lambda Bootstrapper 和自定义运行时功能从一个代码库实现多个 lambda 函数。
我有一套 16 个 lambda 表达式，它们是从一个应用程序而不是“单体”部署的。
这是通过使用_handler环境变量来选择在运行时使用的方法来实现的，而不是博客文章示例代码中显示的硬编码一对一映射。
我认为它是一个控制台应用程序，它接收一个开关，告诉它在启动时“变成”什么动作。

@martincostello

根据你的解释，我在解决这个问题时遇到了一些麻烦。我的 Functions.cs 中有大约 20 个 Lambda 函数，它们与 serverless.template 中的相应定义相关联。我知道您将在每个定义中传递一个环境变量来指示要调用的函数。这些函数中的大多数都具有以下签名：

public APIGatewayProxyResponse ThisLambdaFunction(APIGatewayProxyRequest request, ILambdaContext context)
{

如果我有其他函数采用不同的参数（APIGatewayProxyRequest 除外）和不同的返回类型，如何添加对不同 lambda 函数签名的支持？

antsaia 于 2020-02-25

请不要使线程脱轨。

twopointzero 于 2020-02-25

👍11

@twopointzero我花了几天时间在 Google 上搜索使用 .NET Core 3.1 自定义运行时项目运行多个 lambda 函数的解决方案。互联网上没有更多相关线程，我正在回复现有帖子，该帖子提供了一线希望，即有解决我的问题的方法。

在 AWS 中没有原生的 .NET Core 3.1 支持让生活变得困难。我们需要升级到 3.1 才能升级到最新的 EntityFramewore Core 3.1.2，它修复了我们在 Aurora (PostgresSQL) 中看到的连接池问题。

@normj我完全理解没有 ETA 的立场，但你能告诉我我们是否接近吗？ < 30 天？

antsaia 于 2020-02-25

@antsaia尊重，您的评论与使用自定义运行时支持部署分布式单体有关，与 AWS Lambda 对 .NET Core 3.1 的支持无关。如果您在互联网上找不到更相关的线程，我恳请您创建一个而不是破坏一个。

为了不让自己脱离这个线程，这是我对此事的最终评论。

twopointzero 于 2020-02-25

👍10

@normj是否有可用的资源（博客、论坛等），我们可以从中获取有关 .net core 3.1 支持实施状态的信息？

我每天访问此页面，希望获得任何新信息，但显然没有足够的信息（因为它不用于该用途）。如果我们有一些基本的更新，那么我们就可以提前计划了。

像这里的许多人一样，我们交付功能的计划在很大程度上取决于我们是可以使用 3.1 还是必须使用 2.1 来开发它。就我而言，3.1 将提供对 System.Draw 的支持，这对我将要处理的功能产生重大影响。

liam-sage 于 2020-03-02

👍5

我想要的只是......圣帕特里克节是 lambda .net core 3.1 支持

cdesallegdf 于 2020-03-02

👍4

@liam-sage 我能找到的只是亚马逊论坛上的一些帖子，表明它将在 2020 年第一季度准备就绪。https: //forums.aws.amazon.com/thread.jspa =313806

joel-morland 于 2020-03-02

👍1

@liam-sage 我能找到的只是亚马逊论坛上的一些帖子，表明它将在 2020 年第一季度准备就绪。https: //forums.aws.amazon.com/thread.jspa =313806

这意味着它必须在 3 月份上线。我在等。

martonx 于 2020-03-03

嗨，我知道它并不完全合适，但您可以将自己的 lambda 更新到 dotnetcore 3.1。同时，在您等待期间，我建议您创建大量 lambda 表达式来编写您自己的 dotnetcore 模板。我这样做是为了我自己。我想确保我不必在样板代码上浪费时间。可以在此处找到模板示例。

vincentvanderwalt 于 2020-03-05

👍1

文森特，我们如何在那里举办？使用自定义运行时？
2020 年 3 月 5 日星期四晚上 7:40 Vincent van der Walt <
[email protected]> 写道：

嗨，我知道它并不完全合适，但你可以得到你自己的 lambdas
更新到 dotnetcore 3.1。与此同时，当你等待的时候，我会建议
如果您创建大量 lambda 来编写您自己的 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=AGIDH4OWUT7Y3HR3O5KARBDRF62V3A5CNFSM4JU5UTJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEN5P2CY#issuecomment-595262731 ，
或取消订阅
https://github.com/notifications/unsubscribe-auth/AGIDH4PLKFSDLNBX2QVMG63RF62V3ANCNFSM4JU5UTJA
.

alirafique99 于 2020-03-05

是的，它利用了自定义运行时。

您可以在您的机器上本地运行它或部署到 aws。

F5 用于本地和dotnet lambda deploy-serverless用于部署到 aws

自述文件解释了如何将模板安装到本地机器上（它是一个 dotnetcore 模板）

vincentvanderwalt 于 2020-03-05

👍1

自定义运行时很酷，但我仍在等待 AWS 对 .Net Core 3.1 的完整支持，以便 lambda 在生产环境中使用它们😄

bartoszsiekanski 于 2020-03-06

👍4

每次我在收件箱中看到这个，我都会迫不及待地打开它看看
宣布任何事情只是为了找到一个至少有点偏离的帖子
话题。其他人要求其他人不要劫持该线程，但并没有
工作。有人可以锁定线程，直到有人准备好宣布
发布 3.1 支持？

在周五，2020年3月6日在上午07点13 bartoszsiekanski [email protected]
写道：

自定义运行时很酷，但我仍在等待完整的 AWS 支持
for .Net Core 3.1 for lambdas 在生产环境中使用它们😄
—
您收到此消息是因为您发表了评论。
直接回复本邮件，在GitHub上查看
https://github.com/aws/aws-lambda-dotnet/issues/554?email_source=notifications&email_token=AAVUT3SNDR4L2ZL5J4KQYDDRGDSHBA5CNFSM4JU5UTJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBWZKEOTLOM50000000000000000000000000000000000000000000000000000000000000000000001
或取消订阅
https://github.com/notifications/unsubscribe-auth/AAVUT3TBH3NIBMGB54EFCR3RGDSHBANCNFSM4JU5UTJA
.

hounddog22030 于 2020-03-06

👍11

除了讨论 .NET Core 3.1 支持之外，请为其他任何事情创建单独的问题。在我们有更多新闻@normj之前，我可以关闭这个问题吗？

raRaRa 于 2020-03-06

👍4

@hounddog22030我没有意识到我在“劫持”线程。我的建议是，与其不断询问它是否准备就绪，不如说如果人们迫切希望迁移到 dotnetcore 3.1，还有其他方法。官方非自定义运行时支持将在准备就绪时准备就绪。人们只需要多一点耐心或寻求替代方法。

vincentvanderwalt 于 2020-03-06

👍2

如果 AWS 支持 dotnet lambda package 命令中的 --self-contained 选项，则无论其 SDK 版本如何，lambda 函数都必须是可执行的。对？为什么不这样做，而不是为每个 .NET Core 版本添加支持？

aussiearef 于 2020-03-17

如果 AWS 支持 dotnet lambda package 命令中的 --self-contained 选项，则无论其 SDK 版本如何，lambda 函数都必须是可执行的。对？为什么不这样做，而不是为每个 .NET Core 版本添加支持？

您刚刚描述了 lambda 自定义运行时功能

Thiago-Dantas 于 2020-03-17

@aussieref这确实很好用，但自包含的包包括 .Net Core 本身，对于网站来说，它通常至少增加 40MB（压缩）——为应用程序和依赖项本身留下太多空间。

aidansteele 于 2020-03-17

使用相同版本的 .NET Core 时，自定义运行时也比本机运行时慢（冷启动）。 3.1 增加了许多性能改进，因此您可以在 3.1 自定义完全优化和 2.1 本机之间期望相同级别的性能。我希望 3.1 原生会带来重大改进。

madmox 于 2020-03-17

👍1

Q1 将在 4 天后结束，但看起来我们不会在 lambda 中看到 3.1。
我希望团队的所有成员在这个大流行时期都是安全的，并希望在第二季度看到这个版本。

rati-dzidziguri 于 2020-03-27

👍4

不要放弃希望我们还有几天！我们几乎都在等待最终部署和其他最后一刻的活动。请记住，我们都知道软件，最后一刻可能会出现问题。

我实际上计划很快开始推出新的客户端工具更新，以确保一旦运行时打开，一切都可用。因此，如果您看到新的 NuGet 包更新消失，请不要假设运行时已经存在。等到博客文章出来了，我会在这里发布更新。

normj 于 2020-03-27

👍25 🎉23 ❤15 👀8

这真是个好消息。谢谢@normj

期待博客文章和发布。

vincentvanderwalt 于 2020-03-27

不要放弃希望我们还有几天！我们几乎都在等待最终部署和其他最后一刻的活动。请记住，我们都知道软件，最后一刻可能会出现问题。
我实际上计划很快开始推出新的客户端工具更新，以确保一旦运行时打开，一切都可用。因此，如果您看到新的 NuGet 包更新消失，请不要假设运行时已经存在。等到博客文章出来了，我会在这里发布更新。

面对此线程中的态度，您的耐心令人印象深刻。感谢您为此努力！

gregorylyons 于 2020-03-27

👍3 😄1

@normj很乐意协助您在发布之前进行任何测试；)

3GDXC 于 2020-03-28

还有 2 天，手指交叉。

rati-dzidziguri 于 2020-03-30

🚀2 👍2

本季度还剩 13 小时就结束了😅

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

感谢大家的耐心等待。 @raRaRa我会让你很荣幸关闭这个问题。

normj 于 2020-03-31

🎉34 👍34 🚀19 ❤14 😄6

伟大的

2020 年 3 月 31 日，星期二，20:06 Norm Johanson， notifications@ github.com 写道：

本季度还剩 13 小时就结束了😅
https://aws.amazon.com/blogs/compute/annoucing-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
.

ahmadwaquar88 于 2020-03-31

谢谢你！！！！

clearwaterstream 于 2020-03-31

还有....取消订阅:-)

感谢所有参与的人！！！

bobhaffner 于 2020-03-31

👍1

谢谢！

VissnuKumaar 于 2020-03-31

本季度还剩 13 小时就结束了😅
https://aws.amazon.com/blogs/compute/annoucing-aws-lambda-supports-for-net-core-3-1/
感谢大家的耐心等待。 @raRaRa我会让你很荣幸关闭这个问题。

干得好！

assyadh 于 2020-03-31

那是 AWS 宝贝。那是AWS！！！
不管发生什么，他们最终都会完成它。

非常感谢，团队！！！

rati-dzidziguri 于 2020-03-31

好消息，非常感谢@raRaRa @normj ！！！冒着听起来愚蠢和/或贪婪的风险，这在本质上是否也意味着 Powershell 7？只是仔细检查......

andyKalman 于 2020-03-31

@normj和 AWS 的每个人干得

这是滚动到底部的博客的链接
https://aws.amazon.com/blogs/compute/annoucing-aws-lambda-supports-for-net-core-3-1/

raRaRa 于 2020-03-31

👍5 🎉2

太棒了，感谢一百万添加对 dotnet core 3.1 的支持！！！

albertocorrales 于 2020-03-31

@andyKalman还没有使用 PowerShell 7。我正在对 AWSLambdaPSCore 模块进行一些最后的修改，然后将发布的 AWSLambdaPSCore 的 2.0.0 版本放到图库中。

normj 于 2020-03-31

👍1

我很感谢@normj的快速回复。事后我确实看到了#607，很高兴看到它看起来是一个快速的跟进。是否还有其他问题需要跟踪，以便我可以在此处停止评论？：）再次感谢。

andyKalman 于 2020-03-31

恭喜！
并感谢 AWS 和 .NET 团队！
非常感激。

petarrepac 于 2020-03-31

感谢所有帮助实现这一目标的人！这是一个巨大的版本，它显示了大量的辛勤工作！好的！ 🎉🥳

CraigHead 于 2020-03-31

谢谢！！：拍手：：：拍：：多田：：多田：

hiroCat 于 2020-03-31

恭喜各位，期待升级。

morquan 于 2020-03-31

谢谢！

genisbarrera 于 2020-03-31

很棒的工作，热衷于升级这些 lambda。

brajm008 于 2020-03-31

做得好！谢谢@normj👏👏

joel-morland 于 2020-04-01

伟大的工作团队！

SureshD84 于 2020-04-01

渴望通过 dotnet 3.1 Async Streams +AWS AppSync/GraphQL 订阅加入 Lambda 工作者。
AWS 团队，非常感谢！

akrsmv 于 2020-04-01

天哪，你们统治的家伙！惊人的！呜呼！ 😄😄😄

bartoszsiekanski 于 2020-04-01

谢谢！

hrytskivr 于 2020-04-01

@andyKalman我推出了 AWSLambdaPSCore 模块的 2.0.0 版，该模块现在使用 PowerShell 7。我计划发布一篇关于 PS7 支持的博客文章，但它的作用与现有的 PowerShell 6 支持仅使用 7 相同。

normj 于 2020-04-02

😄1

@andyKalman我推出了 AWSLambdaPSCore 模块的 2.0.0 版，该模块现在使用 PowerShell 7。我计划发布一篇关于 PS7 支持的博客文章，但它的作用与现有的 PowerShell 6 支持仅使用 7 相同。

如果我使用新版本发布它们，新版本的 AWSLambdaPSCore 是否会更新我现有 Lambda 函数中的任何配置？喜欢它指向 dotnet3.1 和 ps7 吗？

tr33squid 于 2020-04-02

@tr33squid是的，如果您使用 2.0.0 进行部署，它将使用 .NET Core 3.1 和 PS7

normj 于 2020-04-02

非常感谢 AWS 团队的出色工作！！

Rajivhost 于 2020-04-03

嗨，大家好，
我正在积极致力于在 Lambda 中引入对 .NET Core 3.1 的支持。这需要一些时间，因为 Microsoft 在构建运行时方面做了大量工作。我正在努力合并这些更改，以便为您带来本机运行时。

感谢 AWS-Lambda .NET 核心团队

neetika123 于 2020-04-08

你好，
尝试执行 AWS-Lambda 时出现此错误
找不到任何兼容的框架版本。
未找到指定的框架“Microsoft.AspNetCore.App”，版本“3.1.0”。
有什么建议？？

neetika123 于 2020-04-24

你好，
尝试执行 AWS-Lambda 时出现此错误
找不到任何兼容的框架版本。
未找到指定的框架“Microsoft.AspNetCore.App”，版本“3.1.0”。
有什么建议？？

您需要安装 3.1.0 SDK。

gregorylyons 于 2020-04-24

👍1

我相信 Microsoft.AspNetCore.App 应该从您的项目中删除
依赖项，Core 3.1.0 不再需要，我不得不将其删除
构建和部署我从 2.1 升级的服务。

2020 年 4 月 24 日星期五上午 3:24 Gregory Lyons通知@github.com
写道：

你好，
尝试执行 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
.

——
最好的事物，
乔治

乔治·塔科斯
高级解决方案架构师

WeAre8
公园大道 230 号，第三层。西
纽约，NY 10169
(917) 717-9067
weare8.com

私人入口，
范德比尔特大街 71 号
3楼

weare8 于 2020-04-24

我相信 Microsoft.AspNetCore.App 应该从您的项目依赖项中删除，Core 3.1.0 不再需要它，我必须删除它才能构建和部署我从 2.1 升级的服务。
…
2020 年 4 月 24 日星期五，凌晨 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 。
-- Best, George George Taskos 高级解决方案架构师 WeAre8 230 Park Avenue, 3th fl. West New York, NY 10169 (917) 717-9067 weare8.com Private Entrance, 71 Vanderbilt Ave 3rd Floor

感谢您的回复，
其实这个错误是由于我的愚蠢错误。我忘了在 serverless.yml 中删除 runtime: dotnetcore2.1。现在问题解决了。

neetika123 于 2020-04-24

有人对此做过任何更新的基准/比较吗？我能找到的都是带有自定义运行时的旧版本。

onionhammer 于 2020-07-04

有人对此做过任何更新的基准/比较吗？我能找到的都是带有自定义运行时的旧版本。

这是一个很好的。
https://medium.com/@zaccharles/a -close-look-at-net-core-3-1-on-aws-lambda-9ccec4dd96be

另外，我在 512mb lambda 大小上将 2.1 复杂 lambda 更新为 3.1 的个人经验看到几乎完全相同的性能（冷启动和热启动）。 2.1 和 3.1 lambda 都使用 lambda 层、优化发布、newtonsoft（可能会看到 3.1 中 Microsoft json 的性能改进）、分层编译关闭和 3.1 的 RTR。

从我的指标来看，它似乎在 dotnet 3.1 运行时获得了轻微的性能，但在 Amazon Linux 2 和 dotnet 3.1 初始化上的性能下降。（2.1 使用 Amazon Linux 1。）制作收益。

davidruhmann 于 2020-07-04

Aws-lambda-dotnet: .NET Core 3.1 (LTS) 已经发布

最有用的评论

所有130条评论

相关问题