我正在开发一个包含250多个项目的大型解决方案。使用Visual Studio Nuget UI或Nuget命令行工具时，更新在所有这些项目中使用的公共Nuget包需要2到3个小时。我想通过手动更新文件来更快地完成这项工作。
我的第一个想法是，我只需要更新每个项目的*.config文件中的软件包版本号。例如，查找并替换
<package id="ThisPackage" version="0.0.0.1" targetFramework="net452" />
与
<package id="ThisPackage" version="0.0.0.2" targetFramework="net452" />
这似乎是当您通过VS Nuget UI执行更新时实际发生的事情，所以我想这样做然后重建解决方案会处理所有事情，有点像手动编辑package.json中的依赖项和然后在Node中运行npm install。
然而，这不起作用; .csproj文件中的引用不会像Nuget更新配置文件时那样在构建时更新。
我也可以手动更新.csproj文件，例如通过查找和替换
<HintPath>..\..\packages\ThisPackage.0.0.0.1\
与
<HintPath>..\..\packages\ThisPackage.0.0.0.2\
但是大概我还需要更新引用的程序集版本，我不知道如何计算出给定版本的Nuget包它们应该是什么。此外，虽然大约半小时的工作而不是3小时的死亡时间，但它有点繁琐且容易出错。
有没有人找到一种方法来在一个不需要多个小时的解决方案中更新大量项目中的Nuget包？
答案 0 :(得分：3)
软件包更新时间包括下载软件包和卸载/安装软件包。第一次下载时，下载操作只执行一次，因此卸载/安装操作几乎占用所有更新时间。因此，您可以接受Kiliman的建议，首先检查您的机器性能。
如果您想根据您的步骤手动更新所有这些包。您可以按照以下步骤缩短更新时间：
答案 1 :(得分：0)
我不会尝试手动更新软件包，除非您使用的是将NuGet软件包视为一等公民的.NET Core。
现在，下载软件包，更新项目引用等等太多了，以至于尝试自己动手做太容易出错。
现在也许真正的问题是为什么更新包需要这么长时间。你有没有添加其他NuGet存储库？也许其中一个是超时。
您是否尝试过运行Fiddler以查看是否存在无关的网络请求？问题是在所有机器上发生还是仅在特定机器上发生？他们是开发人员工作站还是构建服务器？