如何通过Azure管道更新appsettings.json的Version并注入构建号

核心方案是使用Azure Pipelines原生的JSON文件转换能力配合内置构建号变量实现，零自定义脚本、不会破坏JSON结构、不影响本地开发配置，是稳定性最高的实现方式。

具体实施步骤 #

• 确认构建号规则
  Azure管道每次执行构建时会自动生成全局唯一的构建号，对应预定义变量为Build.BuildNumber，不需要额外编写生成编号的逻辑。如果需要自定义编号格式，可以直接在管道的「选项-构建号格式」中配置，比如设置为$(Date:yyyyMMdd).$(Rev:r)就能生成20240520.1格式的、按日期+当日构建序号递增的编号，完全满足每次构建生成新编号的要求。
• 保留本地AppSettings.json的原有配置
  本地开发环境不需要做任何改动，Version字段保持默认值"Dev"即可，不会影响本地调试，也不会把构建过程生成的动态编号提交到代码仓库。
• 在管道中添加文件转换任务
  在构建步骤（.NET项目建议放在dotnet publish之前，或者部署阶段放在部署到目标环境之前）添加官方的「File Transform（文件转换）」任务，按以下参数配置：
  • 转换类型选择JSON
  • 目标文件路径填写AppSettings.json相对于代码仓库根目录的相对路径，比如你的配置文件在Web项目根目录就填src/YourProjectName/AppSettings.json
  • 在变量替换规则中添加替换项：节点路径填AppSettings.Version，对应值填$(Build.BuildNumber)
    这个任务是直接解析JSON结构做节点值替换，不会改动其他配置项，也不会破坏JSON格式，完全不会出现正则替换常见的错替换、格式损坏问题。
• 业务侧无需改动读取逻辑
  管道执行时会自动把发布包内的AppSettings.json对应字段替换为当次构建号，你原有读取AppSettings配置的代码不需要做任何调整，直接把读到的Version值渲染到网站Logo位置即可。

避坑提示 #

不要自己写PowerShell/Shell脚本用正则匹配的方式替换JSON内容：JSON的格式、空格、注释、同名字段都可能导致正则匹配失效，轻则替换失败，重则破坏JSON结构导致应用启动报错，原生JSON转换任务的稳定性远高于自定义脚本。

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