如何在MSBuild执行前通过构建脚本可靠编辑.NET SDK风格.csproj文件中的<Version>元素？

好问题！用XPath定位<PropertyGroup>下的<Version>元素确实比正则表达式靠谱得多，但它并非绝对完美。我们来拆解一下不同方案的可靠性，并推荐更稳妥的做法：

一、XPath方案的可靠性分析 #

• 优势：相比正则的模糊匹配，XPath可以精准定位目标节点，比如使用//PropertyGroup/Version[not(ancestor::PackageReference)]这样的查询，能明确排除嵌套在<PackageReference>里的<Version>元素，从根本上避免误修改的问题。
• 潜在坑点：
  • 命名空间问题：SDK风格的.csproj默认带有命名空间xmlns="http://schemas.microsoft.com/developer/msbuild/2003"，如果你的XPath查询没有处理命名空间，会直接查不到节点，这是很多人忽略的细节。
  • 多配置PropertyGroup：项目中可能存在多个<PropertyGroup>（比如对应Debug/Release等不同配置），如果XPath不够精确，可能会同时修改多个版本号，导致配置不一致。
  • 版本定义位置：如果版本号是定义在Directory.Build.props而非项目本身的.csproj里，修改项目文件就完全起不到作用。

二、更可靠的替代方案 #

1. 直接通过MSBuild参数传递版本号（最推荐） #

这是.NET官方推荐的方式，完全不需要修改任何XML文件，直接在构建命令中传入版本参数：

# 针对传统MSBuild
msbuild /p:Version=1.2.3.4 YourSolution.sln

# 针对.NET CLI
dotnet build /p:Version=1.2.3.4 YourSolution.sln

MSBuild会自动使用这个参数覆盖项目中定义的<Version>属性，而且绝对不会影响<PackageReference>里的版本号，安全又高效。如果需要设置预发布版本，还可以用/p:PackageVersion=1.2.3-beta1（如果和Version不同的话）。

2. 统一修改Directory.Build.props #

如果你的解决方案包含多个项目，建议在解决方案根目录创建Directory.Build.props文件，集中管理版本号：

<Project>
  <PropertyGroup>
    <Version>1.2.3.4</Version>
  </PropertyGroup>
</Project>

所有子项目会自动继承这个版本号。你的脚本只需要修改这一个文件的<Version>元素即可（同样可以用XPath，但因为文件结构更简单，出错概率更低）。

3. 使用专门的版本管理工具 #

比如dotnet-setversion，这是一个官方生态的工具，专门用来设置.NET项目版本：
首先安装工具：

dotnet tool install -g dotnet-setversion

然后在项目目录或解决方案目录执行：

dotnet setversion 1.2.3.4

它会自动识别项目中正确的<Version>元素（只会修改PropertyGroup下的，不会碰PackageReference），完全不用自己处理XML解析的问题。

总结 #

XPath方案比正则表达式可靠，但仍存在XML解析相关的潜在问题。最稳妥的方式是直接通过MSBuild参数传递版本号，或者使用专门的工具，这两种方式都能彻底避免手动编辑XML带来的各种坑。

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