Aws-lambda-dotnet: .NET 5 支持吗？

我对这个话题也很好奇，尤其是因为等待下一个 LTS（2021）听起来是一个非常糟糕的（商业）想法。

Lambda 服务团队的政策是支持 LTS 版本的运行时。 我们，AWS .NET 团队，正在努力研究我们的替代方案，以了解我们如何能够最好地使用 Lambda 支持 .NET 5，因为我们知道它有很多令人兴奋的地方。

出于以 Lambda 的角度运行 .NET 的好奇心，人们对 .NET 5 最感兴趣的是什么？ 这有助于我推动优先事项。

启动快、占用空间小、内存占用少
.NET 的静态编译（提前 - AOT）
Java 互操作性——这可能是一个“杀手级功能”

嗨@andyfurniss4 ，

下午好。

看起来@normj已经提供了关于这个问题的意见。 请告知我们是否可以关闭此问题。

谢谢，
阿西什

出于以 Lambda 的角度运行 .NET 的好奇心，人们对 .NET 5 最感兴趣的是什么？ 这有助于我推动优先事项。

我真的很想转到 C# 9 for Records、新的 Json 序列化、可空类型注释、F# 5 - 按这个顺序

我很想知道使用自定义运行时而不是本机 .NET 5 支持能走多远。 特别是链接修剪器应该可以剪掉很多不必要的代码，减少包的大小。 如果自定义运行时方法不合适，那么我将非常支持本机 .NET 5 支持。 正如其他人指出的那样，主要驱动因素是新的 C# 语言功能。

自定义运行时应该可以工作，但是 5.0 RC1 中的 .NET 运行时存在一个错误，这意味着它在 AWS Lambda 中不起作用（请参阅 #730）。 RC2 发布后应该会很好。

使用和维护自定义运行时是否会给团队带来很大的开销？ 我最近没有研究它，上次似乎需要付出很多努力，但那是针对 CoreRT 的。

例如设置一个，使用它，更新它等？

AWS 对他们的支持如何？

根据个人经验，我唯一的持续开销是每月一次撞击 NuGet 包和 SDK 以获取最新的修复程序和/或安全补丁，然后重新部署。

否则，我认为切换到自定义运行时花了我大约一天的时间来重构和测试所有内容并插入Amazon.Lambda.RuntimeSupport包。

您必须编写更多代码并使其保持最新状态，但您可以在最新功能可用时立即使用它们。 如果您没有足够的带宽来保持更新等，那么您可以使用内置运行时，但是您必须等待 AWS Lambda 团队在所有其他项目中提供新的运行时所需的时间工作。

对于我的用例，我觉得开销值得能够按照我们自己的计划进行更新，而不是绑定到 AWS 上。

天啊。

我们目前正在从 Oracle 迁移到 Aurora Postgres，因为他们拖慢了我们的开发速度，因为我们无法使用最新技术进行创新。 因为它是面向 .NET Core 3.X 的 Oracle 实体框架驱动程序刚刚发布。 但是，我们意识到因为他们，我们需要继续使用 LTS。 但 LTS 支持不可能在几个月后到来。 鉴于我认为 .NET 5.0 也是 LTS 计划的一个很好的例外，因为它在功能上发生了如此巨大的转变。

现在 .NET 5 发布了，有什么消息吗？

我的主要兴趣是 C# 9 和所有System.Text.Json更新。

请记住，您现在可以使用自定义运行时功能来使用 .NET 5： https :

我还没有尝试过，但是使用 .NET 5 中的新代码修剪，体验应该比使用 .NET Core 3.0 好很多。

Lambda 服务团队的政策是支持 LTS 版本的运行时。 我们，AWS .NET 团队，正在努力研究我们的替代方案，以了解我们如何能够最好地使用 Lambda 支持 .NET 5，因为我们知道它有很多令人兴奋的地方。

出于以 Lambda 的角度运行 .NET 的好奇心，人们对 .NET 5 最感兴趣的是什么？ 这有助于我推动优先事项。

这是否意味着仅当 .NET 5.0 从“当前”移动到“LTS”时才支持使用 .NET 5 运行 lambda 应用程序？

.NET 5.0 永远不会是 LTS。 .NET 6.0 将是下一个 LTS 版本。

.NET 5.0 永远不会是 LTS。 .NET 6.0 将是下一个 LTS 版本。

对于 lambdas 及其对使用 .NET 5.0 的支持，这究竟意味着什么？

这意味着我们不应该期望在 Lambda 上支持 .NET 5，因为它不会是 LTS。

这意味着我们不应该期望在 Lambda 上支持 .NET 5，因为它不会是 LTS。

