.NET Core的Transitive Reference设置是否存在本地配置项?
可能导致该问题的本地配置排查点如下:
- 全局NuGet缓存损坏或不一致
哪怕代码版本完全一致,部分设备上默认路径为%userprofile%\.nuget\packages的全局NuGet缓存中,相关依赖包存在损坏、版本缺失、被本地篡改的情况,都会导致传递引用链断裂。可以先在异常设备上执行dotnet nuget locals all --clear清空所有本地NuGet缓存,再重新还原项目尝试编译。 - MSBuild全局配置强制关闭了传递引用
不同版本的Visual Studio都存在MSBuild全局导入配置目录(比如2019社区版对应路径为C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Imports),如果有第三方软件、过往项目遗留的自定义.targets/.props文件被放到该全局导入目录下,会自动给所有项目添加DisableTransitiveProjectReferences或DisableTransitivePackageReferences配置,强制关闭传递引用特性。
你可以在报错项目的.csproj文件中添加如下配置显式开启传递引用,覆盖全局配置:<PropertyGroup> <DisableTransitiveProjectReferences>false</DisableTransitiveProjectReferences> <DisableTransitivePackageReferences>false</DisableTransitivePackageReferences> </PropertyGroup> - 用户级NuGet配置存在差异
检查异常设备的%appdata%\NuGet\NuGet.Config文件,对比正常设备的配置,确认是否存在额外的依赖源、包排除规则、强制包版本映射规则,导致依赖还原时传递引用的包被跳过。 - 本地存在未提交的编译配置文件
检查异常设备上的项目根目录是否存在未被提交到版本库的Directory.Build.props、Directory.Build.targets或者.user配置文件,这类本地配置文件会覆盖项目默认编译规则,可能包含关闭传递引用的配置。
如果以上排查点都无效,可以在异常设备上执行dotnet build /bl输出二进制编译日志,和正常设备的编译日志对比传递引用的解析流程差异,即可定位到具体的配置异常点。
内容的提问来源于stack exchange,提问作者FBryant87
相关产品推荐
相关产品推荐

