如何通过本地源码覆盖NuGet包引用实现代码编辑与调试

1. 临时把类库项目加回应用所在的解决方案（零配置，还原体验和之前同仓开发完全一致） #

• .NET SDK和Visual Studio自带内置的还原匹配逻辑：只要你应用项目里保留原本对私有NuGet源的包引用，把要迭代的类库源码项目临时拖进解决方案，NuGet还原时会自动检测到本地项目的程序集名、版本号和被引用的NuGet包匹配，直接用本地项目的编译输出替换NuGet包内的对应程序集，完全不需要修改项目文件里的引用配置。
• 开发流程上，你改完类库代码直接运行应用就能看到改动效果，调试时可以直接在类库源码打断点；等当前功能迭代完成、把类库新版本发布到私有NuGet源后，只要把类库项目从解决方案里移除，应用就会自动切回使用私有源的正式包，不会影响CI流程、其他协作成员的本地环境。
• 注意：必须保证类库项目的目标框架、程序集版本和当前引用的NuGet包版本一致，否则NuGet无法自动完成匹配识别。

2. 配置本地临时NuGet源做优先级覆盖（适合需要频繁验证改动的迭代场景） #

• 在本地单独建一个空文件夹作为临时开发NuGet源，在本地专属的nuget.config文件里把这个本地源的优先级排在私有NuGet源前面，注意这个配置文件不要提交到代码仓库，只在本机保留即可。
• 每次修改完类库代码，直接运行dotnet pack --output 你的本地临时源路径，把打出的包版本号设成比私有源最新版本更高的预发布版本（比如私有源最新正式版是1.2.0，本地就打1.2.1-dev.1）。
• 还原阶段NuGet会自动优先拉取你本地临时源里的最新开发版本包，不需要改应用项目的任何引用配置，相比每次发包到私有源的流程，能把本地验证的等待时间从几分钟压缩到几秒。

3. 直接替换为本地项目引用（适合长周期的大版本迭代） #

• 如果当前迭代周期内需要连续修改类库十几次甚至更多，完全可以直接把应用项目里对应的PackageReference手动替换为ProjectReference，指向类库在本地磁盘的源码路径。
• 这种模式下IDE联动性最强：修改完类库代码只要重新生成解决方案，应用就能立刻拿到最新的类库输出，没有打包、拉取包的额外步骤，调试体验和之前类库、应用同解决方案时完全一致。
• 等当前迭代完成、类库正式版本发布到私有NuGet源后，只要把引用配置改回原来的PackageReference即可。

通用注意点 #

• 所有为本地开发做的配置调整，尽量不要提交到公共代码仓库，避免污染其他协作成员的环境
• 哪怕没有做源码覆盖，只要本地加载了类库对应的pdb符号文件，一样可以直接在类库源码打断点调试，不需要切到项目引用模式

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