Sdk: "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?

[yuriy-nelipovich]

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

[yuriy-nelipovich]

@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.

[blackdwarf]

@christianhuening the documentation linked states that issuing dotnet pack will pack only the project and not its P2P references. If you feel that the documentation is still inadequate, please file an issue in the dotnet/core-docs repo. Thanks!

[mairaw]

I have an issue tracking the documentation update and I should have a PR out in a moment: https://github.com/dotnet/core-docs/issues/1070

[radu-matei]

How about .csproj?

How do I also include the dependency in a msbuild environment?

Thanks!

[PiMihai]

@radu-matei that is a whole different beast of an issue.

There are (or were) essentially two different build systems after the release of .NET Core and .NET Standard. The old one, MSBuild, still used for .NET Framework projects (.csproj files), and the new one exposed by the "dotnet" CLI, which knows how to handle project.json files.

The problem is the dotnet CLI does not know how to handle .csproj files, so you cannot reference a .csproj from a project.json or .xproj.

The solution, while I haven't tested it myself, should be to install VS2017 and open your project.json-based projects with it. The dotnet team gave up on project.json and have switched back to .csproj files even for .NET Core / Standard in order to support the very issue you have right now. This is why VS2017 comes with new tooling which should be able to convert all your project.json based projects to the new, msbuild based projects. You should be able to reference other .csproj files after that.

[radu-matei]

@UizzUW - my project is VS17 based with .csproj for all projects.

I built a nuget package using dotnet pack, but I also want to bundle all dependencies of that project (which are also .csproj based).

The concrete questions (which I should have made clear in the first place) are:

• how can (and if) I use dotnet pack to create the package with all dependencies
• how can I use nuget (latest version, 4.0.0) on a system with VS17 (last RC) installed.

Thanks,
Radu M

[gingters]

I feel I have the same issue. I have a Command line executable project.

When I use either dotnet pack or dotnet publish, I end up with a nupgk that only contains my .exe and a {projectname}.runtimeconfig.json file in it. It does not even include the config.json file that is copied to the output directory, which is require to run my command line tool.

However, when I use VS 2017 and right-click on my project and select Publish, then selecting the default FolderProfile, all contents (including my config file) and all dependencies required to run the project are put in a folder. I need the complete outputs of this publish folder in a nuget package to be able to deploy a runnable version of my tool.

As a workaround I could create a .nuspec and point to that folder to create a Octo-deployable runnable version of my tool, however on my build server I have no VS installed (just the .net core sdk, the VS 2017 build tools and some target packs), and I see no way how to trigger the pubxml publish process on the build server.

So the questions boil down to these:

• Is there a way to trigger VS publish using dotnet msbuild and if yes how is it done
• Is there a way to make nuget publish behave the way it would feel correct and create a deployable, runnable version of my project including configuration and dependencies?

[lorddev]

@gingters maybe this will work?

  <ItemGroup>
    <None Include="config.json" Pack="true" PackagePath="config.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
  </ItemGroup>

[quarion]

Currently we are having the same problem when migrating projects from old .csproj and .nuspec to new .csproj format.

How to reproduce (using VS 2017):

• Create CommonLib.csproj project, it should not be published as NuGet package.
• Create ProjectA.csproj project, it should be published as NuGet package.
• Add project reference from ProjectA to CommonLib.
• Pack the ProjectA (with Visual Studio or CLI).

Expected result:

• ProjectA.nupkg is created. It contains ProjectA.dll and CommonLib.dll.

Actual result:

• ProjectA.nupkg is created. It contains only ProjectA.dll. CommonLib is added as a NuGet dependency.

Side note:
I have tried to add <IsPackable>false</IsPackable> property to the CommonLib.csproj, but it is not take into the consideration.

I have created a new ticket for this, to make it clear that it is strictly related to new .csproj based workflow.
https://github.com/dotnet/cli/issues/6707

[mattwhetton]

