.NET 7.0.14应用无法在Azure App Service运行的解决方案咨询

云上老周

2026-7-5

解决方案

下面是几个不用修改本地开发环境就能解决问题的办法：

升级Azure App Service的.NET运行时到7.0.14
这是最省心的方案，完全不用动代码或构建配置：
1. 登录Azure门户，找到你的目标App Service
2. 进入配置 > 常规设置页面
3. 在**.NET版本**下拉列表里选择7.0（Azure会自动同步最新的补丁版本，7.0.14已在可用列表中）
4. 保存设置后重启App Service
  服务器端升级后，和本地、流水线的版本完全匹配，应用就能正常运行。
在BitBucket流水线里指定7.0.13版本的SDK镜像
只修改流水线的构建镜像，本地开发环境保持不变：
把原来的镜像标签从7.0（默认拉取最新补丁版）改成指定版本的7.0.13，比如流水线配置文件里：
```
image: mcr.microsoft.com/dotnet/sdk:7.0.13
```
微软为每个.NET补丁版本都提供了对应的Docker SDK镜像，这样构建出来的应用就会适配Azure上的7.0.13运行时，本地依然用7.0.14开发不受影响。
采用自包含部署打包应用
构建时把.NET运行时一起打包进应用，彻底脱离服务器的.NET版本依赖：
修改流水线里的发布命令，加上--self-contained true参数，比如：
```
dotnet publish -c Release -r linux-x64 --self-contained true
```
（如果你的App Service是Windows环境，把linux-x64替换成win-x64）
这种方式会让部署包变大，但不管Azure上装的是哪个7.0补丁版本，应用都能正常运行，本地和流水线的构建版本也不用统一。
优化global.json配置（规避本地问题）
之前用global.json出问题大概率是配置不合理，你可以试试只限制SDK版本同时允许向前兼容：
```
{
  "sdk": {
    "version": "7.0.13",
    "rollForward": "latestMinor"
  }
}
```
rollForward设为latestMinor后，本地开发时会自动使用7.0.x里的最新补丁版（也就是你现在的7.0.14），而流水线构建时会严格用指定的7.0.13版本。如果这个配置还是导致本地问题，建议优先用前面三个方案。