Azure Functions：.NET 7下Git部署成功但无函数显示问题求助

优先排查操作配置问题 #

• 确认部署工件类型：.NET Isolated模式的Functions必须部署编译后的发布产物（即dotnet publish输出的bin/Release/netX.x/publish目录内容），而非原始源码。检查Azure DevOps管道是否正确执行了dotnet publish命令，且将publish目录作为部署工件上传，而非直接推送源码根目录。
• 核对部署模式设置：在Azure门户的函数应用「部署中心」，确认部署模式与.NET Isolated运行时匹配，避免使用源码编译模式（该模式针对脚本型函数，不适用于预编译的Isolated项目）。
• 验证运行时版本一致性：在门户「配置→常规设置」中，确认“.NET 隔离进程”的版本与本地开发、编译时使用的.NET版本完全一致，版本不兼容会导致函数宿主无法加载程序集。

对比文件结构的核心差异点 #

• 检查关键文件/目录是否存在：正常部署的site/wwwroot目录应包含：bin目录（存放编译后的DLL）、host.json、各函数对应的子目录（每个目录下有自动生成的function.json）。如果Git部署后的目录缺少这些内容，说明部署的是未编译的源码，而非发布产物。
• 确认function.json的有效性：.NET Isolated模式下的function.json由编译过程自动生成，文件中scriptFile字段需正确指向对应的函数DLL路径。如果部署的是源码，不会生成该文件，门户自然无法识别函数。

深度诊断与验证 #

• 查看宿主启动日志：通过门户「日志流」或Kudu高级工具（https://<your-function-app>.scm.azurewebsites.net/）的「调试控制台→日志→ApplicationLogs」，检查函数宿主启动时是否有程序集加载失败、函数定义未找到等错误。
• 排查部署日志细节：在Azure DevOps的部署任务日志中，确认dotnet publish的输出路径正确，且部署任务将publish目录的所有文件完整上传到了函数应用的site/wwwroot。
• 手动上传验证：将本地dotnet publish生成的publish目录内容，通过Kudu文件管理器上传到site/wwwroot，重启函数应用后查看门户是否显示函数。若手动上传有效，说明Azure DevOps管道配置存在问题。

关于是否为Azure平台Bug的判断 #

若上述所有检查均确认配置正确，且手动上传也无法解决问题，同时启动日志无明确错误，可考虑平台问题：

• 尝试重启函数应用或切换部署槽后重新部署。
• 创建全新的.NET Isolated函数应用，用相同管道部署，验证是否复现问题。
• 查看Azure状态页，确认当前区域的Functions服务无运行异常。

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