使用ARM模板修改Azure Web应用.NET版本为.NET 5未生效问题咨询

问题根因 #

你遇到的部署失效问题，本质是混淆了Azure App Service中两套完全独立的运行时配置属性：

• 你写入的netFrameworkVersion属性，仅用于控制传统Windows托管的.NET Framework（4.x/3.5/2.x系列）运行时，和.NET Core、.NET 5+的跨核心运行时没有任何关联。
• 你设置的"netFrameworkVersion": "v5.0"本身就是无效取值：该属性的合法值仅对应.NET Framework的CLR版本，例如v4.0（对应实际运行的.NET Framework 4.8）、v2.0，根本不存在v5.0的合法配置。ARM部署只会做模板结构校验，会直接把这个无效应值存入资源属性包，不会触发App Service的运行时切换逻辑——这就是为什么你能在资源管理器里看到这个值，但门户上显示的运行时依然是.NET Core 3.1（这个展示状态本质是由现有配置中linuxFxVersion的值为DOTNETCORE|3.1决定的，和你写入的netFrameworkVersion没有任何关联）。

正确的.NET 5运行时配置方式 #

注意一个历史遗留的命名陷阱：无论你使用Windows还是Linux的App Service计划，.NET Core、.NET 5+的运行时版本配置，统一存储在linuxFxVersion属性中。这个命名的由来是最早.NET Core仅支持Linux托管，后续Windows平台上的.NET Core托管能力直接复用了这套属性结构，微软并没有单独为Windows平台新增独立的配置项。

针对你当前的Windows版App Service场景，要切换到.NET 5运行时，需要在Microsoft.Web/sites/config（对应站点的web配置实体）的properties对象内添加如下配置：

"linuxFxVersion": "DOTNETCORE|5.0"

• 只要linuxFxVersion的值为DOTNETCORE|x.y格式，App Service就会自动识别并加载对应版本的.NET Core/.NET 5+运行时，这个值和门户配置页截图里你看到的运行时下拉选项是完全一一对应的。
• 不需要额外修改netFrameworkVersion的值：如果你的场景是跑.NET 5的跨平台应用，传统.NET Framework的配置属性不会影响Core系运行时的加载，强行在netFrameworkVersion里设置v5.0反而会增加排查成本。

部署后校验 #

配置部署完成后，你可以在资源管理器中确认对应站点配置的linuxFxVersion值是否为DOTNETCORE|5.0，该值会直接同步到门户的运行时配置展示页，不会出现“资源层有值、门户不生效”的脱节问题。

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