dotnet pack for .NET Core project produces .nupkg file with sources

Question

I have a simple .NET Core 2.1 class library project and need to pack it as a Nuget package. For that I'm using this command:

dotnet pack <project>.csproj --output <outputFolder> /p:Configuration=Release

But, I'm getting this warning:

C:\Program Files\dotnet\sdk\2.1.502\Sdks\NuGet.Build.Tasks.Pack\build\NuGet.Build.Tasks.Pack.targets(202,5): warning NU5100: The assembly 'obj\Release\netcoreapp2.1\<assembly>.dll' is not inside the 'lib' folder and hence it won't be added as a reference when the package is installed into a project. Move it into the 'lib' folder if it needs to be referenced.

I understand that lib folders are for targeting multiple frameworks, but I don't want that. I only want to target .NET Core 2.1.

At the end my .nupkg file is created, but it has all the source code (don't know why) and when used in other projects, they cannot reference the assemblies, because they are inside the bin\Release\netcoreapp2.1 folder.

I've seen some guides to create Nuget packages from .Net Core projects and none of them mention something related to lib folders.

I need to understand if something is missing or if I'm doing something wrong.

Thanks.

Edit: Added the project file and the .nuspec file

Project File:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netcoreapp2.1</TargetFramework>
    <Company>xxx</Company>
    <RootNamespace>xxxx</RootNamespace>
    <Product>xxxx</Product>
    <Authors>xxxx</Authors>
    <NuspecFile>xxxxx.nuspec</NuspecFile>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="AutoMapper.Extensions.Microsoft.DependencyInjection" Version="5.0.1" />
    <PackageReference Include="Microsoft.EntityFrameworkCore" Version="2.1.4" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.Relational" Version="2.1.4" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="2.1.4" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="2.0.3" />
  </ItemGroup>

</Project>

.nuspec File:

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
  <metadata>
    <id>xxxxxx</id>
    <version>1.0.0</version>
    <title>xxxx</title>
    <owners>xxxx</owners>
    <description>xxxx</description>
    <authors>xxxx.</authors>
    <copyright>Copyright 2019 xxxx.</copyright>
    <summary>xxx is a common code library for internal projects.</summary>
  </metadata>
</package>

Can you give us your .csproj? This one's going to be nice and juicy. — Joshua
Could you explain why you have a nuspec file at all? I think you should be able to specify everything in just the .csproj file. I haven't used a nuspec file for a long time. — Jon Skeet
The documentation doesn't say that .nuspec files are not needed anymore, so I like the idea to have the package properties in a separate file. But that was causing the issue. Once I removed the .nuspec file, it started to create package as expected! — Gustavo Vargas

zivkan zivkan · Accepted Answer · 2019-01-05T04:09:31

There appear to be a few misunderstandings here.

Firstly, the lib folder in the nupkg is not for multitargetting, but for all dlls that are part of the build. If your package only supports 1 target framework moniker (TFM), then your nupkg will only have a single folder under lib, for example lib/netstandard2.0/MyLib.dll, or possibly lib/netcoreapp2.1/MyLib.dll if your app uses APIs that are part of the .NET Core 2.1 runtime, but not netstandard. If your project only uses APIs that are part of netstandard, there's no benefit to targetting netcoreapp and has potential problems which might cause you issues in the future, even if it works fine today.

Secondly, a simple class library (to me this means the project only contains .cs files and no content files, no build file, the package will only contain the dll and NuGet's own files) shouldn't need to know anything about what's inside a nupkg. Even more complex projects that multitarget don't need to care about the lib folder when using an SDK style project. Just specify your target TFMs in the <TargetFrameworks> element, and let the SDK pack the nupkg itself. It knows what to do. If you've done anything in your csproj to try to force the output dll to a different location within the nupkg, it's more likely to cause problem than improve things.

Without seeing your .csproj, I cant' guess what you could have done to get that warning message on pack, but like I said, a brand new dotnet new classlib packs just fine, and if your project only contains code files, you shouldn't need anything in the csproj related to pack paths.

dotnet pack for .NET Core project produces .nupkg file with sources

1 Answers