Differences between nuget-packing a csproj vs. nuspec

Recently, I started to pack nuget packages out of my several projects. First I started with the Package Explorer application. It is a nice tool, but it's less useful if you do continuous integration. Then I looked into specifying the nuspec template file, and passing changing data, e.g. version number, as command line arguments. Later, I wondered how to define the nuget package dependencies. As it turns out, the nuget.exe already does this based on the package.config if you specify a csproj. Moreover, it extracts relevant data like Author, Version, Copyright right from the assembly info. What I'm missing right now is the ability to specify a licenseUrl in the command line. But I wanted the question to be more generic. And so I'm asking:

What is the prefered way to pack nuget packages?

Here's a little-known fact: you can combine both! Target a csproj file, and make sure there's a nuspec file in the same directory with the same name as the csproj file. NuGet will merge the two during package creation.

So in short: target <ProjectName>.csproj, optionally add a corresponding tokenized <ProjectName>.nuspec file to be used as metadata by NuGet.exe.

It saves you from managing output location, dependencies, version, and other stuff that can be derived from the project.

For simple packages you can directly create the packages off .csproj or .vbproj. But for more advance packages, especially when you need to pull in custom files into your package, you need to use .nuspec. I usually start off with the csproj and move to nuspec as needed. You can always get the nuspec using the command nuget spec on the csproj.

https://docs.nuget.org/create/creating-and-publishing-a-package

You can specify any of the properties including licenseUrl using the Properties parameter to nuget pack

nuget pack -properties licenseUrl=http://blah

With a .csproj for Visual Studio 2017, you don't need a .nuspec file. You can actually add the values directly to your csproj and it will pick them up.

Right click the project in Visual Studio, Edit xxxxx.csproj. Notepad works fine too.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <Version>1.0.1</Version>
    <authors>Subtracts</authors>
    <TargetFrameworks>netstandard1.6;net452</TargetFrameworks>
    <AssemblyName>Checkout.net</AssemblyName>
    <PackageId>Checkout.net</PackageId>

...

</Project>

p.s. Since I don't have sufficient reputation to comment, I am leaving an answer instead of a comment on Xavier's answer. :)

With .NET Core as of February 2018 you'll need to supply a .nuspec file for any more than the basic spec file properties.

But the dotnet pack command will not use the .nuspec file unless you add <NuspecFile>relative path to nuspec</NuspecFile> to the .csproj file.

See https://github.com/dotnet/cli/issues/2170

Most packages can now be made without a .nuspec file. The thing to watch is the dependencies. You may need to add a PrivateAssets element to some that are tools, like msbump and um, SpecFlow maybe.

<PackageReference Include="msbump" Version="2.3.2">
  <PrivateAssets>all</PrivateAssets>
</PackageReference>

This stops this package dependency "flowing" to the dependencies of your package.

Also worth reading about specifying versions in the most flexible way.

https://docs.microsoft.com/en-us/nuget/consume-packages/dependency-resolution#floating-versions

And range syntax.

https://docs.microsoft.com/en-us/nuget/reference/package-versioning#references-in-project-files-packagereference