Azure App Service中WEBSITE_RUN_FROM_PACKAGE变量自动生成问题

• 我有一个包含Web App和Web Job项目的解决方案，通过Azure DevOps流水线用ZipDeploy部署到Azure Windows App Service。DEV和TEST环境部署一切正常，但PROD环境会自动出现WEBSITE_RUN_FROM_PACKAGE=1变量。
• 该变量不在我的appsettings.json或用户机密文件中，三个环境的发布流水线除了订阅和App Service名称外无其他差异。
• 另一个包含Web App和2个Web Job的类似解决方案，可在三个环境中正常部署，对比两个DevOps项目的构建、发布流水线未发现差异。
• 通过Kudu查看App Service文件系统中的appsettings.json，没有该变量条目，但环境变量页面显示WEBSITE_RUN_FROM_PACKAGE=1和APPSETTING_WEBSITE_RUN_FROM_PACKAGE=1。手动删除该变量后，过段时间它又会重新出现。

补充说明：手动删除PROD环境的WEBSITE_RUN_FROM_PACKAGE=1后，Web App重启抛出了之前版本的错误。重新部署最新版本后，Web App恢复正常，但该变量又自动出现。

编辑：PROD阶段Azure App Service部署任务的YAML

trigger:
  - main

pool:
  vmImage: windows-latest

stages:
  - stage: BuildStage 
    displayName: Build
    jobs:
    - job:
      displayName: Build 
      steps:
        - task: DotNetCoreCLI@2
          inputs:
            command: 'build'
            projects: '**/*.csproj'
            arguments: '--configuration Release'
          displayName: 'build'
     
        - script: cp -v mySolution.UI/appsettings.json $(build.ArtifactStagingDirectory)
          displayName: 'Copy appsettings.json to artifacts folder'
       
        - task: DotNetCoreCLI@2
          inputs:
           command: 'publish'
           publishWebProjects: false
           projects: '**/mySolution.WebJobs.csproj'
           arguments: '--output $(Build.BinariesDirectory)/publish_output/App_Data/jobs/triggered/myWebJob  -r win-x64 --self-contained false'
           zipAfterPublish: false
           modifyOutputPath: false
          displayName: 'Publish myWebJob'

        - task: DotNetCoreCLI@2
          inputs:
            command: 'publish'
            publishWebProjects: true
            arguments: '--output $(Build.BinariesDirectory)/publish_output'
            zipAfterPublish: false
            modifyOutputPath: false
          displayName: 'Publish Web App'

        - task: ArchiveFiles@2
          inputs:
             rootFolderOrFile: '$(Build.BinariesDirectory)/publish_output'
             includeRootFolder: false
             archiveType: 'zip'
             archiveFile: '$(Build.artifactStagingDirectory)/$(Build.BuildId).zip'
             replaceExistingArchive: true
          displayName: 'Archive Files'
          
        - task: PublishBuildArtifacts@1
          inputs:
            PathtoPublish: '$(Build.ArtifactStagingDirectory)'
            ArtifactName: 'drop'
            publishLocation: 'Container'

可能的原因 #

1. 部署模式自动触发：使用ZipDeploy部署时，若PROD环境的App Service曾通过ARM模板、Azure CLI等方式启用过「运行从包」模式，Azure会自动维护WEBSITE_RUN_FROM_PACKAGE变量。即使手动删除，后续流水线的ZipDeploy操作可能再次触发该模式启用。
2. PROD环境配置隐性差异：
   • App Service的「部署中心」可能残留了其他持续部署源的配置，与DevOps流水线冲突；
   • PROD的App Service SKU或特性与DEV/TEST不同，部分高级SKU默认倾向启用「运行从包」模式；
   • 曾在PROD环境启用过持续部署功能，相关配置未完全清理。
3. 部署任务的隐性行为：即使YAML未显式设置，Azure App Service部署任务在检测到Web Job存在时，可能因PROD环境的部署历史、缓存与DEV/TEST不同，自动启用「运行从包」模式。

解决步骤 #

1. 显式禁用「运行从包」模式：在Azure DevOps的部署任务YAML中添加enableRunFromPackage: false参数，强制关闭该模式：

   - task: AzureWebApp@1
     inputs:
       azureSubscription: '<你的PROD订阅>'
       appName: '<你的PROD App Service名称>'
       package: '$(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip'
       enableRunFromPackage: false
   

2. 检查PROD App Service配置：
   • 进入App Service门户「部署中心」，确认未启用其他持续部署源；
   • 查看「配置」>「常规设置」，将「运行从包」选项设置为「关闭」；
   • 排查是否有ARM模板或Azure CLI脚本在后台修改App Service配置。
3. 清理部署缓存：
   • 通过Kudu控制台（https://<app-service-name>.scm.azurewebsites.net/DebugConsole）删除D:\home\data\SitePackages下的旧包文件；
   • 重启App Service，确保缓存完全清除。
4. 对比Web Job配置：检查出现问题的解决方案中Web Job的settings.job文件，确认无特殊配置；对比正常解决方案的Web Job部署路径和参数，确保一致。

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