Failed to restore packages after switch to the new project system

[sharwell]

Details about Problem

NuGet product used: CLI

NuGet version (x.x.x.xxx): Unknown (AppVeyor image Visual Studio 2017)

dotnet.exe --version (if appropriate): N/A

VS version (if appropriate): Visual Studio 2017, MSBuild 15.1.1012.6693

OS version (i.e. win10 v1607 (14393.321)): AppVeyor image

Worked before? If so, with which NuGet version: Yes, worked with packages.config.

Detailed repro steps so we can see the same problem

1. Check out DotNetAnalyzers/StyleCopAnalyzers@b2bebb5f
2. Run nuget restore

🔗 Here's a failing AppVeyor build: https://ci.appveyor.com/project/sharwell/stylecopanalyzers/build/1.0.3122

Other suggested things

• The error message produced for this situation is completely unusable
• Renaming assemblies and changing the <PackageId> values during the build is not an acceptable solution. This scenario is expected to work under a default build configuration.

[emgarten]

I took a look at the repro, I see that the project is referencing a package with the same name and the dependency package is actually overriding the project and causing all sorts of confusion for the resulting dependency graph.

Restore should fail with a circular dependency error instead of going on to try to resolve this graph.

The conflict errors here can be ignored, they aren't the real problem.

The restore eventually fails with this stack:

System.AggregateException: One or more errors occurred. ---> System.InvalidOperationException: Sequence contains more than one matching element
   at System.Linq.Enumerable.SingleOrDefault[TSource](IEnumerable`1 source, Func`2 predicate)
   at NuGet.Commands.LockFileBuilder.AddProjectFileDependenciesForNETCore(PackageSpec project, LockFile lockFile, IEnumerable`1 targetGraphs)
   at NuGet.Commands.LockFileBuilder.CreateLockFile(LockFile previousLockFile, PackageSpec project, IEnumerable`1 targetGraphs, IReadOnlyList`1 localRepositories, RemoteWalkContext context)
   at NuGet.Commands.RestoreCommand.<ExecuteAsync>d__8.MoveNext()

Here is a simple repro that causes the same issue.

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <Version>3.3.0</Version>
    <PackageId>NuGet.Versioning</PackageId>
  </PropertyGroup>

  <ItemGroup>
    <!-- This package will be used instead of the project itself -->
    <PackageReference Include="NuGet.Versioning" Version="3.5.0" />
  </ItemGroup>

</Project>

Renaming assemblies and changing the values during the build is not an acceptable solution. This scenario is expected to work under a default build configuration.

@sharwell after fixing this issue restore will still fail, in your case having a package and project with the same name is invalid. The reason for this is that projects and packages are treated the same, this allows you to get the same behavior after packing your project (duality).

If you packed your project from this repro and I installed it, I would get MyProject -> StyleCopAnalyzers -> StyleCopAnalyzers which has a circular dependency.

[sharwell]

If you packed your project from this repro and I installed it, I would get MyProject -> StyleCopAnalyzers -> StyleCopAnalyzers which has a circular dependency.

This project uses both developmentDependency=true and PrivateAssets=all. How could there be a circular dependency?

[emgarten]

Setting it to private will stop it from flowing up to parent projects, however StyleCopAnalyzers -> StyleCopAnalyzers is still a circular dependency. The project is also part of the dependency graph.

[sharwell]

@emgarten This is a very frustrating breaking change for projects related to build tooling, including but not limited to analyzer projects. The assumption that a project reference and a package reference do the same thing is not valid in practice.

[emgarten]

I understand your frustration, as far as breaking changes go the move from legacy csproj to NETCore SDK projects has many differences, there currently is no expectation that everything will work identical to the older packages.config world. Transitive dependencies are another major change that are present in NETCore SDK projects and not packages.config.

[rocklan]

I had a similar problem, except it was occuring when building my solution inside azure devops. No circular dependency, the issue was just that I defined a variable named packageId at the top of my yaml. Renaming it fixed the problem. Seems like a bug to me, it should at least alert me that this is a reserved variable name.