基于VSTS CI构建C#类库并推送NuGet包的相关技术问题

针对你的两个问题，我整理了实用的解决方案和建议：

有几种靠谱的方式来设置NuGet包名称，你可以根据自己的项目类型选最合适的：

• 通过项目文件（.csproj）配置（推荐SDK-style项目）
  如果你的类库用的是SDK风格的.csproj（比如.NET Core/.NET 5+，或者升级后的.NET Framework SDK格式项目），直接在项目文件里添加<PackageId>节点就能指定包名：

  <PropertyGroup>
    <PackageId>Your.Custom.Package.Name</PackageId>
    <!-- 顺便可以在这里统一配置版本、作者等其他包信息 -->
    <Version>1.0.0</Version>
  </PropertyGroup>
  

  这种方式最好，因为包名和项目代码绑定，团队所有人都能看到，构建时也不容易出错。

• 通过NuSpec文件配置（适合传统.NET Framework项目）
  要是你的项目是传统的非SDK格式.NET Framework类库，就创建一个.nuspec文件，在<metadata>节点里设置<id>字段：

  <?xml version="1.0"?>
  <package>
    <metadata>
      <id>Your.Custom.Package.Name</id>
      <version>1.0.0</version>
      <!-- 其他必填的元数据比如作者、描述也记得加上 -->
    </metadata>
  </package>
  

  然后在VSTS的NuGet打包任务里指定这个nuspec文件的路径就行。

• 在VSTS构建任务中临时覆盖（仅临时场景用）
  如果你只是临时改一次包名，可以在NuGet打包任务（不管是NuGetCommand还是DotNetCoreCLI任务）的命令参数里加-id参数。比如用DotNetCLI任务的话，命令行参数可以这么写：

  pack --configuration $(BuildConfiguration) -id Your.Temp.Package.Name
  

  但这种方式不建议长期用，因为配置只在构建任务里，团队其他人可能不知道，容易造成包名不一致的问题。

既然你的.NET 4.0分支构建已经正常跑起来了，这里给几个小建议帮你维护好这个遗留项目的构建流程：

• 区分NuGet包标识
  为了避免和原.NET 4.7.2版本的包搞混，建议给.NET 4.0版本的包加个后缀——要么把包名改成Your.Package.Name.Net40，要么在版本号里加后缀（比如1.0.0-net40）。这样在私有NuGet源里能一眼区分两个版本，使用的时候也不会选错。

• 精准配置构建触发器
  确保新的CI构建只触发.NET 4.0分支的代码提交，别让原分支的改动误触发它。在VSTS构建的「触发器」设置里，把分支过滤规则改成只包含你的.NET 4.0分支（比如refs/heads/net40）。

• 添加兼容性测试步骤
  可以在构建流程里加个测试环节，用.NET 4.0版本的测试项目（比如NUnit或xUnit的.NET 4.0适配版）来验证移植后的类库功能是否正常，避免把有问题的包推送到私有源。

• 共享通用构建配置
  如果原.NET 4.7.2的构建有一些通用配置（比如NuGet推送的源地址、认证信息），可以把这些做成VSTS的变量组，让两个构建任务共享。这样后续修改的时候只需要改一次，不用两个构建都调整，省事儿还不容易出错。

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