使用Git子模块和.NET Core时递归csproj依赖的NU1105问题

我之前在维护一个多子模块的.NET Core项目时，碰到过和你完全一样的NU1105错误，折腾了好一阵才搞清楚根源，给你分享下解决思路：

问题根源 #

.NET Core 2.0的SDK风格csproj在NuGet还原阶段，依赖解决方案（.sln）中显式包含的所有项目来构建完整的依赖链。哪怕你的子模块项目A引用了嵌套子模块里的项目B，只要项目B没被添加到顶层解决方案中，NuGet就无法找到项目B的还原元数据，直接抛出NU1105错误——这和旧的非SDK风格csproj的处理逻辑完全不同，旧版本可能会自动解析嵌套引用，但SDK风格要求所有参与依赖的项目都必须在解决方案里有记录。

具体解决步骤 #

• 把所有嵌套子模块的csproj都添加到顶层解决方案
  不管这些项目是直接被顶层项目引用，还是被其他子模块间接引用，都要显式加入sln：

  • 命令行方式（推荐，路径更准确）：

    dotnet sln add ./src/submoduleA/nested-submoduleB/ProjectB.csproj
    

  • 或者在Visual Studio里右键顶层解决方案 → 添加 → 现有项目，找到嵌套子模块里的目标csproj文件。

• 检查ProjectReference的路径合法性
  确保子模块里的csproj中，对嵌套子模块项目的引用用的是相对路径（相对于当前csproj的位置），比如：

  <ProjectReference Include="..\..\nested-submoduleB\ProjectB.csproj" />
  

  绝对路径会导致跨环境解析失败，也是触发NU1105的常见诱因。

• 强制清理缓存并重新还原
  有时候旧的NuGet缓存会干扰还原过程，执行以下命令彻底重置：

  dotnet clean
  dotnet nuget locals all --clear
  dotnet restore
  

额外说明 #

你提到之前的类似问题已经过时，这点完全正确——因为非SDK风格的csproj依赖packages.config管理包，而.NET Core 2.0的SDK风格csproj采用了基于MSBuild的依赖解析逻辑，对解决方案的项目完整性要求更高，这也是为什么旧方案不适用于你的场景。

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