A . nuspec file is an XML manifest that contains package metadata. This manifest is used both to build the package and to provide information to consumers. The manifest is always included in a package.
A NUSpec file contains package metadata and is used to create a package. A package is created from your project, which is why it would make sense to place the NUSpec file in the project folder.
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With