i have the following setting:
- nuget.exe Version: 1.6.21205.9031
- Project A.csproj packaged into A.1.0.0.0.nupkg, and published to a LOCAL package repository hosted on my local IIS (My VS Nuget Extension i able to add the A-package to a new project)
- Project B.csproj has a dependency to the A-package that i added with the VS Nuget Extension
Now, when i run
nuget spec
the B.nuspec is created.
Then i run
nuget pack B.csproj -verbose
but in the created B-package, their is NO dependency to the A-package. The nuget pack command tells me that it has found the packages.config file (which contains the dependency to the A-package), but then it says "Dependencies: None".
What am i missing? Could the problem be that the A-package can only be found in my local package repository? How can i make nuget.exe aware of this local repository?
Thanks a lot!
nuget pack needs to be able to find the packages folder in order to resolve dependencies (see http://nuget.codeplex.com/workitem/3097), either in the same folder as the .csproj (as long as there's a .sln file one level above it) or in a folder specified in NuGet.Config.
I think I may have figured this out...
Our library solution had Nuget Package Restore turned on. I turned off NuGet Package Restore, and after that the project dependences were included when I created the NuGet packages.
I'm not really sure why the dependencies were not included in the package when Package Restore was turned on, but oh well :).
'Nuget.exe spec A.csproj' will create a very thin NuSpec file which won't have any dependencies. For our process use a powershell script to add the Project References and other dependencies from the project's packages.config to the <dependency> node in B.nuspec.
'Nuget.exe pack A.nuspec' will then be correct.
Similar question was asked here, and the answer explains that:
The reason why these were causing problems is because NuGet looks for the solution level packages folder to decide which package dependencies to pull in (not quite sure how this determination is made). If the path to that packages folder is incorrect (as it would be if NuGet uses the wrong solution file), then it can't resolve the dependencies correctly. In addition if the packages folder is empty, it also cannot resolve the dependencies correctly.
I had the same problem and adding solution file to project folder (previously without solution) helped me to resolve the issue.
The dependencies were missing for me because I didn't have the *.nupkg files in the packages folder for all the packages I was using.
This was pretty hard to track down, because the output of nuget pack looked like it was working:
Found packages.config. Using packages listed as dependencies
I had been using GitHub's Visual Studio .gitignore and only commented out the one line about "Package Restore" (because I wanted to commit my packages), but I should have commented out two. It should look like this:
# NuGet Packages
# *.nupkg
# The packages folder can be ignored because of Package Restore
# **/packages/*
Thanks to Rick Mohr's answer for linking to the CodePlex work item 3097, where feiling explains how the packages folder is used:
Since packages.config contains just a list of packages, and does not
contain dependency relationship between those packages, nuget needs to
access those package files to get the dependency info. That's why it
needs to know the packages folder.
The dependency information that feiling refers to is inside the *.nupkg files. Once I changed the .gitignore and committed all the missing *.nupkg files, my TeamCity build server was able to successfully create my NuGet package with the correct dependencies.
