sdk: "donet pack" is not including project references

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

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>

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

What a mess…

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

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

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

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

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

@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

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

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?

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.

How about .csproj?

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

Thanks!

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.

The same for me here! Specifying “type”: “build” results in all the needed DLLs being written out to the /bin/Release/<framework>/ 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.

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

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

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

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.

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…

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.

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

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?

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

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

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

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.

  <Import Project="WalkEachTargetPerProject.targets" />
  

• Ensure ProjectReference items do not have PrivateAssets set to All.
• (Optionally) Exclude your packaging project’s build output.

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

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