无需推送至NuGet服务器，VS中开发NuGet包如何联动服务解决方案？

我之前也碰到过一模一样的场景——一个解决方案负责生成NuGet包，另一个用这些包做服务开发，改完包要半天才能在服务里用上太折腾了！结合你已经在做的本地源配置，给你几个能快速解决的实操方案：

一、先把本地NuGet源的配置补全（你已经开了头，这里细化） #

• 确保每个包项目不仅开了<GeneratePackageOnBuild>true</GeneratePackageOnBuild>，还要统一包的输出路径到你的artifacts文件夹，这样本地源能准确找到新生成的包。在每个包项目的.csproj里加这段配置：

  <PropertyGroup>
    <GeneratePackageOnBuild>true</GeneratePackageOnBuild>
    <!-- 路径根据你的解决方案实际位置调整，比如Packages.sln在根目录下的Packages文件夹，就用相对路径指向artifacts -->
    <PackageOutputPath>..\..\artifacts</PackageOutputPath>
    <!-- 可选但非常实用：加动态版本后缀，每次生成的包版本不一样，避免缓存混淆 -->
    <VersionSuffix>dev-$(DateTime.Now.ToString("yyyyMMddHHmm"))</VersionSuffix>
  </PropertyGroup>
  

• 打开VS的「工具」→「NuGet包管理器」→「包管理器设置」，在「包源」里添加你的artifacts文件夹，命名成好识别的名字比如「本地开发包源」，确认路径正确。

二、实现修改包后自动同步到服务项目 #

1. 让服务项目自动触发包项目构建 #

如果两个解决方案在同一个目录下，最省心的办法是把Packages.sln里的包项目直接添加到Services.sln中：

• 右键Services.sln →「添加」→「现有项目」，找到Packages文件夹里的PackageA、PackageB等项目添加进去。
• 然后右键服务项目（比如ServiceA）→「项目依赖项」，勾选对应的包项目。这样每次你编译ServiceA时，VS会自动先编译修改过的包项目，生成最新的nupkg到artifacts文件夹。

如果不想把包项目加入Services.sln，也可以写个简单的批处理脚本（比如BuildPackages.bat）放在Services.sln根目录，一键编译Packages.sln：

@echo off
dotnet build "../Packages/Packages.sln" -c Debug
echo 包项目编译完成，已生成到artifacts文件夹
pause

2. 快速更新服务项目的NuGet包 #

编译完包项目后，在Services.sln里：

• 打开「NuGet包管理器」→「管理解决方案的NuGet包」，切换到「更新」标签，选择你刚才加的「本地开发包源」，就能看到最新版本的包，点击更新即可。
• 嫌GUI慢的话，用命令行更高效，在Services.sln根目录执行：

  # 刷新源并更新指定包
  dotnet restore --source "本地开发包源"
  dotnet add package PackageA --source "本地开发包源"
  

三、踩过的坑：解决NuGet缓存导致的不生效问题 #

有时候明明生成了新包，服务项目却还是用旧的，这大概率是NuGet缓存搞的鬼：

• 清理本地NuGet缓存，执行命令：

  dotnet nuget locals all --clear
  

• 或者之前提到的动态版本号一定要用上，每次生成的包版本不同，VS就不会拿旧缓存糊弄你了。

四、调试阶段的终极快捷方式：跳过NuGet包生成 #

如果只是开发调试，不想每次都走生成包、安装包的流程，直接用项目引用代替NuGet包引用：

• 右键服务项目→「添加」→「项目引用」，勾选Packages.sln里的对应包项目。
• 这样你修改包项目的代码后，直接编译服务项目就能即时生效，完全跳过NuGet的那套流程，等调试稳定后再改回NuGet包引用就行，非常适合快速迭代。

内容的提问来源于stack exchange，提问作者Robert N. Dean