CloudFormation部署.NET Lambda时DOTNET_SHARED_STORE设置及报错排查

你的配置一共存在3个核心问题，直接导致了程序集加载失败：

• 程序集版本完全不匹配
  你在Lambda层中打包的Amazon.Lambda.Core版本为2.1.0，但函数引用的AWSSDK.CloudFront 3.7.4.39明确依赖3.7.11.13及以上版本的Amazon.Lambda.Core。.NET Lambda运行时不会自动做跨大版本的程序集兼容，版本号不匹配时会直接判定程序集不存在。
  至于报错中提到的Version=1.0.0.0是加载失败后的默认版本占位提示：因为你的函数没有直接引用Amazon.Lambda.Core，编译时不会自动生成程序集绑定重定向规则，运行时找不到3.7.11.13版本的程序集后，回退查找最低默认版本失败，就会抛出这个带1.0.0.0版本号的错误，不是真的需要加载1.0.0.0版本的包。
• 层与函数的目标框架可能不一致
  使用dotnet lambda publish-layer创建运行时存储层时，会严格按照执行命令时指定的目标框架（比如net6.0、net8.0）生成对应目录结构，如果你创建层时用的目标框架和函数项目的目标框架不一致，哪怕环境变量配置正确，运行时也不会扫描到不匹配框架下的程序集。
  另外你执行dotnet lambda package时带--function-layers参数的作用是把对应层中已包含的依赖从函数部署包中剔除，如果层本身因为框架不匹配没有正确打包对应依赖，函数包里又被剔除了对应文件，运行时必然找不到程序集。
• 层目录结构与环境变量路径未做校验
  你配置的DOTNET_SHARED_STORE=/opt/dotnetcore/store/是工具默认的路径，但如果执行dotnet lambda publish-layer时指定了自定义输出路径、或者漏加了--enable-package-store参数，层解压后的实际文件路径会和默认路径不一致——比如包可能被放到/opt/dotnet/目录下而非/opt/dotnetcore/store/，环境变量指向错误路径自然无法加载程序集。

按以下顺序调整即可解决问题：

1. 统一依赖版本：将层中的Amazon.Lambda.Core版本升级到3.7.11.13及以上，和AWSSDK.CloudFront的依赖版本完全对齐，不要留版本差。
2. 校验层结构：重新创建层后，先解压生成的层压缩包，确认所有NuGet包都存放在dotnetcore/store/目录下，确保层挂载到Lambda的/opt目录后，完整路径和你配置的DOTNET_SHARED_STORE值完全匹配，没有多余的嵌套目录。
3. 对齐目标框架：确保创建层时指定的目标框架和函数项目的目标框架完全一致，执行打包命令前先清理项目的bin、obj目录，避免本地缓存的旧依赖引发版本冲突。
4. 多场景校验：如果后续叠加多个.NET Lambda层，需要把所有层的store路径用冒号分隔后填入DOTNET_SHARED_STORE，每个路径末尾必须携带/。

内容的提问来源于stack exchange，提问作者Tim Bassett