nuget pack command is not adding project dependencies in my NuGet package created from a .csproj file

Aug 5, 2011 at 2:44 PM
Edited Aug 5, 2011 at 2:45 PM

I am creating a nuget package from .csproj file.  The .csproj file lists a bunch of project dependencies.  

  1. I create the spec file using nuget spec in the same folder as my .csproj file. 
  2.  I edit the .spec file for things such as tags. 
  3.  I then run nuget pack which successfully creates my .nupkg file.  

When I open the package file using nuget explorer I do not have the project dependent .dlls packages in my lib folder.  I only have the .dll associated with the .csproj file.

Aug 5, 2011 at 3:19 PM
Edited Aug 5, 2011 at 4:29 PM

I have another project that I run the same process on and it pulls in project dependencies (which makes sense), but it is unclear how the results are derived.  I have summarized the project dependencies  for project A:

  • project A 
    • references project B 
    • references project C
    • reference project F
  • project B 
    • references project C 
    • references project D 
    • references project E 
    • references project F 
    • references project N 
    • reference project M 
  • project C 
    • reference project F 

What I end up with in my NuGet package for project A's lib folder are assemblies from:

  • project A
  • project B 
  • project C 
  • project D 
  • project E
Aug 5, 2011 at 4:11 PM

Strange, I would expect all of them to be there. Would you be able to share a minimal solution that demonstrates this behavior so we can investigate further? Thanks!

Aug 5, 2011 at 4:22 PM

Sure. Let me know what portions you would like to see and I will post them.

Eric

Aug 5, 2011 at 6:21 PM

Turns out that even on a simple library that uses another one, the dependent assembly doesn't get included. I think there is a bug tracking this but I couldn't quite find it.

You should be able to work around by explicitly listing the assemblies you care about in the nuspec. e.g.

<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
  <metadata>
    ...
  </metadata>
  <files>
    <file src="bin\Debug\*.dll" target="lib\net40" /> 
  </files>
</package>

This will include all dll's that ended up in the bin folder, but you can be more selective if you like.

Aug 5, 2011 at 6:24 PM

Thanks David.

Is this something that you think will be in your 1.6 release which is CI oriented?  I'm working on this as part of a CI process and having that fix in the 1.6 release would be great.

Aug 5, 2011 at 6:29 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Aug 5, 2011 at 6:32 PM

Not sure at this point. I just filed a new bug since I couldn't find the old one. Note that the design is not quite straightforward:

  • What if the dependent project itself had its own package. Then including the DLL would be incorrect
  • What about references to random libraries (not project references). Should they also end up in the package?

We need to think through the various scenarios to get this right :)

Aug 5, 2011 at 6:48 PM

    <files>
            <file  ...   > 

Does "file" provided a means of excluding elements because when I incorporate this code into my nuspec file I get a message that it:

Cannot add  part for the specified URI because it is already in the package.

 My guess is that it is complaining about the .dll associated with the .csproj file.

Aug 5, 2011 at 6:50 PM

Strange, I did not see this when I tried (on a really simple solution with two libraries). Does it work if you selectively pick the DLL's you need?

Aug 5, 2011 at 8:11 PM

David:

 

Yes, if I list each dependency out in the <files> <file ...> section of the .nuspec file than the subsequent nuget pack packaging works fine.  I have to make sure that I exclude the .dll  from the <file .. > list that is associated with the .csproj file that resides in the same directory.

Aug 5, 2011 at 8:17 PM

For reference, here is my test solution. After building it, going under ClassLibrary3 and running 'nuget pack ClassLibrary3.csproj' (which has the *) produces the correct package.