ASP.NET Core servicing 更新准备指南递增 AspNetCorePatchVersion 的全链路解析【免费下载链接】aspnetcoreASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.项目地址: https://gitcode.com/GitHub_Trending/as/aspnetcore在 aspnetcore 仓库中发布一个新的 servicing补丁版本并非简单的改一个数字而是需要让仓库中所有版本号、targeting pack 解析、安装包产物与基线检查逻辑都正确感知这次升级。本文以仓库维护文档 docs/PreparingPatchUpdates.md 为骨架结合 eng/Versions.props 与 docs/Servicing.md 等工程化细节讲解如何为构建一个新的 servicing update 做准备读者将掌握 patch 版本号应改在哪里、它如何沿构建管线向下游流动、以及递增后必须留意的连带影响与验证要点。servicing 更新是什么为何需要单独准备仓库在 ASP.NET Core 的发布策略中团队会同时维护多个已发布版本并持续为之产出补丁patch。所谓 servicing build就是在已发布的major.minor版本之上仅包含缺陷修复、安全与合规修复等低风险变更的增量构建例如8.0.x系列中从8.0.7升到8.0.8。相关的准入标准servicing bar与审批流程在 docs/Servicing.md 中有完整定义其核心约束包括影响大量用户且没有合适 workaround 的缺陷不允许改动公共 API应用必须与某个major.minor的所有patch 保持二进制兼容行为变更必须用于修复异常/崩溃等意外问题或位于 opt-in 配置之后修复需经过 .NET Shiproom由 runtime、libraries、app models、sdk 等各方利益相关者参加的评审以servicing-consider→servicing-approved/servicing-more-info/servicing-rejected标签流程把关。由于 servicing 分支release/*上的改动必须小而稳构建它们的版本基础设施同样需要被精确控制。这正是 docs/PreparingPatchUpdates.md 存在的意义——它是一份面向维护者的建新补丁前置清单。核心操作递增 eng/Versions.props 中的 patch 版本根据 docs/PreparingPatchUpdates.md让本仓库准备好构建一个新 servicing update需要修改仓库根目录下 eng/Versions.props 文件中的 patch 版本号- AspNetCorePatchVersion7/AspNetCorePatchVersion AspNetCorePatchVersion8/AspNetCorePatchVersion示例表示从7递增到8对应一次 7.x → 8.x 的补丁发布。该文件位于eng/Versions.props注意是eng/目录而非仓库根目录属于Version settings属性组当前仓库取值可见 eng/Versions.propsAspNetCoreMajorVersion11/AspNetCoreMajorVersion AspNetCoreMinorVersion0/AspNetCoreMinorVersion AspNetCorePatchVersion0/AspNetCorePatchVersion即版本三元组的语义为AspNetCoreMajorVersion.AspNetCoreMinorVersion.AspNetCorePatchVersion。当团队基于某个已发布版本开新补丁分支时通常会把AspNetCorePatchVersion置为下一个待发布的补丁号并把PreReleaseVersionLabel调整为servicing见下文。patch 版本号如何向下游流动一张依赖网AspNetCorePatchVersion不是孤立的值它是整个仓库版本装配的源头。从 eng/Versions.props 可以看到它参与构造了一系列派生版本派生属性定义作用VersionPrefix$(AspNetCoreMajorMinorVersion).$(AspNetCorePatchVersion)产品包与框架的主要版本前缀如11.0.8TargetingPackVersionPrefix$(VersionPrefix)供.deb、.rpm等使用不同版本格式的产物ExperimentalVersionPrefix0.$(AspNetCoreMajorVersion).$(AspNetCorePatchVersion)实验性包版本前缀AspNetCoreModuleVersionRevision$(AspNetCorePatchVersion)ANCM 模块版本的最后一段PreviousAspNetCoreReleaseVersion$(AspNetCoreMajorMinorVersion).$(patch-1)patch≠0 时用于校验生成的代码与基线是否与上一版本一致IsServicingBuildPreReleaseVersionLabel servicing时为 true切换 servicing 构建的特殊行为其中两点尤其值得展开ANCM 模块版本的特殊编码。eng/Versions.props 中注释说明AspNetCoreModuleVersionMajor故意取10 AspNetCoreMajorVersion因为更早版本的 ANCM 以 8.x 发布过。因此递增 patch 会同步影响 IIS 的 AspNetCore Module 版本号 revision 段。上一版本号的自动推导。PreviousAspNetCoreReleaseVersion是AspNetCoreMajorMinorVersion加上用 MSBuild 函数$([MSBuild]::Subtract(...))计算出的patch - 1且仅在 patch 非 0 时生效。其注释指出它用于错误检查确保在递增 patch 后生成的代码与基线baseline已同步更新。这意味着仅仅改数字是不够的——CI/构建过程会用新旧版本号做差异校验提醒维护者把尚未纳入补丁的基线改动补齐。补丁版本在构建产物中的落地patch 版本最终会进入实际的框架产物。仓库内多处构建文件直接消费AspNetCorePatchVersionsrc/Framework/App.Ref/src/Microsoft.AspNetCore.App.Ref.sfxprojref packMicrosoft.AspNetCore.App.Ref的PatchVersionsrc/Framework/App.Runtime/src/Microsoft.AspNetCore.App.Runtime.sfxprojruntime packMicrosoft.AspNetCore.App.Runtime的PatchVersion注释说明了它如何把M.N.P-PreReleaseLabel-Build形式的 PackageVersion 转换为安装包使用的M.N.P~PreReleaseLabel-Build形式src/Framework/App.Runtime/bundle/aspnetcore-runtime-bundle.bundleprojruntime bundle 安装器的PatchVersion。可以推断当AspNetCorePatchVersion递增后ref pack、runtime pack 与自包含安装包会统一以新版本号产出保证框架版本在整个发布物中自洽。递增 patch 的连带影响生成文件与 targeting pack需要特别留意的是AspNetCorePatchVersion还会被模板化注入到构建阶段生成的文件中。eng/tools/GenerateFiles/GenerateFiles.csproj 中的GenerateDirectoryBuildFiles目标通过GenerateFileFromTemplate任务将AspNetCorePatchVersion、MicrosoftAspNetCoreAppRefVersion等属性渲染进Directory.Build.props/Directory.Build.targets模板生成到artifacts/bin/GenerateFiles/下。随后生成的 eng/tools/GenerateFiles/Directory.Build.targets.in 中出现了与 patch 版本直接相关的条件逻辑!-- Do not update %(TargetingPackVersion) until X.Y.0 versions have been released. -- TargetingPackVersion Condition %(TargetFramework) ${DefaultNetCoreTargetFramework} AND ${AspNetCorePatchVersion} ! 1 ${MicrosoftAspNetCoreAppRefVersion}/TargetingPackVersion这里揭示了 servicing 场景下的一个重要规则在X.Y.0正式发布之前不能更新 targeting pack 版本而对于某个补丁序列如首次补丁X.Y.1条件! 1使得它不会把 targeting pack 版本提升到尚未正式发布的新版。也就是说递增 patch 版本号时需要理解 ref pack 与 runtime pack 的更新节奏并不完全相同——runtime pack 会随补丁更新而 targeting pack 的刷新则受X.Y.0发布节点的制约。此外servicing build 有独特的框架解析行为eng/tools/GenerateFiles/Directory.Build.targets.in 的注释表明当在 servicing 中构建产品代码时除非必要否则不使用刚构建的 ASP.NET Core shared framework通过IsServicingBuild开关控制DefaultRuntimeFrameworkVersion是否生效以避免补丁构建期间意外依赖自身尚未发布的新版本。递增后的验证与整体流程回顾递增 patch 版本并提交到目标release/分支后维护者应当运行常规构建确认VersionPrefix、ref/runtime pack 均按新版本号产出关注基线/生成文件校验PreviousAspNetCoreReleaseVersion对应的错误检查会提示GeneratedCode与 API baseline 是否需要随 patch 递增而更新相关资源如 eng/PublicAPI.empty.txt、eng/GenAPI.exclusions.txt 正是这类基线文件的例子servicing 中不允许公共 API 变更也与此呼应对照 servicing 流程详见 docs/Servicing.md补丁中的每个改动 PR 都需打上servicing-consider标签等待 Shiproom 评审经servicing-approved后由仓库管理员在分支开放时统一合入。综上docs/PreparingPatchUpdates.md看似只有一条 diff背后却是整套版本装配、产物编码与基线校验机制的协同。理解AspNetCorePatchVersion从 eng/Versions.props 出发、流经 ref/runtime pack 与 GenerateFiles 生成文件的全过程才能在准备 servicing 更新时做到改动最小、影响可控并符合 servicing 发布对稳定性的最高要求。【免费下载链接】aspnetcoreASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.项目地址: https://gitcode.com/GitHub_Trending/as/aspnetcore创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ASP.NET Core servicing 更新准备指南：递增 AspNetCorePatchVersion 的全链路解析
ASP.NET Core servicing 更新准备指南递增 AspNetCorePatchVersion 的全链路解析【免费下载链接】aspnetcoreASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.项目地址: https://gitcode.com/GitHub_Trending/as/aspnetcore在 aspnetcore 仓库中发布一个新的 servicing补丁版本并非简单的改一个数字而是需要让仓库中所有版本号、targeting pack 解析、安装包产物与基线检查逻辑都正确感知这次升级。本文以仓库维护文档 docs/PreparingPatchUpdates.md 为骨架结合 eng/Versions.props 与 docs/Servicing.md 等工程化细节讲解如何为构建一个新的 servicing update 做准备读者将掌握 patch 版本号应改在哪里、它如何沿构建管线向下游流动、以及递增后必须留意的连带影响与验证要点。servicing 更新是什么为何需要单独准备仓库在 ASP.NET Core 的发布策略中团队会同时维护多个已发布版本并持续为之产出补丁patch。所谓 servicing build就是在已发布的major.minor版本之上仅包含缺陷修复、安全与合规修复等低风险变更的增量构建例如8.0.x系列中从8.0.7升到8.0.8。相关的准入标准servicing bar与审批流程在 docs/Servicing.md 中有完整定义其核心约束包括影响大量用户且没有合适 workaround 的缺陷不允许改动公共 API应用必须与某个major.minor的所有patch 保持二进制兼容行为变更必须用于修复异常/崩溃等意外问题或位于 opt-in 配置之后修复需经过 .NET Shiproom由 runtime、libraries、app models、sdk 等各方利益相关者参加的评审以servicing-consider→servicing-approved/servicing-more-info/servicing-rejected标签流程把关。由于 servicing 分支release/*上的改动必须小而稳构建它们的版本基础设施同样需要被精确控制。这正是 docs/PreparingPatchUpdates.md 存在的意义——它是一份面向维护者的建新补丁前置清单。核心操作递增 eng/Versions.props 中的 patch 版本根据 docs/PreparingPatchUpdates.md让本仓库准备好构建一个新 servicing update需要修改仓库根目录下 eng/Versions.props 文件中的 patch 版本号- AspNetCorePatchVersion7/AspNetCorePatchVersion AspNetCorePatchVersion8/AspNetCorePatchVersion示例表示从7递增到8对应一次 7.x → 8.x 的补丁发布。该文件位于eng/Versions.props注意是eng/目录而非仓库根目录属于Version settings属性组当前仓库取值可见 eng/Versions.propsAspNetCoreMajorVersion11/AspNetCoreMajorVersion AspNetCoreMinorVersion0/AspNetCoreMinorVersion AspNetCorePatchVersion0/AspNetCorePatchVersion即版本三元组的语义为AspNetCoreMajorVersion.AspNetCoreMinorVersion.AspNetCorePatchVersion。当团队基于某个已发布版本开新补丁分支时通常会把AspNetCorePatchVersion置为下一个待发布的补丁号并把PreReleaseVersionLabel调整为servicing见下文。patch 版本号如何向下游流动一张依赖网AspNetCorePatchVersion不是孤立的值它是整个仓库版本装配的源头。从 eng/Versions.props 可以看到它参与构造了一系列派生版本派生属性定义作用VersionPrefix$(AspNetCoreMajorMinorVersion).$(AspNetCorePatchVersion)产品包与框架的主要版本前缀如11.0.8TargetingPackVersionPrefix$(VersionPrefix)供.deb、.rpm等使用不同版本格式的产物ExperimentalVersionPrefix0.$(AspNetCoreMajorVersion).$(AspNetCorePatchVersion)实验性包版本前缀AspNetCoreModuleVersionRevision$(AspNetCorePatchVersion)ANCM 模块版本的最后一段PreviousAspNetCoreReleaseVersion$(AspNetCoreMajorMinorVersion).$(patch-1)patch≠0 时用于校验生成的代码与基线是否与上一版本一致IsServicingBuildPreReleaseVersionLabel servicing时为 true切换 servicing 构建的特殊行为其中两点尤其值得展开ANCM 模块版本的特殊编码。eng/Versions.props 中注释说明AspNetCoreModuleVersionMajor故意取10 AspNetCoreMajorVersion因为更早版本的 ANCM 以 8.x 发布过。因此递增 patch 会同步影响 IIS 的 AspNetCore Module 版本号 revision 段。上一版本号的自动推导。PreviousAspNetCoreReleaseVersion是AspNetCoreMajorMinorVersion加上用 MSBuild 函数$([MSBuild]::Subtract(...))计算出的patch - 1且仅在 patch 非 0 时生效。其注释指出它用于错误检查确保在递增 patch 后生成的代码与基线baseline已同步更新。这意味着仅仅改数字是不够的——CI/构建过程会用新旧版本号做差异校验提醒维护者把尚未纳入补丁的基线改动补齐。补丁版本在构建产物中的落地patch 版本最终会进入实际的框架产物。仓库内多处构建文件直接消费AspNetCorePatchVersionsrc/Framework/App.Ref/src/Microsoft.AspNetCore.App.Ref.sfxprojref packMicrosoft.AspNetCore.App.Ref的PatchVersionsrc/Framework/App.Runtime/src/Microsoft.AspNetCore.App.Runtime.sfxprojruntime packMicrosoft.AspNetCore.App.Runtime的PatchVersion注释说明了它如何把M.N.P-PreReleaseLabel-Build形式的 PackageVersion 转换为安装包使用的M.N.P~PreReleaseLabel-Build形式src/Framework/App.Runtime/bundle/aspnetcore-runtime-bundle.bundleprojruntime bundle 安装器的PatchVersion。可以推断当AspNetCorePatchVersion递增后ref pack、runtime pack 与自包含安装包会统一以新版本号产出保证框架版本在整个发布物中自洽。递增 patch 的连带影响生成文件与 targeting pack需要特别留意的是AspNetCorePatchVersion还会被模板化注入到构建阶段生成的文件中。eng/tools/GenerateFiles/GenerateFiles.csproj 中的GenerateDirectoryBuildFiles目标通过GenerateFileFromTemplate任务将AspNetCorePatchVersion、MicrosoftAspNetCoreAppRefVersion等属性渲染进Directory.Build.props/Directory.Build.targets模板生成到artifacts/bin/GenerateFiles/下。随后生成的 eng/tools/GenerateFiles/Directory.Build.targets.in 中出现了与 patch 版本直接相关的条件逻辑!-- Do not update %(TargetingPackVersion) until X.Y.0 versions have been released. -- TargetingPackVersion Condition %(TargetFramework) ${DefaultNetCoreTargetFramework} AND ${AspNetCorePatchVersion} ! 1 ${MicrosoftAspNetCoreAppRefVersion}/TargetingPackVersion这里揭示了 servicing 场景下的一个重要规则在X.Y.0正式发布之前不能更新 targeting pack 版本而对于某个补丁序列如首次补丁X.Y.1条件! 1使得它不会把 targeting pack 版本提升到尚未正式发布的新版。也就是说递增 patch 版本号时需要理解 ref pack 与 runtime pack 的更新节奏并不完全相同——runtime pack 会随补丁更新而 targeting pack 的刷新则受X.Y.0发布节点的制约。此外servicing build 有独特的框架解析行为eng/tools/GenerateFiles/Directory.Build.targets.in 的注释表明当在 servicing 中构建产品代码时除非必要否则不使用刚构建的 ASP.NET Core shared framework通过IsServicingBuild开关控制DefaultRuntimeFrameworkVersion是否生效以避免补丁构建期间意外依赖自身尚未发布的新版本。递增后的验证与整体流程回顾递增 patch 版本并提交到目标release/分支后维护者应当运行常规构建确认VersionPrefix、ref/runtime pack 均按新版本号产出关注基线/生成文件校验PreviousAspNetCoreReleaseVersion对应的错误检查会提示GeneratedCode与 API baseline 是否需要随 patch 递增而更新相关资源如 eng/PublicAPI.empty.txt、eng/GenAPI.exclusions.txt 正是这类基线文件的例子servicing 中不允许公共 API 变更也与此呼应对照 servicing 流程详见 docs/Servicing.md补丁中的每个改动 PR 都需打上servicing-consider标签等待 Shiproom 评审经servicing-approved后由仓库管理员在分支开放时统一合入。综上docs/PreparingPatchUpdates.md看似只有一条 diff背后却是整套版本装配、产物编码与基线校验机制的协同。理解AspNetCorePatchVersion从 eng/Versions.props 出发、流经 ref/runtime pack 与 GenerateFiles 生成文件的全过程才能在准备 servicing 更新时做到改动最小、影响可控并符合 servicing 发布对稳定性的最高要求。【免费下载链接】aspnetcoreASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.项目地址: https://gitcode.com/GitHub_Trending/as/aspnetcore创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考