Azure Function与WindowsAzure.Storage版本冲突（DLL地狱）技术问询

嗨，我来帮你理清这个困扰～

首先得明确：VS2017的早期Azure Function模板（对应v1 runtime）确实会强制绑定WindowsAzure.Storage 7.2.1这个旧版本，这是因为当时的Azure Functions runtime对Storage SDK的兼容性有严格限制，更高版本的SDK会出现API不兼容、序列化失败甚至部署后无法启动的问题。

那是否建议降级到7.2.1？分两种情况来看：

如果你打算继续使用v1 runtime #

这种情况下非常建议降级到7.2.1，而且同步降级关联的OData、JSON等依赖包是稳妥的做法——毕竟7.2.1和这些依赖包的版本是经过官方适配的，能最大程度避免版本冲突导致的各种奇怪问题。很多博客把这个作为解决方案，也是因为大量开发者在实践中验证过，确实能解决v1 runtime下的兼容性报错。

不过降级后记得做两件事：

• 全面测试所有和Azure Storage相关的功能（比如Blob读写、Queue消息处理），确保没有异常；
• 不要盲目过度降级依赖包，参考NuGet上WindowsAzure.Storage 7.2.1的依赖说明，只降到它要求的最低兼容版本即可。

如果你可以升级到更高版本的runtime #

其实更推荐你考虑升级Azure Functions的runtime到v2或v3（VS2017需要安装对应的Azure开发扩展才能支持）。因为v2+的runtime已经放弃了对WindowsAzure.Storage旧包的依赖，转而支持新的Azure.Storage.*系列包（命名空间从Microsoft.WindowsAzure.Storage改为Azure.Storage.Blobs等），这些新包不仅性能更好，安全性更高，还能避免旧版本的各种限制。

如果选择升级runtime，你需要：

• 在创建Azure Function项目时选择v2或v3版本（如果VS里没有这个选项，先更新VS的Azure开发工具）；
• 替换项目中旧的Storage引用为新的Azure.Storage.Blobs、Azure.Storage.Queues等包；
• 调整代码中的命名空间和API调用（新包的API设计更简洁，改动不算大）。

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