这几年在VS2022里做.NET项目的团队多少都会碰到同一个问题项目一多NuGet包的文件反复下载、重复占用磁盘内网环境下一还原就报错不同开发人员本地的包版本还不一致。我这次尝试NuGet共享起因也很简单——组里有多个解决方案共用同一批第三方依赖每次新成员拉代码回来还原包都要等半天部分机器还在隔离内网根本连不上nuget.org。于是我把VS2022的NuGet共享方案从头到尾捋了一遍从全局缓存路径调整到本地文件夹源搭建再到离线环境下的包迁移折腾下来算是摸清了底细。这篇文章就是这次尝试的完整记录适合需要给团队统一下依赖、做内网离线开发或者单纯想省点磁盘空间的朋友参考。1. 为什么要把NuGet包“共享”起来1.1 先看一个典型痛点场景假设你手上有三个解决方案一个是Web API一个是后台任务还有一个是工具类控制台程序它们都引用了Newtonsoft.Json、Serilog、OpenCvSharp这些包。默认情况下VS2022的NuGet还原机制会把每个包解压一份到全局缓存目录同时每个项目的输出目录里还会复制一份dll。如果三个解决方案各自维护一份引用磁盘空间就是这么悄悄没的。更麻烦的是离线环境。很多公司项目不能直接访问nuget.org新电脑配好环境之后一执行dotnet restore或VS里的“还原NuGet包”要么卡在超时要么报NU1101找不到包。这个时候如果之前没人做过包共享就只能拿着U盘从有网的机器一个个拷非常痛苦。我这次做NuGet共享本质就是想解决这三件事让同一台机器上的项目不重复下载同一份包、让离线/内网环境的还原能顺利进行、让团队内部依赖版本保持一致。1.2 NuGet共享到底共享的是什么很多刚接触这块的人会有一个误区以为“共享NuGet包”是把dll放到一个公共目录然后项目直接引用这个目录。实际上现代SDK风格项目根本不需要这样操作NuGet的核心机制是“包还原restore”。还原时会按照包ID和版本号去特定的缓存目录里找找到就直接用找不到才去配置的源里下载。所以真正值得共享的内容有三个层面。第一个是全局包缓存也就是同一台机器上多个项目、多个解决方案共用一份已解压的包文件避免重复下载和重复占空间。第二个是包源把一个文件夹或者一台服务器作为NuGet源让团队所有成员的还原请求都从这个源里拿包而不是每个人都直连公网。第三个是版本策略通过配置文件把各项目引用的包版本统一锁定避免“我这能跑你那不行”的经典问题。1.3 三种共享方式的取舍我把常见的共享方式分成三种按投入成本从低到高排了一下共享方式配置成本适用场景局限统一全局包缓存位置低单机多用户、多个解决方案共用跨机器迁移仍要手动处理本地文件夹源中低内网开发、离线还原、小团队包数量多之后不好管理私有NuGet服务器BaGet、Nexus、Azure Artifacts高大团队、CI/CD、精细化权限控制需要服务器和持续维护这次我实际采用的组合是“统一全局缓存目录 本地文件夹源”中间穿插了离线包迁移和版本锁定。这套方案不用搭服务器、不花钱但已经能把90%的依赖共享问题解决掉。等团队规模大到需要权限控制和包审计时再考虑私有服务器也不迟。2. NuGet缓存体系拆解共享前先摸清家底2.1 全局包文件夹global packages folder全局包文件夹是NuGet最核心的缓存位置默认在用户目录下。Windows系统里通常是C:\Users\用户名\.nuget\packages结构大概是这样的C:\Users\用户名\.nuget\packages\ newtownsoft.json\ 13.0.3\ lib\ newtonsoft.json.nuspec newtonsoft.json.13.0.3.nupkg .nupkg.metadata每个包ID对应一个文件夹里面按照版本号再分一层真正的包内容已经解压好了。构建项目时编译器直接引用这里的dll所以“还原之后删掉项目bin目录里的输出文件”并不会真正丢东西只要全局缓存还在重新构建会自动恢复。这也解释了为什么第一次还原慢、之后还原很快——因为大部分包已经命中本地缓存。想查看当前全局缓存路径可以打开命令行执行dotnet nuget locals global-packages --list会输出类似global-packages: C:\Users\xxx\.nuget\packages的结果。如果你设置了环境变量NUGET_PACKAGES这个输出就会变成你指定的路径。2.2 HTTP缓存与临时目录除了全局包文件夹另外两个容易混淆的缓存是HTTP缓存和临时安装目录。HTTP缓存默认在%LOCALAPPDATA%\NuGet\v3-cache它保存的是NuGet客户端从服务器请求元数据时得到的HTTP响应用来减少重复请求但里面不保存完整的包文件内容。清掉HTTP缓存并不会让你丢失已还原的包最多就是下次还原时重新拉一遍元数据速度会略慢一点。临时安装目录一般在系统临时目录下比如%TEMP%\NuGetScratch只在安装、更新包的短暂过程中使用。遇到还原中断、磁盘写满这类异常情况偶尔会有临时文件残留影响不大但可以随手清理。做共享时最容易踩的坑就是只看到全局包文件夹而忽略另外两类缓存。导出包给别人时正确的原料来源是全局包文件夹里的.nupkg文件而不是HTTP缓存。拿HTTP缓存目录里的文件去当离线包源十有八九是缺文件的。2.3 旧式 packages.config 与本地包目录如果你的项目还是老式的.NET Framework项目拖动引用时用的是packages.config而不是PackageReference包的还原逻辑会有点不一样。这种项目默认会在解决方案根目录生成一个packages文件夹里面按包ID.版本号存放包内容项目文件通过相对路径引用dll。对这类项目做共享思路和SDK风格项目不同。你不能再指望全局缓存因为旧项目的还原行为是“把包解压到解决方案的packages目录”。想让团队复用要么把整个packages目录放到共享盘要么保留一份完整的离线包压缩包交给新成员解压到对应位置。VS2022里也可以把老项目迁移到PackageReference模式迁移之后就能享受全局缓存带来的便利了。不过迁移有风险页面级依赖、程序集版本绑定的兼容性都要测我不建议在共享这件事上顺手做大规模迁移。2.4 NuGet.Config 的配置层级NuGet的所有配置都集中在一个叫NuGet.Config的XML文件里但它有多层而且不同层级的配置会合并。按从低到高排列大致是机器级、用户级、解决方案/项目级越靠近项目的配置优先级越高。机器级文件一般在C:\ProgramData\NuGet\Config用户级是%APPDATA%\NuGet\NuGet.Config解决方案级就是放在解决方案根目录下的nuget.config。这个顺序很重要。很多人在用户级里配了本地源结果发现VS还原时根本没走本地源就是因为解决方案根目录存在另一个nuget.config把源列表给覆盖掉了。反过来如果我们想给团队统一配置直接在解决方案根目录放一份nuget.config是最有效的做法它会覆盖成员机器上的用户级设置保证同一个解决方案在任何机器上还原表现一致。3. VS2022实操一步步把NuGet共享配起来3.1 第一步确认当前包源与缓存位置动手之前先看清现状。打开VS2022菜单路径是“工具” - “NuGet包管理器” - “程序包管理器设置”左侧点“包源”能看到当前配置的所有源默认一般有nuget.org。如果你之前装过一些插件或者公司内部源这里可能多出几项。命令行也有对应的查看方式dotnet nuget list source dotnet nuget locals all --list第一条列出当前生效的包源第二条会把全局包文件夹、HTTP缓存、临时目录的位置全部打出来。我习惯先把这些信息截图保存后面改配置出问题时能快速对比。这里有一个容易被忽略的情况VS2022里的包源列表和命令行看到的源可能不完全一样因为VS会额外读取自己的配置有时还会受“程序包源映射”功能影响。后面我会专门讲这个坑。3.2 第二步把全局包缓存改到共享目录为什么要动全局包缓存默认位置在C盘用户目录C盘空间一旦吃紧第一个背锅的就是它。另外如果想在同一台机器的多个用户之间共享已下载的包把缓存挪到一个公共目录会更合理。改法有两种。第一种是设置环境变量NUGET_PACKAGESsetx NUGET_PACKAGES D:\NuGetShared\packages设置完之后要重启终端和VS2022环境变量才会生效。第二种是直接改用户级NuGet.Configconfiguration config add keyglobalPackagesFolder valueD:\NuGetShared\packages / /config /configuration改完保存重新打开VS2022执行一次还原NuGet会在新目录里重建包缓存。原有的旧缓存可以暂时不删等确认所有项目都能正常构建之后再清理。这里要提醒一点不要直接把旧缓存文件夹改名成新目录以为能“继承”缓存。不同项目的缓存里可能会残留损坏的元数据直接拷贝过去有时会让还原报错干净重建反而更稳。3.3 第三步搭建本地文件夹源本地文件夹源是最轻量的包共享方式。原理很简单把一个目录当作NuGet源目录里放.nupkg文件NuGet客户端就能从这个目录还原包。先在本地建一个目录比如D:\NuGetLocalFeed。然后把想共享的包文件放进去。手动从网上下载或从全局缓存复制都行。我一般用PowerShell脚本从全局缓存批量导出这样一条命令就能把当前机器上已还原的所有包都搬到本地源$sourceRoot $env:USERPROFILE\.nuget\packages $destRoot D:\NuGetLocalFeed $packageIds Get-ChildItem $sourceRoot -Directory foreach ($idDir in $packageIds) { $versionDirs Get-ChildItem $idDir.FullName -Directory | Where-Object { $_.Name -notlike .* } foreach ($verDir in $versionDirs) { $nupkg Get-ChildItem $verDir.FullName -Filter *.nupkg | Select-Object -First 1 if ($nupkg) { $dest Join-Path $destRoot $idDir.Name New-Item -ItemType Directory -Force -Path $dest | Out-Null Copy-Item $nupkg.FullName (Join-Path $dest $nupkg.Name) } } }脚本的逻辑是按“包ID/版本号”的目录结构去找.nupkg再按同样的层级复制到目标目录。NuGet的本地源支持平铺目录但按ID分文件夹后在VS的包管理器里浏览起来更清晰。复制完成后在VS2022的包源设置里点“添加”名称填LocalFeed源填D:\NuGetLocalFeed。命令行也可以dotnet nuget add source D:\NuGetLocalFeed -n LocalFeed之后对任何项目执行还原NuGet会先从全局缓存找找不到就按配置的源顺序去本地源找。只要本地源里有对应版本的包即使离线也能还原成功。3.4 第四步离线环境下的包迁移真正被逼着做NuGet共享的多数是离线机器。步骤其实不复杂在一台有网的机器上把需要的.nupkg全部收集好拷贝到目标机器然后在目标机器上把目录配置成本地源。上面那个PowerShell脚本已经可以完成“收集”这一步但要确保收集了传递依赖。光收集主包文件通常不够比如你引用了某ORM框架它底层还依赖日志组件、连接驱动这些传递依赖缺一个还原就会抛NU1101或NU1103。一个比较稳妥的做法是在有网机器上打开目标解决方案执行一次完整的dotnet restore确认没有缺包再用脚本把整个全局缓存里涉及的所有包全部导出而不是只导出你认识的几个主包。这样虽然会多拷贝一些用不上的包但能避免离线机器还原到一半发现缺包。拷贝介质用U盘、移动硬盘或者内网共享目录都可以关键是把D:\NuGetLocalFeed完整拷过去别只拷一部分。目标机器上执行dotnet nuget add source D:\NuGetLocalFeed -n OfflineFeed dotnet restore如果项目设置了锁文件还原会严格按锁文件里的版本去找包本地源里如果没有对应版本依然会失败。所以导出的包最好和锁文件版本完全一致。3.5 第五步用 Directory.Packages.props 锁定版本共享缓存和本地源解决的是“从哪里拿包”的问题但团队里每个人引用的包版本不一致的问题还没有根治。有人项目里写的是13.0.3有人写的是13.0.1还原出来行为当然不一样。VS2022对SDK风格项目支持“集中包管理”也就是Central Package ManagementCPM这个功能强烈建议用起来。做法是在解决方案根目录创建一个Directory.Packages.props文件Project PropertyGroup ManagePackageVersionsCentrallytrue/ManagePackageVersionsCentrally /PropertyGroup ItemGroup PackageVersion IncludeNewtonsoft.Json Version13.0.3 / PackageVersion IncludeSerilog Version3.1.1 / /ItemGroup /Project然后项目文件里的PackageReference就只写包名不写版本ItemGroup PackageReference IncludeNewtonsoft.Json / PackageReference IncludeSerilog / /ItemGroup这样整个解决方案的包版本都由根目录这一个文件管着谁要升级版本改这一处就行。它和本地源是互补关系本地源保证能拿到包中央包管理保证大家拿的是同一个版本。3.6 第六步团队层面统一配置如果只想自己一个人用前面几步已经够了。但给团队统一最好把配置固化到代码仓库里。我会在解决方案根目录放一份nuget.config内容类似下面这样configuration config add keyglobalPackagesFolder valueD:\NuGetShared\packages / /config packageSources clear / add keyLocalFeed valueD:\NuGetLocalFeed / add keynuget.org valuehttps://api.nuget.org/v3/index.json / /packageSources /configuration这里有个非常关键的操作就是在packageSources节点里先用clear /清掉所有继承来的源。不清的话成员机器上如果有旧的、乱七八糟的源配置还原时可能从奇怪的地方拉包轻则慢重则出安全问题。清掉之后再按需添加我们自己的源和nuget.org。更激进的方案是开启“包源映射”packageSourceMapping。设置之后可以指定哪些包只能从哪个源下载避免因源顺序问题导致包被恶意替换。不过这功能配置门槛不低初次尝试共享的用户可以先不开等团队适应了再逐步收紧。4. 常见问题与排查技巧实录4.1 问题速查表这次折腾过程中我把遇到的高频问题整理成一张速查表后面再处理同类问题可以照着看现象/错误可能原因处理办法NU1101 找不到包源列表里没有对应包或版本不匹配检查源列表、补充对应版本的.nupkgNU1103 找不到可满足版本的包项目要求版本范围与本地源不一致确认锁文件和Directory.Packages.props里的版本还原突然变慢HTTP缓存被清、源顺序把公网放太靠前检查http-cache路径把本地源调整到最前项目构建报projects.assets.json损坏缓存被并发修改或文件损坏删除对应包的缓存目录后重新还原多人共用共享缓存目录时报文件占用多进程同时写同一缓存目录局域网场景避免直接共用NUGET_PACKAGES路径VS2022浏览标签页看不到本地源包源未刷新、目录结构不对、包源映射限制点刷新检查目录下有.nupkg检查映射规则改了NUGET_PACKAGES但不生效环境变量未刷新、被更高优先级配置覆盖重启VS/终端检查解决方案根目录的nuget.config4.2 几个典型的排查案例第一个案例是“在我机器上能还原新同事机器上不行”。排查下来发现新同事的VS2022里没有配置我们仓库里的nuget.config还在用默认的nuget.org源。把解决方案根目录的nuget.config提交到仓库后这个问题彻底消失因为VS打开解决方案时会自动读取根目录配置能保证每个成员用的源列表是一致的。第二个案例更有意思设置了NUGET_PACKAGES环境变量但还原后包还是跑到了默认的.nuget\packages。排查过程是先看环境变量有没有生效发现setx之后终端没重启重启后再还原结果还是不对。最后定位到是解决方案根目录有一份旧版nuget.config里面显式设置了globalPackagesFolder为默认值它的优先级比用户级配置高直接覆盖了环境变量。删除旧配置项后新路径才生效。第三个案例是离线机器上还原报NU1103提示找不到版本。明明我已经把项目里引用的主包拷到本地源了为什么还说缺原因是该主包依赖的其他传递依赖包没有一起导过来。重新在有网机器执行完整还原后用脚本导出全部全局缓存再把整个本地源目录拷到离线机器问题就解决了。这也是离线共享里最容易忽略的一环传递依赖经常被漏掉。4.3 我的几点避坑心得实际踩过坑之后我总结了几条经验不一定写在官方文档里但对做NuGet共享的人来说很有价值。第一条共享目录最好放在本机硬盘不要直接把网络盘设成NUGET_PACKAGES。虽然理论上可以这样但网络盘在还原大量包时会有严重的并发和延迟问题多个开发者同时还原还可能因为文件锁导致缓存损坏。正确做法是每台机器本地维护一份缓存通过共享盘里的本地源来分发包文件还原时命中本地缓存才快。第二条清理缓存要克制。dotnet nuget locals all --clear这个命令很爽快一下子把全局缓存、HTTP缓存全清了但清完之后你要用的老版本包就得重新下载。如果离线环境里某个老版本已经很难找到清缓存等于给自己挖坑。我一般只清理确认不用的包或者干脆不动。第三条中央包管理比共享缓存更值得优先推行。缓存共享解决的是“拿包快不快”版本锁定解决的是“构建结果一致不一致”。很多团队做共享只盯着缓存版本其实早就乱套了。先把Directory.Packages.props用起来再配本地源效果会好得多。这次尝试下来我自己最大的感受是NuGet的共享机制并不神秘核心就是“缓存 源 版本策略”三个抓手。一个人开发理解了全局缓存的位置就够用了一个小团队把本地源和nuget.config提交进仓库就能解决绝大多数问题更大规模再考虑私有服务器没必要一上来就上重方案。如果你刚接触VS2022的NuGet建议先打开命令行执行一下dotnet nuget locals all --list看看自己机器上到底缓存了什么很多关于“共享”的直觉一下子就通了。