谢谢@bjorg 。 如果这是结论，那么这个问题不应该以此作为直接答案吗？

我在知道 .NET 5 不是 LTS 并且 AWS 团队只支持 LTS 的情况下提出这个问题。 我想知道是否会因为发布的规模和下一个 LTS 直到 2021 年底才会有一个例外。事实是，我们还没有明确的“是”或“否”但我认为我们不应该关闭它。 .NET 5 版本来来去去（就像它在 3.1 中所做的那样），我们没有 Lambda 支持，但这并不意味着 A）他们不致力于它或 B）他们不打算这样做。

如果 AWS 人员决定不支持 .NET 5 并且他们明确表示这一点，那么可以肯定，让我们关闭这个问题。 如果是这种情况，那么我们只需要再等 12-18 个月即可获得下一个受支持的 .NET 版本。

此外，我知道还有一百万件其他事情需要处理，这可能不是微不足道的。 我就是喜欢闪亮的新东西😋

事实是，考虑到微软决定给 .NET 的速度，每隔一年等待 LTS 发布是没有意义的。 因为即使当前版本也有 LTS 的味道，因为它必须持续 15 个月（1 年 + 3 个月的支持）。

如果 AWS 定义了 LTS 和 Current 运行时，我会很好，这样我们的客户就可以决定我们想要保留的路径。

老实说，我可以为 Current 路径上的运行时预煮自定义运行时。

老实说，我可以为 Current 路径上的运行时预煮自定义运行时。

您这么说，但其他人可能不会那么热情地在 2021 年 11 月收到来自 AWS 的通知，告诉他们在 Lambda 退出 AWS 的所有支持之前，他们有 3 个月的时间从 5.x 更新到 6.0。

一年内可能会发生很多变化，突然间，团队可能没有足够的带宽来应对更新 Lambda 的需要运行时无需考虑。

当然，可能有一个当前预煮的当前运行时，上面有大量警告和警告，但这会带来用户需要了解的支持复杂性和细微差别。

如果 Lambda 在 Microsoft 发布之日支持 .NET 的所有新主要版本，那就太好了，但我想在它们的规模上这样做的实用性是为什么事情会变成现在的样子。

如果您真的，真的想走在最前沿，尽快升级，自己支持事情，做自己的事情，并接受所有后果，那么这就是自定义运行时的用途。

问题是，我们显然并不处于前沿。 .NET Core 发展迅速并且非常稳定。 立即查看 NuGet，其中有 5.0.0 的软件包。 它们现在供公众消费。

虽然我还没有尝试将 DotNet Core 3.1 项目升级到 DotNet 5，但到目前为止，我还没有在升级时遇到任何重大问题（例如从 2.1 到 3.1）。

DotNet 5 可能是一个不同的野兽，但我的自定义运行时适用于更不寻常的环境，如 C++ Lambda。

我宁愿尽快获得更新并迁移到 DotNet 5 Lambda。 2020 年已经证明，一年是一段漫长的时光 :-)

我知道你来自@martincostello。

但这是应该由客户做出的选择：选择 Current 或 LTS。

AWS 没有在 Current 上发布运行时，因为选择它的客户可能会发现自己遇到麻烦，因为它扭曲了 AWS 对其客户的责任。 他们应该提供工具，让每个人决定哪种工具最适合他们。

除了@genifycom所说的之外，Lambda 函数通常非常简单，而且大多数情况下，它们的代码不依赖于框架的特定功能，因此很难从一个主要版本移动到另一个主要版本（显然存在异常） .

在我的公司，我们有数十个函数，大多数时候我们使用文件夹范围的查找/替换来升级它们（当我们必须从项目文件中删除特定的 LambdaTools 属性时，它会更复杂一些）。

在 LTS 版本可用之前，我也希望看到对 dotnet 5 的传递支持。 （这发生在过去的另一个版本中）

目前唯一可用的选项是：

• 留在 dotnet core 3.1 并等到 dotnet 6 :(
• 使用自定义运行时（这本身就可以了，但是，由于 dotnet 5 中缺乏足够的本机 AOT，启动时间可能会受到影响，以至于它会使开发人员放弃这个想法 https://medium.com/ @zaccharles/benchmarking-lambdas-new-custom-runtime-for-net-core-43ea79b5a35a)

Zac 跟进了该原始帖子，详细介绍了如何提高自定义运行时的启动性能： https: //medium.com/@zaccharles/net -core-3-0-aws-lambda-benchmarks-and-recommendations- 8fee4dc131b0

我希望他发布一个 .NET 5 版本，因为 .NET 5 中有很多 .NET Core 3.1 中不存在的编译改进，例如代码修剪，这对自定义运行时非常有用。