dotnet pack uses project folder name instead of project name as dependency

[fubar-coder]

Steps to reproduce

Project layout:

LibA/project.json
LibA/TestA.cs
LibB/project.json
LibB/TestB.cs

The project name for LibA is Test.LibA and for LibB, it's Test.LibB.
LibB has a dependency to LibA by its folder name LibA, because Test.LibA searches the NuGet sources for a package with this ID (which might cause trouble).

Expected behavior

After a dotnet pack, the dependency of Test.LibB must be Test.LibA.

Actual behavior

The dependency of Test.LibB is LibA, even though the project.json has a name element with Test.LibA as the projects name.

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-rc2-002485)

Product Information:
 Version:     1.0.0-rc2-002485
 Commit Sha:  d3c65aee87

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.10586
 OS Platform: Windows
 RID:         win10-x64

[TheRealPiotrP]

@fubar-coder the dependency name must match the output nuget package name. Can you share a more complete repro?

[fubar-coder]

This is the example.
naming-inconsistencies-folder-name.zip

Run:

dotnet restore
dotnet build Json**/project.json
dotnet pack Json.Test

Every command succeeds and in the file project.lock.json, you can see the reference to the Json project. The produced nupkg file references a package named Json instead of Newtonsoft.Json. The obvious solution to this problem would be to change the dependency in Json.Test from Json to Newtonsoft.Json. Sadly, after a dotnet restore, the Newtonsoft.Json from nuget.org gets referenced instead of our own and therefore, dotnet build Json.Test fails, because our test class could be found. Changing the global.json entry from Json to Newtonsoft.Json doesn't change that problem.

[mpreyskurantov]

This issue (the impossibility to specify a unique package id/name) is also very critical to us, because it blocks porting numerous existing and deployed/integrated libraries (published as NuGet packages) to .NET Core.

The following workarounds seem to not work:

1. Create a *.nuspec file manually without using the "dotnet pack" command and replace the related package id/name with the required unique name (for example, with the "DotNetCore" suffix). In this case, the related generated *.nupkg file cannot be pushed.

2. Add a ported library/DLL file (whose name could be unique) as a dependency for a newly generated NuGet package for .NET Core. In this case, this new NuGet package is installed, but cannot resolve its dependency, which is included as DLL (without its own NuGet package).

While we see that there is an activity ("blackdwarf added the nuget label X days ago"), we need to know your real plans and estimates regarding this issue. Would you please share your progress and let us know if you need our cooperation?

[TheRealPiotrP]

@mpreyskurantov the original issue here is quite quite old and still refers to the project.json project system. this doc shows how to set the package ID and version.. let us know if anything is missing.

[github-actions]

Due to lack of recent activity, this issue has been labeled as 'Stale'. It will be closed if no further activity occurs within 30 more days. Any new comment will remove the label.