企业内部.Net跨解决方案依赖管理优化方案咨询

方案1：现有NuGet流程轻量化改造 （最小改造成本） #

• 启用本地临时NuGet源：开发者本地修改Class Library "C"后，直接执行dotnet pack生成本地NuGet包，存到本地指定文件夹并将该文件夹设为NuGet最高优先级源，无需提交代码跑CI流程，就能直接在B、A项目本地更新引用做验证，调试确认无问题后再提交代码走正式发版流程。
• 配置CI增量构建：打开Azure DevOps流水线的构建缓存规则，只构建有代码变更的项目，跳过无改动项目的打包、测试、发布步骤，可将现有4-5分钟的构建时长压缩到1分钟以内。
• 自动提交依赖更新PR：启用Azure DevOps内置的Dependabot功能，Class Library "C"正式包发布后自动给B项目提NuGet引用更新PR，B包发布后自动给A项目提PR，无需人工手动修改版本号。

方案2：本地项目引用替代临时调试 （适合多依赖并行开发场景） #

• 开发阶段临时将Class Library "C"、Class Library "B"的项目文件添加到A的解决方案中，切换为项目引用（Project Reference），修改C的代码可直接在A项目中实时生效调试，完全不需要打包发布流程，功能验证无误后再切回NuGet引用提交代码。
• 可通过MSBuild条件配置实现自动切换，无需手动修改引用配置，示例代码如下：

<Choose>
  <When Condition="'$(Configuration)' == 'Debug'">
    <ProjectReference Include="..\..\C\ClassLibraryC.csproj" />
  </When>
  <Otherwise>
    <PackageReference Include="ClassLibraryC" Version="*" />
  </Otherwise>
</Choose>

Debug模式下自动走本地项目引用，Release模式下自动切换为正式NuGet引用。

方案3：单体仓库（Monorepo）重构 （长期最优解，适配30+解决方案的内部依赖场景） #

• 将内部耦合度高的所有解决方案迁移到同一个Git仓库中，所有公共类库和业务应用统一管理，跨项目直接使用项目引用，代码修改全链路实时生效，完全不需要NuGet包作为中间载体，从根源上消除跨依赖流程耗损。
• 配置Azure DevOps的Monorepo触发规则，仅对应目录下的代码有改动时才触发对应项目的构建发布，不会出现全仓库全量构建的性能问题。
• 改造完成后一次简单的依赖修改最多10分钟就能完成全链路验证，完全消除等待和上下文切换带来的效率耗损。

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