"An item with the same key has already been added" - when project graph has projectName == packageRef name (of same version)

[ceddlyburge]

The problem occurs when a dll is referenced as a nuget package and as a project reference.

If there are 3 projects, Source, Intermediate and DoublyReferencedTarget

Then the problem will occur when Source has:

• ProjectReference to project Intermediate
• ProjectReference to project DoublyReferencedTarget

And 'Intermediate' has

• PackageReference to project DoublyReferencedTarget.

Thus project DoublyReferencedTarget is referenced twice in two different ways, which creates this error.

I realise that this is a genuine error, but a better error message would be very useful. Some of our solutions contains 100's of projects (a bad idea I know), and it's just taken me a week to track down this problem.

I have created a repo to demonstrate the problem at https://github.com/ceddlyburge/nuget-error.

[nkolev92]

@ceddlyburge
I am unable to reproduce this with the latest 15.7 preview.

Which version of VS are you using?

[laszlohorvath]

I am able to reproduce it with the demo repo. VS 2017 Ent 15.6.6

And we also have this issue, and it is a quite big problem here, I've spent days to solve it, but we were unable to. So any help (hotfix, workaround, etc...) would be appreciated.

[ceddlyburge]

Hi there, I am on VS 2017 Professional 15.6.4

I also get the problem on the command line using nuget 4.3.0.4406, which in turn uses msbuild 15.6.82.30579

[MisterJimson]

Running into this as well...

[natemcmaster]

Ran into this as well with VS 15.9. Anyone found a solution?

[JosepBalague]

NuGet 4.9.2.5706 (nuget restore), msbuild version '15.9.21.664', VS2017 15.9.6 still failing. When this will be solved?

[bdongus]

Nuget 4.9.3.5777, VS2017 15.9.11. This still is an issue.

[thyn]

vs19 same issue

[GraySerg]

VS 2019 same error

[ivankarpey]

This is insane to see such a problem exist for such a long time without any response or workaround provided by the Nuget team. As I still could confirm these issues exist (vs 2019, .net core 3.0 preview) the simple workaround is to change the version of a package you do reference in sources. With the new version, it should start working fine.

[zivkan]

I was able to reproduce the error. The exception is thrown here: https://github.com/NuGet/NuGet.Client/blob/3113c5ddf420ae0c9c34959108e127136c8f141e/src/NuGet.Core/NuGet.Commands/RestoreCommand/LockFileBuilder.cs#L152

The issue appears to be that the same name+version pair is both a package and a project reference. If they had different versions, it would work, or if it was consistently a package or a project reference both times, I expect it would work.

My initial reaction is that the assets file might need to change to support this scenario, rather than being a simple bug to fix.

[zivkan]

From the sample, if we remove the project reference to intermediate from source, source can reference both the package and project and it works fine, NuGet selects the project. This "prefer project over package" logic doesn't appear to be happening for transitive dependencies, which I think is the bug.

[redwyre]

I got this message, which I was able to fix by converting the project to the new project format. Have no idea what the real problem was.

[morbidcamel101]

Hey so I got this issue when doing some coding and adding a reference to a project that was already in the project as a nuget package. I removed the nuget package - added a project reference but the dotnet restore command failed. A work-around was to change the version number of the referenced project.

[MABrunner]

Thanks for this commit! Will this fix the issue in Visual Studio itself, or in the DevOps pipelines? Or neither?

[erdembayar]

I was able to reproduce the error. The exception is thrown here: https://github.com/NuGet/NuGet.Client/blob/3113c5ddf420ae0c9c34959108e127136c8f141e/src/NuGet.Core/NuGet.Commands/RestoreCommand/LockFileBuilder.cs#L152

The issue appears to be that the same name+version pair is both a package and a project reference. If they had different versions, it would work, or if it was consistently a package or a project reference both times, I expect it would work.

My initial reaction is that the assets file might need to change to support this scenario, rather than being a simple bug to fix.

It looks any change to lock file might break existing build and restore since we can't support both project reference and packagereference for same Id&version. Even we support which one take more priority is tricky question. So I believe best course of action is display "Explicit error" for what is wrong. I already talked with @nkolev92 on this.

[erdembayar]

From the sample, if we remove the project reference to intermediate from source, source can reference both the package and project and it works fine, NuGet selects the project. This "prefer project over package" logic doesn't appear to be happening for transitive dependencies, which I think is the bug.

@zivkan
Do we have logic written somewhere in documents or code for "prefer project over package"?

[zivkan]

From a quick search, I couldn't find it. @nkolev92 do you know?

[nkolev92]

https://github.com/NuGet/NuGet.Client/blob/3ef6cd3c0145e59314a495569c2d53296794fbf3/src/NuGet.Core/NuGet.Commands/RestoreCommand/Utility/IncludeFlagUtils.cs#L200-L221 which is called by https://github.com/NuGet/NuGet.Client/blob/3ef6cd3c0145e59314a495569c2d53296794fbf3/src/NuGet.Core/NuGet.Commands/RestoreCommand/Utility/IncludeFlagUtils.cs#L67-L165, which in turn is called when the dependencies are flattened, ie when the assets file is created: https://github.com/NuGet/NuGet.Client/blob/3ef6cd3c0145e59314a495569c2d53296794fbf3/src/NuGet.Core/NuGet.Commands/RestoreCommand/LockFileBuilder.cs#L171

[erdembayar]

@NuGet/nuget-client
Do we need to show warning message to user that we picked up project over package in this case instead of doing it silently?

[nkolev92]

@erdembayar
Given that it's an implementation detail and a question to the team, let's continue the discussion on the PR instead.