I'm having the same issue with new csproj file format

[bitfringe]

So I see this is successfully being ignored. Good job...

[dasMulli]

For anyone that's interested, I have a sample up at https://github.com/dasMulli/nuget-include-p2p-example to show how to include project-to-project references in NuGet packages that work with dotnet pack / msbuild /t:Pack. However it requires to manually maintain a .nuspec file when you add dependencies or change/add target frameworks (along with content/contentFiles).

A csproj-integrated workaround would be to use a custom target to create None items before the _GetPackageFiles target or _PackageFile items before the GenerateNuspec target (to include items at known build output locations).

[bitfringe]

@dasMulli So if understand this correctly, the only "magic" is happening in LibA.csproj where you specify nuspec file and properties so that dotnet pack can pick those up and use them. Am I correct? Otherwise a nice workaround. Been thinking about using manual nuspec file either way. Thank you.

[iiwaasnet]

Why I can't decide myself, if I need to publish each project of a solution as separate nuget package or not? Projects might be used to enforce clear design for big solutions, although, they might not make sense as separate packages. .NET Core, it becomes a mess, instead of a progress...

[VictorGavrish]

I'm having to work around this it by using oldschool nuget pack and a .nuspec... I'd really like to just dotnet pack and let the tool figure out dependencies and metadata and stuff, but I unfortunately cannot do that.

[dasMulli]

There actually is a ""simpler"" solution at the moment, involving adding and hooking up a custom target (tested on latest released bits):

<Project>
  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <TargetsForTfmSpecificBuildOutput>$(TargetsForTfmSpecificBuildOutput);IncludeP2PAssets</TargetsForTfmSpecificBuildOutput>
  </PropertyGroup>

  <ItemGroup>
    <ProjectReference Include="..\testprivatelib\testprivatelib.csproj" PrivateAssets="All" />
  </ItemGroup>

  <Target Name="IncludeP2PAssets">
    <ItemGroup>
      <BuildOutputInPackage Include="$(OutputPath)\testprivatelib.dll" />
    </ItemGroup>
  </Target>
</Project>

[vishrutshah]

@dasMulli Adding IncludeP2PAssets does correctly includes P2P dlls but did you try installing that package into other projects without having nuspec file? It's failing for me.

[vitalybibikov]

So will the issue be fixed? Currently it's a blocker for us, and the decision to edit packages before packing in order to have dependencies inside looks like the regrettable one.

[wooderz]

Same - why should I have to publish nuget packages for things like a ServiceContract project? Right now I'd be forced to putting that as a folder in my Sdk and risk circular dependencies. It's up to me as the application developer what I package surely? Having to add every dependency by hand to the .csproj file is hardly sustainable?

[sumgup]

Are there any plans to fix this issue or .net core team thinks its not a issue?

[livarcocc]

cc @rohit21agrawal to comment on it.

[rohit21agrawal]

i'll let @rrelyea comment on the timeline of this fix. Until then, we recommend the following workaround as suggested by @dasMulli : https://github.com/dotnet/cli/issues/3959#issuecomment-333318028

Currently we are tracking this issue on our side here: https://github.com/NuGet/Home/issues/3891 .

[wooderz]

@rohit21agrawal while that does indeed work, in terms of packaging - it still leaves the dependency listed so you cannot install the package elsewhere. A proper fix is still desperately needed

[rohit21agrawal]

You can add PrivateAssets=all on your project reference which will not have any other functional impact except suppressing the dependency in the generated package

[rohit21agrawal]

and please don’t get me wrong, I am not denying that a fix is needed, but I just want to make sure that the workaround works as expected

[renatotkr]

why is this closed? this is a blocking issue for large projects, it gets very confusing to manage dependencies.

[leonard-thieu]

I've written an alternative solution. It will automatically grab project outputs and dependencies (so you don't have to declare them in the packaging project). It also includes an option to exclude the packaging project's output.

Usage

