Azure DevOps Pipeline无法部署.NET6服务至Azure Service Fabric集群

• Azure Service Fabric集群现有多个ASP.NET Core 2.1无状态服务，运行稳定
• 单服务升级至.NET 6/ASP.NET Core 6后本地测试正常，通过Visual Studio 2022直接发布到集群可正常运行
• 通过Azure DevOps Pipeline的Deploy Service Fabric Application任务部署时，任务无报错，集群中可见应用实例，但服务实例未正常启动
• 同部署任务部署旧版ASP.NET Core 2.1服务无异常
• 部署任务日志出现Removing application from image store记录，流程未识别StartupServices.xml中配置的DNS服务名
• 环境基线：Windows 10 Enterprise、.NET 6 SDK、ASP.NET Core 6.0、Visual Studio 2022 Professional 17.2.5

按优先级从高到低排查：

1. 优先检查部署包路径长度超限 #

这是.NET版本升级后最容易触发的静默失败问题：.NET 6的依赖包嵌套层级比.NET Core 2.1深很多，Azure DevOps Agent默认工作目录路径本身较长，很容易触发Service Fabric 255字符的包路径长度限制。包上传后解压失败时，SF会自动清理镜像存储中的损坏包（对应日志里的Removing application from image store），但部署任务默认不会把这个判定为错误，最终表现为应用壳子创建成功、服务实例完全不启动。

• 修复操作：
  • CI构建时将Service Fabric包输出路径改到短路径，比如直接输出到$(Agent.TempDirectory)\pkg，避免多层工作目录嵌套
  • 在Deploy Service Fabric任务中勾选Compress Package选项，压缩包可大幅降低路径超限概率
  • 解压CI生成的部署包，检查所有文件的全路径长度，确保不超过250字符，删除不必要的嵌套目录

2. 对齐Service Fabric SDK/Runtime版本 #

Visual Studio 2022 17.2.5内置的Service Fabric SDK版本通常高于Azure DevOps托管Windows Agent预装的SDK版本。如果项目中引用的Microsoft.ServiceFabric.AspNetCore.Kestrel等NuGet包版本高于集群SF Runtime版本，会出现服务清单解析失败、DNS配置识别失效的问题。

• 修复操作：
  • 打开SF Explorer首页，查询集群当前运行的SF Runtime版本
  • 将项目中所有Microsoft.ServiceFabric.*开头的NuGet包版本，统一调整为和集群Runtime大版本完全一致，禁止使用高于集群版本的SDK包
  • 如果使用托管Agent，在部署任务前增加PowerShell步骤安装匹配版本的Service Fabric模块，避免使用Agent默认的旧版本：

  # 将版本号替换为集群实际Runtime版本
  Install-Module -Name ServiceFabric -RequiredVersion 9.0.1028.9590 -Force -AllowClobber
  

3. 检查CI发布配置，确保入口文件完整 #

VS直接发布时会自动适配目标框架的发布参数，但Azure DevOps的dotnet publish任务如果未显式指定参数，很可能生成错误的输出结构：比如只输出dll文件、缺少SF要求的exe入口，导致服务激活失败。

• 修复操作：
  • 修改CI中的dotnet publish任务，显式添加发布参数：-c Release -f net6.0 -r win-x64 --self-contained false
  • 检查publish输出目录，确认存在服务对应的exe入口文件，不要保留旧版netcoreapp2.1框架路径的残留配置
  • 核对ServiceManifest.xml中配置的入口点路径，和publish生成的实际exe路径完全一致

4. 确认StartupServices.xml被正确打包 #

.NET 6项目升级后，StartupServices.xml默认不会设置为复制到输出目录：VS本地发布时会自动识别项目根目录的该文件并打包，但CI构建时如果没有显式配置复制规则，这个文件不会进入最终部署包，自然无法识别配置的DNS名称。

• 修复操作：
  • 在项目文件.csproj中添加配置，将文件设置为随构建复制到输出目录：

  <ItemGroup>
    <None Update="StartupServices.xml">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
  </ItemGroup>
  

  • 构建完成后检查部署包，确认服务根目录下存在StartupServices.xml文件

不要仅依赖部署任务日志判断结果：部署完成后直接打开SF Explorer，进入对应应用的服务实例详情页，查看「事件」标签页的激活错误日志，里面会明确标注服务启动失败的具体原因（比如入口缺失、依赖错误、路径超限）。
也可以把CI生成的部署包下载到本地，通过VS的「从现有包部署」功能发布，如果本地部署同样失败，说明问题出在CI构建的包本身，和CD部署任务无关。

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