VSTS中提交Project A后自动升级Project B NuGet包并构建可行性咨询

嗨，不用为英文表达致歉哈！你的需求完全可以实现，不需要先手动更新Project A的引用再提交——下面给你详细拆解具体的实现步骤和注意事项：

核心实现思路 #

利用VSTS构建管道的任务编排，在编译Project A之前自动执行NuGet包更新操作，甚至可以把更新后的引用自动提交回仓库（可选）。

前提准备 #

确保Project B生成的NuGet包已经发布到VSTS的私有NuGet源，或者构建代理能够访问的其他NuGet源中。

具体步骤 #

1. 配置Project A的构建管道

   • 打开Project A的构建定义，在现有编译任务（比如VSBuild）之前添加一个NuGet Command任务。
   • 在任务的“Command”下拉框选择update，然后在“Arguments”里填写：

     YourProjectA.sln -Id YourProjectBNuGetPackageId -Latest
     

     这里的YourProjectBNuGetPackageId是Project B生成的NuGet包的唯一ID，-Latest参数会强制更新到该包的最新稳定版本。如果你的解决方案用的是packages.config，也可以直接指定这个文件路径代替sln。

2. 可选：自动提交更新后的引用到仓库
   如果希望把自动升级后的NuGet引用（比如.csproj或packages.config里的版本号变更）保留到代码仓库中，可以在构建管道的最后添加一组Git操作任务：

   • 添加Command Line任务，执行Git命令提交变更：

     git add .
     git commit -m "Auto-update Project B NuGet package to latest version [CI]"
     

   • 再添加一个Command Line任务执行推送：

     git push origin master
     

     注意：需要确保VSTS的构建服务账号拥有Project A仓库的提交和推送权限，同时要考虑可能的代码冲突（比如构建期间有其他提交），可以在提交前添加git pull命令拉取最新代码。

3. 验证与测试
   提交一次Project A的master分支代码，触发构建管道，查看日志确认NuGet包更新任务是否成功执行，然后检查编译结果是否正常。

对比手动方式 #

手动更新Project A的引用再提交当然可行，但自动方案更适合持续集成的场景，能减少重复操作，确保每次构建都使用Project B的最新稳定包。

注意事项 #

• 如果你想限制更新的版本范围（比如只更新小版本），可以把-Latest换成具体的版本范围参数，比如-Version [1.0,2.0)。
• 确保构建代理能够访问到Project B的NuGet源，如果是VSTS私有源，需要在NuGet任务中配置对应的源凭据。

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