• Copy WalkEachTargetPerProject.targets into your packaging project directory.
• Import it into your project.
  xml <Import Project="WalkEachTargetPerProject.targets" />
• Ensure ProjectReference items do not have PrivateAssets set to All.
• (_Optionally_) Exclude your packaging project's build output.
  xml <IncludeThisBuildOutput>false</IncludeThisBuildOutput>

Notes

I haven't tested if this includes content and framework assembly references correctly. Include sources doesn't _appear_ to be working correctly (source files are packed with incorrect-looking paths) but as I don't use the feature myself, I didn't verify if it has an actual impact.

[bluebirdtech]

We were surprised by this behavior. Can this issue be reopened and fixed?

[kwaazaar]

What a mess...

[livarcocc]

This is closed here because the fix is being tracked by NuGet here: NuGet/Home#3891.

[Cloudmersive]

This is a huge mess - why is this not fixed?

[IanKemp]

This is a huge mess - why is this not fixed?

Probably because the NuGet team are a bunch of drunken monkeys.

[akordzik]

bump

[manums]

why is this issue closed? is there an easy way to pack with multiple project references (which might have other project references). Something nuget pack <<csproj>> -IncludeReferencesProjects could do?

[axm]

3.5 years later, still not sorted. What a mess.

[mslot]

why is this issue closed? is there an easy way to pack with multiple project references (which might have other project references). Something nuget pack <<csproj>> -IncludeReferencesProjects could do?

It isn't closed. It is just tracked elsewhere: https://github.com/NuGet/Home/issues/3891

[danielmeza]

why is this issue closed? is there an easy way to pack with multiple project references (which might have other project references). Something nuget pack <<csproj>> -IncludeReferencesProjects could do?

It isn't closed. It is just tracked elsewhere: NuGet/Home#3891

So it is closed...

[mslot]

why is this issue closed? is there an easy way to pack with multiple project references (which might have other project references). Something nuget pack <<csproj>> -IncludeReferencesProjects could do?

It isn't closed. It is just tracked elsewhere: NuGet/Home#3891

So it is closed...

Theoretically, you are correct :) But i just wanted to point out that the issue is still being tracked on another issue.

[majorimi]

It is simple to solve. You just add your project as ProjectReference into your other projects. And continue development using project references. When you want to publish your packages using the same version just run:
dotnet pack -p:PackageVersion=2.1.0 also can add all other pack arguments.

Since during pack all ProjectReference will be transformed to Package dependencies. And version number is cascading into all package.

Hope it helps.

[mslot]

It is simple to solve. You just add your project as ProjectReference into your other projects. And continue development using project references. When you want to publish your packages using the same version just run:
dotnet pack -p:PackageVersion=2.1.0 also can add all other pack arguments.

Since during pack all ProjectReference will be transformed to Package dependencies. And version number is cascading into all package.

Hope it helps.

This doesn't include the referenced projects as dlls in the project being packed.

[majorimi]

You don't have to include it since you can publish your packages separately. But if you needed you can pack dependencies into a single Nuget package as well. I have answered this here.

[mslot]

It is simple to solve. You just add your project as ProjectReference into your other projects. And continue development using project references. When you want to publish your packages using the same version just run:
dotnet pack -p:PackageVersion=2.1.0 also can add all other pack arguments.

Since during pack all ProjectReference will be transformed to Package dependencies. And version number is cascading into all package.

Hope it helps.

All we want is a _simple_ pack command that adds all dlls to the package when used. See https://github.com/NuGet/Home/issues/3891.

[majorimi]

Follow the link to stackowerflow where I explained how to do it...

[nlaveck]

For anyone else struggling with this, I found a nuget package that is very similar to the solution mentioned by @dasMulli, but takes care of copying and resolving the dll paths for you with any reference marked as PrivateAssets="all".

https://www.nuget.org/packages/Teronis.MSBuild.Packaging.ProjectBuildInPackage/