"donet pack" is not including project references

[ivanz]

Steps to reproduce

git clone https://github.com/ivanz/dotnet-pack-repro.git
dotnet restore
dotnet build src\MainProject
dotnet pack src\MainProject

Expected behavior

DependencyProject.dll should be included in the .nupkg for the net46 framework:

{
    "version": "0.10.0-unstable-*",
    "frameworks": {
        "net46": {
            "dependencies": {
                "DependencyProject": {
                    "target": "project"
                }
            }
        },
        "netstandard1.5": {
            "dependencies": {
                "NETStandard.Library": "1.6.0"
            }
        }
    }
}

Actual behavior

DependencyProject.dll is not included at all in the .nupkg

Environment data

dotnet --info output:

> dotnet --info                                    
.NET Command Line Tools (1.0.0-preview2-003121)    

Product Information:                               
 Version:            1.0.0-preview2-003121         
 Commit SHA-1 hash:  1e9d529bc5                    

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

[blackdwarf]

@ivanz you need to dotnet pack each dependency separately. This is by design.

[ivanz]

@blackdwarf Are you saying that I need to publish a nuget package of my dependency and have a dependency on it? (in my case that's exactly what I am trying to avoid when porting a library in order to retain the distribution as is prior to dotnet/.NET Standard/.Net Core)

[blackdwarf]

@ivanz you keep the dependency as a P2P reference, but you produce a nupkg of both your library and its consumer.

[ivanz]

@blackdwarf That doesn't work. I end up with a MainProject.nupkg which has a nuget dependency on DependencyProject instead of simply including the DependencyProject.dll in the MainProject.nupkg for the net46 target?

[tsublette]

I am having the same issue. I am porting a common library to .net core and it consists of the main DLL class library and 2 supporting DLLs. I build the package with nuget and the nupkg file contained all 3 DLLs. The same behavior is not happening with dotnet pack. According to the documentation if you specify the dependencies as project references they will be included. This is not happening. Can you reopen the issue and investigate?

[nullptre]

The same for me. Documentation says that it is possible. So why closing this issue?

[PiMihai]

In case anyone else is having the same issue, you must also specify "type": "build" on each dependency. It is stated in the docs, for some reason though I thought "default" means "build" (it clearly wasn't "platform" - hence I thought "default" is a placeholder)

{
    "version": "1.0.0-*",
    "dependencies": {
        "ProjectA": {
            "target": "project",
            "type": "build"
        }
    }
}

[jonjo-manywho]

I'm also running into this same problem, and following the docs that @UizzUW linked to still don't bundle the dependency DLLs into the nupkg

[nullptre]

@UizzUW, I did it and still without success.

[tsublette]

I had read the docs as well and setup the project target and type as shown above. Doesn't work...

[tsublette]

Without the ability to package and publish libraries, it is hard to move into production with dot net core

[PiMihai]

.NET Standard linking seems to be a bit different than old style .NET Framework linking. From what I've gathered, this is in order to make stripping more modular and only include the bits that you actually need in the final build (and not the full framework). Here's the scenario I'm currently struggling with and what I figured out so far :

• I am working on project A which I would like to distribute as a NuGet
• I have another project B which I DO NOT wish to expose on NuGet, as it does not offer any standalone functionality
• A references B with "type":"build" and "target":"project"
• I have a project C consuming A with "target":"project"

The tricky thing here is that if I package A and publish to NuGet, B will get packaged along and will not appear as a NuGet dependency. HOWEVER, I will not have access to any of rhe classes in B from C - it's like a "protected" packaging, so-to-speak, where the dependency is being packaged but not exposed further. only B's contract will get packaged along with A! The consuming project (C) will still have to resolve B somehow. The difference with this is that the A NuGet won't list B as a NuGet dependency. This results in a runtime error rather than a compile error.

What's even more, in both cases ("type":"build" and "type":"default"), the A NuGet won't further expose B's contract - it's like a "protected" contract packaging, so-to-speak.

You can find the actual project I am working on here - look through the project.jsons and see if you can find anything that would be of help. Choose either Common + Core + Core.Sample or Common + Client + Client.Sample in order to get the same dependency tree I am talking about (.Sample projects are supposed to be projects that would consume the actual NuGet library)

I think this area needs lots more in-depth documentation, then again they might just be waiting for the right moment since they're going to get rid of project.json and go back to .csproj configs soon anyway.

[tsublette]

I have a work around

"packOptions": {
    "files": {
      "mappings": {
        "lib/netstandard1.6/": {
          "includeFiles": [
            "bin/Release/netstandard1.6/_3DSIM.Business.Core.pdb",
            "bin/Release/netstandard1.6/_3DSIM.Utility.Core.dll",
            "bin/Release/netstandard1.6/_3DSIM.Utility.Core.pdb",
            "bin/Release/netstandard1.6/_3DSIM.SupportOptimization.Core.dll",
            "bin/Release/netstandard1.6/_3DSIM.SupportOptimization.Core.pdb"
          ]
        }
      }
    }
  },

  "scripts": {
    "postcompile": [
      "dotnet pack --no-build --configuration %compile:Configuration%"
    ]
  }

The resulting nupkg file contains the main dll, the 3 supporting libraries and the pdbs. I tried to replace "Release" with %compile:Configuration% but then no nupkg file was built. I only care about the nuget package for a CI release build so this is fine for now.

[christianhuening]

The same for me here! Specifying "type": "build" results in all the needed DLLs being written out to the /bin/Release// folder, but they are not included in the resulting .nupkg.

@blackdwarf
I really understand the idea behind the modularization effort put into dotnet core and therefore get the idea of publishing everything as its own .nupkg file. But since packaging everything in a single nupkg is documented (https://docs.microsoft.com/en-us/dotnet/articles/core/tools/dotnet-pack), it should either work that way or the documentation needs to be changed.