Include both Nuget Package References *and* project reference DLL using “dotnet pack” 📦
Tags: nuget, dotnet, devops
Published: 2019-09-06 09:39:15

---
title: Include both Nuget Package References *and* project reference DLL using “dotnet pack” 📦
published: true
tags: Nuget,dotnet,devops
canonical_url: http://yer.ac/blog/2019/09/05/dotnet-pack-project-reference-and-nuget-dependency/
---

Original: http://yer.ac/blog/2019/09/05/dotnet-pack-project-reference-and-nuget-dependency/


Recently I have been trying to generate more Nuget packages for our dotnet core projects, utilizing the `dotnet pack` command. One issue I have been encountering is that the command was either referencing the required nuget packages, or the project reference DLLs, never both.

## The current problem.

If you have Project A which has a project reference to Project B as well as including a nuget package called Package A you would expect the generated package to contain a link to both the required nuget package, and the DLL(s) for Project B, yes? This however is not how the dotnet pack command works.

This issue is widely reported on their repo (I.e. [https://github.com/NuGet/Home/issues/3891](https://github.com/NuGet/Home/issues/3891) ) and unfortunately it seems the developers and the community are in a bit of a disagreement to what is “correct”. The official stance (as I understood it) is that the project references won’t be included as they should be their own packages. This however is not always practical or desired.

## The workaround.

Plenty of workarounds have been suggested around Stack Overflow and Github including having a seperate nuspec file, using Powershell to inject things into the generated nupkg and so on…

The solution below worked for me, but of course, YMMV.

In the end I ditched having my own `.nuspec` file within my project (as per some SO posts) and instead used the CSPROJ (as recommended). Below you can see the required fields for the packaging (version, naming, etc), a reference to a nuget package, and a reference to another project within the solution.

![CSProj Snippet of dotnet core project](https://i1.wp.com/yer.ac/blog/wp-content/uploads/2019/09/image-1.png?w=840)<figcaption>Snippet of CSPROJ with basic package info filled in.</figcaption>

If you run dotnet pack now, it will generate an appropriately named package which will contain a nuget dependancy on `SomeNugetPackage`. This can be confirmed by opening the nupkg with an archive tool (7Zip,WinRar, WinZip…) and seeing that the only DLL in the `lib` folder will be the DLL of the project being packed.

The fix is as follows:

- Alter the project reference to set the `ReferenceOutputAssembly` flag to true, and `IncludeAssets` to the DLL name

```
<ProjectReference Include="..\ProjectB.csproj">
  <ReferenceOutputAssembly>true</ReferenceOutputAssembly>
  <IncludeAssets>ProjectB.dll</IncludeAssets>
</ProjectReference>  
```

- Add the following line into the `<PropertyGroup>` element

```
<TargetsForTfmSpecificBuildOutput>$(TargetsForTfmSpecificBuildOutput);CopyProjectReferencesToPackage</TargetsForTfmSpecificBuildOutput>
```

- Add new target between `<project>` tags

```
<Target DependsOnTargets="ResolveReferences" Name="CopyProjectReferencesToPackage">
    <ItemGroup>
      <BuildOutputInPackage Include="@(ReferenceCopyLocalPaths->WithMetadataValue('ReferenceSourceTarget', 'ProjectReference'))"/>
    </ItemGroup>
  </Target>
```

So now you end up with something that looks like this

![<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <Version>1.0.9</Version>
    <Product>MyProduct</Product>
    <id>MyProduct</id>
    <PackageId>MyProduct</PackageId>
    <Authors>Your name</Authors>
    <Company>Company Name</Company>
    <Description>My library</Description>
    <Copyright>Copyright © 2019 MyCompany</Copyright>
    <TargetsForTfmSpecificBuildOutput>$(TargetsForTfmSpecificBuildOutput);CopyProjectReferencesToPackage</TargetsForTfmSpecificBuildOutput>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="SomeNugetPackage" Version="1.2.3"/>  
  </ItemGroup>
  <ItemGroup>
    <ProjectReference Include="..\ProjectB.csproj">
      <ReferenceOutputAssembly>true</ReferenceOutputAssembly>
      <IncludeAssets>ProjectB.dll</IncludeAssets>
    </ProjectReference>  
  </ItemGroup>
  <!--Next line is to ensure that dependant DLLS are copied-->
  <Target DependsOnTargets="ResolveReferences" Name="CopyProjectReferencesToPackage">
    <ItemGroup>
      <BuildOutputInPackage Include="@(ReferenceCopyLocalPaths->WithMetadataValue('ReferenceSourceTarget', 'ProjectReference'))"/>
    </ItemGroup>
  </Target>
</Project>
](https://i1.wp.com/yer.ac/blog/wp-content/uploads/2019/09/image-2.png?fit=700%2C298)<figcaption>End result CSPROJ. (Click to enlarge)</figcaption>

Now if you run dotnet pack you should see any project reference DLL under the `lib` folder of the package, and if you inspect the nuspec file inside the package (or upload it to your package repo) you should see the nuget dependencies.

Hopefully this helps someone, as there is a lot of conflicting info around. Please let me know if this would cause any issues!

The post [Include both Nuget Package References and project reference DLL using “dotnet pack” 📦](http://yer.ac/blog/2019/09/05/dotnet-pack-project-reference-and-nuget-dependency/) appeared first on [yer.ac | Adventures of a developer, and other things.](http://yer.ac/blog).