sdk: dotnet pack doesn't let me provide my own nuspec

When I do “dotnet pack”, it synthesizes a .nuspec. This nuspec has several problems:

  • Authors and Owners isn’t right
  • requireLicenseAcceptance is wrong for my package
  • URLs to license and product and icon are wrong
  • It only has one dependency group on “.NETStandard”, but I wish to provide additional dependency groups so that UWP and .NET46 can consume my nuget package too

I wish to provide my own .nuspec file for it to use instead.

Expected behavior

If I do “dotnet pack” and my working directory already contains a .nuspec file, then it should use that.

Or: if I do “dotnet pack -h” then it should provide information on how to provide my own nuspec file.

Actual behavior

It doesn’t do either.

Environment data

dotnet --version output: 1.0.0-beta-002133 on OSX

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Reactions: 21
  • Comments: 34 (9 by maintainers)

Commits related to this issue

Most upvoted comments

“dotnet-pack is going to be replaced by nuget pack” - https://github.com/dotnet/cli/issues/2893

And here I thought dotnet pack was intended to replace nuget pack. This tooling thrash is bonkers!

Okay, so as of April 23, 2017, should we be using nuget pack or dotnet nuget pack? If we use dotnet pack, is supporting separate nuspec files planned? Ultimately, I’m wondering how you’d go about specifying you’d like the spec to generate dependencies with ranges (e.g. <dependency id=“System.Logging” version=“[1,2)” />).

You can use dotnet pack against a project, and that csproj can include <NuspecFile>relative path here</NuspecFile> within a <PropertyGroup>. In order to get the right version number information into the nuspec, though, I have to have a build script generate that nuspec. I think what’s really missing is for this scenario to support the old $replacementtoken$ syntax, propagating values from the new csproj packaging tags.

@natemcmaster Yeah, I saw that…fine with it being gone. However, the ‘pack’ command on dotnet should use nuspec files!

FWIW (and for future googlers, as google dotnet pack nuspec lead me here) I just wasted a couple of hours trying to get dotnet pack to use my .nuspec file, just so that my NuGet package would have a description etc. An easier way is to abandon the .nuspec file altogether and instead set the NuGet properties in the .csproj.

Working example here: https://github.com/mattfrear/Swashbuckle.AspNetCore.Examples/blob/master/src/Swashbuckle.AspNetCore.Examples/Swashbuckle.AspNetCore.Examples.csproj

The replacement tokens need to be created manually when using NuspecFile, but you can see a working example here: https://github.com/dasMulli/nuget-include-p2p-example/blob/master/LibA/LibA.csproj (nuspec file is in the same folder)

Could anyone give me a hint: which one of dotnet pack and nuget pack is deprecated? From what I can understand I should prefer to use nuget pack?

nuget push is affected by a weird bug (https://github.com/NuGet/Home/issues/4286), so looks like the only working combination is to use nuget pack for packing and dotnet nuget push for pushing?

Isn’t it a bit insane? O_o

You can provide MSBuild Command properties (Nuget Metadata properties) such as NuspecFile:

dotnet pack <path to .*proj file> /p:NuspecFile=<path to .nuspec file>

preview 3 includes a new dotnet nuget command which itself provides a pack verb which accepts nuspecs.

@waynebrantley Nuget team removed ‘dotnet nuget pack’. See https://github.com/NuGet/Home/issues/4254 for a request to bring back this functionality.

@knocte

The nuget experience in dotnet is owned by nuget.client

dotnet packing a nuspec is already supported https://docs.microsoft.com/en-us/nuget/reference/msbuild-targets#packing-using-a-nuspec.

What’s not supported is packing a standalone nuspec file, without a project https://github.com/NuGet/Home/issues/4254

PS, if there are doc matters that need to be addressed, please open a new issue on https://github.com/NuGet/docs.microsoft.com-nuget because docs folks don’t monitor closed product issues.