Home: Ambiguous project name '[project]'.

[kingerja]

Details about Problem

NuGet product used (NuGet.exe):

NuGet version (4.1.0.2450):

OS version (Win10 (15063.447)):

Detailed repro steps so we can see the same problem

(see attached zip for repro projects and detailed logs)

1. Create a file d:\tmp\repro\foo.proj
   <?xml version="1.0" encoding="utf-8"?>
   <Project Sdk="Microsoft.NET.Sdk">
   <ItemGroup>
   <PackageReference Include="Newtonsoft.Json" version="9.0.1" />
   <ProjectReference Include="src\foo.proj" />
   </ItemGroup>
   </Project>

2. Create a file d:\tmp\repro\src\foo.proj
   <?xml version="1.0" encoding="utf-8"?>
   <Project Sdk="Microsoft.NET.Sdk">
   <ItemGroup>
   <PackageReference Include="NUnit" />
   </ItemGroup>
   </Project>

3. nuget restore d:\tmp\repro\foo.proj

4. Observe error
   Ambiguous project name 'foo'.

Other suggested things

Verbose Logs

Please include verbose logs (NuGet.exe -verbosity detailed | dotnet.exe --verbosity diag | etc...)
Ambiguous-project-name.zip

Sample Project

Very helpful if you can zip a project and paste into this issue!

[emgarten]

Each node in the dependency graph must have a unique id. In this case the graph is:
Foo -> Foo -> NUnit

If these projects were packed and then consumed by another project it would be:
MyProject -> Foo -> Foo -> NUnit

This has an obvious circular dependency. It is less obvious in the first example but it works the same way, the root project itself is part of the graph and not special cased. This ensures that you get the same behavior before and after packing (duality).

You can work around this by adding <PackageId>FooA</PackageId> to one of the projects to change the id.

This issue may be improved by properly detecting the circular reference here, this is covered in: https://github.com/NuGet/Home/issues/5630

[KevinBurton]

I am not able to see the "obvious circular reference". I am on Visual Studio for Mac with a .NET Core application. In order to make the project references more portable I have created NuGet packages for most all of my library projects. On the particular project I am working on it is a very simple solution that has a code project and a test project. The project compiles and builds just fine. The unit tests also pass without an issue. But, when I try to create a NuGet package out of the project (using dotnet pack . . . and nuget add package . . .) The command that fails is 'dotnet pack'. With '--verbosity' turned on I get

dotnet pack --include-symbols /p:Authors="Kevin Burton" /p:Title=GeoProcessing /p:Title="Methods to use online Web APIs for geoprocessing" /p:PackageId=GeoProcessing /p:PackageVersion=1.0.6 /p:TargetFramework=netcoreapp2.0 --verbosity
System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index
   at System.ThrowHelper.ThrowArgumentOutOfRange_IndexException()
   at System.SZArrayHelper.get_Item[T](Int32 index)
   at System.Linq.Enumerable.ElementAt[TSource](IEnumerable`1 source, Int32 index)
   at Microsoft.DotNet.Cli.Telemetry.TelemetryFilter.LogVerbosityForAllTopLevelCommand(ICollection`1 result, ParseResult parseResult, String topLevelCommandName)
   at Microsoft.DotNet.Cli.Telemetry.TelemetryFilter.Filter(Object objectToFilter)
   at Microsoft.DotNet.Cli.Utils.TelemetryEventEntry.SendFiltered(Object o)
   at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, ITelemetry telemetryClient)
   at Microsoft.DotNet.Cli.Program.Main(String[] args)

Which is a different output without '--verbosity'. Any Ideas?

Microsoft (R) Build Engine version 15.5.180.51428 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restoring packages for /Users/rebeccaannburton/Projects/GeoProcessing/GeoProcessing/GeoProcessing.csproj...
  Restoring packages for /Users/rebeccaannburton/Projects/GeoProcessing/GeoProcessingTests/GeoProcessingTests.csproj...
/usr/local/share/dotnet/sdk/2.1.4/NuGet.targets(103,5): error : Ambiguous project name 'GeoProcessing'. [/Users/rebeccaannburton/Projects/GeoProcessing/GeoProcessing.sln]

It seems when I remove the test project from the solution (when the solution has only one project) it works fine. So it seems to have to do with the number of projects in the solution.

[aguacongas]

@emgarten can you reopen, I've exactly the same issue with dotnet restore but on build server only
On a developer machine it works, on a TFS build server, it doesn't
Mutch more weird : If I launch the command in the repository TFS checkout code, I don't have the error

[golayp]

@aguacongas , @emgarten, it's seems that our TFS build process define a variable named PackageId that override csproj variable in all projects and causes this issue. If it can be helpful for anyone else...

[binki]

Like @golayp, I triggered this error by setting an environment variable without realizing it would be consumed by MSBuild. I had set ASSEMBLYNAME which results in presetting the AssemblyName property in .net core project (which have very tiny .csproj files which don’t explicitly set AssemblyName). Since PackageId is derived from this, I ended up with a very confusing error until I noticed I was polluting my environment.

[gregbair]

For any others that come across this, I accidentally had two projects in the solution with the same AssemblyName in the csproj.

[cyotek]

I also recently encountered this issue. My project structure was

solution.sln
  Directory.Build.props
  src\source.csproj
  tests\test.csproj

PackageId was defined in Directory.Build.props. It should have been obvious given that the contents of this file were being used to generate the package attributes for source.csproj but test.csproj was also inheriting them, causing this error. Hopefully another concrete example of seemingly numerous ways to trigger this issue will be of help to the next person!

As I didn't need/want the inheritance I simply moved the Directory.Build.props file into the src directory. Interestingly I was still getting the error until I closed and reopened the solution. Seems to have worked though, no more local errors and the remote AppVeyor builds are working again too.