如何实现基于解决方案配置的ProjectReference条件引用？

针对你遇到的插件项目引用和VS加载性能问题，结合你提到的NU1105错误根源，提供几个实际可行的方向：

1. 自定义MSBuild条件 + 解决方案过滤器（Solution Filter） #

这是最贴合你需求的方案，既能保留同时调试的能力，又能自由控制加载哪些插件项目：

• 先修改主项目的ProjectReference，把原来的Debug条件扩展，加上自定义的开关属性，比如：

  <ProjectReference Include="..\PluginA\PluginA.csproj" 
                    Condition="'$(Configuration)' == 'Debug' And '$(LoadPluginA)' == 'true'" />
  <ProjectReference Include="..\PluginB\PluginB.csproj" 
                    Condition="'$(Configuration)' == 'Debug' And '$(LoadPluginB)' == 'true'" />
  

• 创建解决方案过滤器文件（.slnf），在里面只包含主项目和你当前需要调试的插件项目。VS打开这个过滤器文件时，只会加载指定的项目，大幅提升打开速度。
• 自定义开关属性可以通过VS的「解决方案属性」→「配置属性」→「MSBuild命令行参数」来设置（比如/p:LoadPluginA=true），或者统一写在Directory.Build.props里，按需修改。

这个方案绕开了NU1105的问题——因为过滤器本质是让VS只加载指定项目，不存在"卸载项目但引用还在"的情况，也就不会触发那个来自VsSolutionRestoreService的错误。

2. 本地NuGet包替代项目引用（调试场景） #

如果不需要同时调试主应用和插件代码，只是偶尔需要调试插件，可以用这个方案：

• 把插件项目打包成本地NuGet包，放在本地NuGet源里。
• 主应用在Debug配置下引用这些本地NuGet包，Release配置保持原来的扫描逻辑。
• 需要调试插件时，再把插件项目加入解决方案，调试完成后移除即可，不用修改主项目的引用配置。

缺点是调试时需要手动附加进程，但胜在完全不需要修改主项目的引用，也不会强制加载所有插件项目。

3. 临时规避NU1105的小技巧 #

如果只是临时卸载项目，不想改配置，可以在VS的「工具」→「选项」→「NuGet包管理器」→「常规」里，关闭「允许NuGet下载缺失的包」，或者在项目的NuGet设置里禁用自动恢复。但这只是临时方案，长期用还是推荐前两种方法。

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