Azure App Service部署.NET 6应用启动失败及静态资源加载问题

问题1：部署成功但应用无法加载，提示找不到Change Management.dll和.NET SDK #

原因分析 #

1. 带空格的DLL名称兼容性问题：Linux环境对文件名空格的处理与Windows不同，Change Management.dll的空格可能导致解析失败，或打包过程中该DLL未被正确包含。
2. .NET运行时/SDK配置不匹配：Linux版Azure App Service未默认安装对应.NET SDK（若部署依赖SDK而非仅运行时），或运行时版本未正确指定。
3. WEBSITE_RUN_FROM_PACKAGE的运行限制：启用该变量后，App Service直接从压缩包运行，若压缩包未包含完整依赖文件（如目标DLL、运行时组件），会触发加载失败。

解决方案 #

• 修正DLL名称：将项目中该DLL的引用名改为无空格格式（如ChangeManagement.dll），重新编译打包，规避Linux文件名解析问题。
• 配置.NET运行时：
  在Azure Portal的App Service「配置-环境变量」中，添加DOTNET_VERSION变量，值设为6.0.x（匹配你的.NET 6具体版本）。
  若仅需运行时，打包时使用命令：dotnet publish --configuration Release --runtime linux-x64 --self-contained false，确保仅包含运行时依赖。
• 验证压缩包完整性：解压部署包，确认Change Management.dll存在于主程序DLL同级目录，且所有依赖项完整。

问题2：调整部署方式后应用可加载，但静态资源404，存在两层wwwroot目录 #

原因分析 #

流水线YAML的打包步骤配置错误，导致压缩包内出现嵌套的wwwroot目录（如wwwroot/wwwroot/），而.NET应用默认从根目录下的一级wwwroot读取静态资源，路径不匹配引发404。

解决方案 #

修正YAML打包逻辑

检查流水线的归档任务，确保直接打包发布输出的根目录内容，而非包含上层目录。
错误示例：

- task: ArchiveFiles@2
  inputs:
    rootFolderOrFile: '$(Build.ArtifactStagingDirectory)/publish'
    includeRootFolder: true  # 会将publish目录作为根目录，导致压缩包内出现publish/wwwroot
    archiveType: 'zip'
    archiveFile: '$(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip'
    replaceExistingArchive: true

修正后配置：

- task: ArchiveFiles@2
  inputs:
    rootFolderOrFile: '$(Build.ArtifactStagingDirectory)/publish'
    includeRootFolder: false  # 直接打包publish内的所有文件，确保wwwroot为一级目录
    archiveType: 'zip'
    archiveFile: '$(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip'
    replaceExistingArchive: true

验证目录结构

部署后通过Kudu工具（https://<你的应用名>.scm.azurewebsites.net/）查看网站根目录，确认wwwroot为一级目录，静态资源直接存放在该目录下。

临时 workaround（不推荐）

若无法修改流水线，可在Program.cs中手动指定静态资源路径：

app.UseStaticFiles(new StaticFileOptions
{
    FileProvider = new PhysicalFileProvider(
        Path.Combine(Directory.GetCurrentDirectory(), "wwwroot", "wwwroot")),
    RequestPath = ""
});

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