Azure DevOps部署In-Process FunctionApp时出现依赖注入及404错误

针对你遇到的本地发布正常但流水线部署后出现404或依赖注入失败的问题，可从以下几个方向排查修复：

• 修正流水线构建任务的发布逻辑
  本地func azure functionapp publish会自动适配FunctionApp的发布结构，而Azure DevOps的DotNetCoreCLI任务如果配置不当，会将源码、中间构建文件等冗余内容打包进去，导致部署目录混乱。务必使用publish命令生成标准部署包：

  - task: DotNetCoreCLI@2
    inputs:
      command: 'publish'
      publishWebProjects: false
      projects: '**/你的FunctionApp项目.csproj'
      arguments: '--configuration Release --output $(Build.ArtifactStagingDirectory)/publish_output'
      zipAfterPublish: true
  

  避免直接用build命令后复制文件，确保只发布FunctionApp运行所需的文件。

• 验证Startup类的部署有效性

  1. 登录Azure Portal进入FunctionApp的Kudu工具，检查/home/wwwroot下是否存在包含Startup类的主程序集，确认程序集未丢失。
  2. 确认In-Process模式下的Startup配置：必须继承FunctionsStartup，且在程序集级别添加标记[assembly: FunctionsStartup(typeof(你的命名空间.Startup))]，避免流水线构建时该特性被编译优化移除。

• 对比本地与流水线的构建输出差异
  本地执行dotnet publish --configuration Release，将输出目录和流水线生成的发布包对比，排查流水线多出来的冗余文件（如.pdb、源码、其他类库项目的输出）。调整YAML中projects参数，仅指向FunctionApp的csproj文件，避免误打包其他项目。

• 修正部署任务的包路径配置
  使用AzureFunctionApp@1部署任务时，确保package参数精准指向生成的zip包，不要指向整个目录：

  - task: AzureFunctionApp@1
    inputs:
      azureSubscription: '<你的Azure订阅>'
      appType: 'functionApp'
      appName: '<你的FunctionApp名称>'
      package: '$(Build.ArtifactStagingDirectory)/publish_output/*.zip'
      deploymentMethod: 'auto'
  

• 清理旧部署文件
  流水线部署可能未完全覆盖旧文件导致冲突，可通过Kudu手动删除/home/wwwroot下所有文件后重新部署，或在部署任务中启用clean选项（需使用新版任务），确保部署目录干净。

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