C#项目中应何时禁用Transitive References（传递项目引用）？

显式禁用传递引用的适用场景 #

满足以下任意一种情况时，建议开启<DisableTransitiveProjectReferences>true</DisableTransitiveProjectReferences>配置：

• 架构约束严格的多项目解决方案：比如DDD、分层架构的项目，需要严格限制各层的访问权限，比如只允许应用层访问领域层，不允许直接访问基础设施层。禁用传递引用后可以从编译层面拦截跨层的隐式调用，强制所有依赖必须显式声明，避免架构被意外破坏。
• 公共类库/SDK开发：如果你开发的是团队内部共享或者对外发布的公共组件，禁用传递引用可以避免你内部依赖的组件暴露给下游使用者，后续你迭代组件时要替换内部依赖不会导致下游代码出现破坏性变更，大幅降低公共组件的维护成本。
• 复杂依赖的治理场景：当项目依赖链很长，经常出现版本冲突、依赖冗余问题时，禁用传递引用后编译报错可以帮你快速梳理出项目实际用到的所有依赖，方便你做依赖裁剪、版本对齐，减少不可预期的依赖问题。
• 发布包体积敏感的场景：比如客户端应用、Serverless函数、轻量微服务等对部署包体积有要求的项目，禁用传递引用可以避免没用的隐式依赖被打包到产出中，有效减小最终程序的体积。

保留默认传递引用特性的利弊 #

默认不配置该标签时，传递引用处于开启状态，对应的收益和成本如下：

收益 #

• 开发效率更高：小型项目或者依赖链简单的场景下，无需手动添加所有用到的依赖，只要引用直接依赖的项目即可使用其所有公开依赖，减少csproj文件的冗余配置，降低开发时的心智负担。
• 版本自动对齐：同一解决方案内的项目依赖，MSBuild会自动统一传递依赖的版本，避免出现同一个依赖多个版本共存的问题，减少版本冲突的手动处理成本。

成本 #

• 架构腐烂速度加快：没有编译层面的约束，开发者很容易为了方便直接调用跨层的传递依赖代码，久而久之会彻底破坏预设的架构分层，后续代码维护成本指数级上升。
• 依赖问题排查难度高：如果传递依赖出现Bug、兼容性问题或者版本冲突，很难快速定位到是哪一层的依赖引入的问题，排查和修复的时间成本会比显式依赖高很多。
• 隐性变更风险高：中间层的依赖更新后，上层项目哪怕没有任何代码改动，也可能因为传递依赖的变更出现兼容性问题，而且这类问题通常很难在开发阶段提前发现，容易带到线上。
• 编译产出冗余：大量未被实际使用的传递依赖会被默认打包到编译产出中，增大程序体积和加载时间，尤其对体积敏感的场景影响更明显。

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