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

[ljw1004]

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

[fubar-coder]

The first three points are bugs and will be (most likely) fixed. The last one will be fixed when the consumer of your package uses the lastest NuGet client. Otherwise, you're always able to specify multiple frameworks for your project with their own set of dependencies.

[ThinkAboutGitHub]

Has there been any progress on this issue? I really would like to provide my own Nuspec file also, so that the Authors and other information is correct.

[TheRealPiotrP]

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

[waynebrantley]

1.0.0-rc3-004530 released on 1/20/17 - pack still ignores nuspec file.
Additionally there is not a dotnet nuget pack in this version.

[natemcmaster]

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

[waynebrantley]

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

[derekgreer]

"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)" />).

[lindydonna]

Is there an update on this? Need to be able to specify max version for a dependency, and it looks like there isn't a way to do this.

Edited: apparently you can use version specs in csproj file directly, so nuspec shouldn't be required for my scenario.

[plioi]

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.

[dasMulli]

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)

[plioi]

@dasMulli Great, thanks!

[georgekargakis]

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

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

[RaringCoder]

@dasMulli That was immensely helpful, thanks.

[mattfrear]

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

[RaringCoder]

@mattfrear Hi Matt. Can't remember how long I wasted being honest. I haven't got the scripts in front of me but basically I parameterised the csproj. That said, the end result is the same and in hindsight I should have used the csproj directly, to my recollection there was no reason I couldn't do that. At the time I was just using nuspec to drive a convention in our build scripts.

[Styxxy]

@dasMulli Nice solution, though one minor bug (not in your case). When having special characters like &, they need to be re-encoded.

In my case I fixed it with a dirty replace:

<NuspecProperties>$(NuspecProperties);authors=$(Authors.Replace("&amp;", "&amp;amp;"))</NuspecProperties>

[mwpowellhtx]

@ljw1004 I just ran into the same, literally today, and it is STILL incorrect. Would be nice to at least specify your own .nuspec, pulling it forward from prior versions of the same projects. :-1:

In my case I've got things like:

<id>$id$</id>
<title>$id$</title>
<owners>$author$</owners>

But $author$ is still emitting as though it were $id$.

Note that I am leveraging the AssemblyInfo attributes, pulling them forward from prior versions of the same project, which should be emitted via the NuGet integration paths.

[mwpowellhtx]

@mattfrear I think you may be on to something there. I don't mind the tooling comprehension, but TBH, it's one more stack I have to learn in the shifting sand of tooling changes. As contrasted with, I'd like for my packaging concerns to be consistent with prior versions and maintain some level of loose coupling at the tooling integration level.

@dasMulli This is a marginally acceptable workaround, IMO, as it is just one more thing I have to be concerned with migrating projects forward. I think that the .nuspec file should be consumed, and certain defaults should be acceptable from AssemblyInfo attribution, as before. Still, good to know; thanks for that.

[mwpowellhtx]

Question, @mattfrear, where are the PackageProjectUrl, or PackageSuchAndSuch, tags, documented? I cannot seem to find references to them anywhere. Sort of answered my own question, I suppose.

[dasMulli]

the properties are documented at the NuGet pack and restore as MSBuild targets document. I do think that this is hard to find since you need to know what you're looking for (msbuild targets) ((and @guardrex pointed me to it a few months ago)).. cc @kraigb maybe

@mwpowellhtx just out of curiosity (I don't work for MS/NuGet): are you upgrading projects from "classic" csproj to new sdk-style csproj or upgrading from packages.config to PackageReference?

[mwpowellhtx]

@dasMulli Exactly. From desktop .NET Framework into the world of .NET Standard. It's something of a paradigm shift, and I've been a bit hesitant to get started on that path, not least of which is all the shiny nuance that I have to sift through, never mind lack of documentation in much of the online docs, i.e. Roslyn documentation. But that said, so far so good. Digestion is a slow, time consuming process.

[mattfrear]

Question, @mattfrear, where are the PackageProjectUrl, or PackageSuchAndSuch, tags, documented? I cannot seem to find references to them anywhere. Sort of answered my own question, I suppose.

@mwpowellhtx to answer your question, I linked to the page that I found where the NuGet properties in the .csproj is documented, in my original answer. The page is here https://docs.microsoft.com/en-us/dotnet/core/tools/csproj#nuget-metadata-properties

[kraigb]

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.

[Cloudmersive]

How are you supposed to specify the nuget package icon when using dotnet pack? The docs are useless on this point

[wli3]

Here is an example

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

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <PackageIconUrl>https://raw.githubusercontent.com/NuGet/Media/master/Images/MainLogo/256x256/nuget_256.png</PackageIconUrl>
    <TargetFramework>netcoreapp2.1</TargetFramework>
  </PropertyGroup>

</Project>

https://github.com/NuGet/NuGet.Client/blob/1123779dd300afb48ae6d6d61fc69eaf9469aec1/build/config.props
@rohit21agrawal is there any documentation for the mapping?

[rohit21agrawal]

https://docs.microsoft.com/en-us/nuget/reference/msbuild-targets#pack-target

[pshirshov]

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

[dquist]

An easier way is to abandon the .nuspec file altogether and instead set the NuGet properties in the .csproj.

That works fine until you decide you want to include an icon and find that <iconUrl> is deprecated in favor of <icon> which has no .csproj counterpart.

[wli3]

@nkolev92

[nkolev92]

@dquist

There is one: https://docs.microsoft.com/en-us/nuget/reference/msbuild-targets#packing-an-icon-image-file

Those docs don't seem to be up to date.

Created an issue for that.
https://github.com/dotnet/docs/issues/14411

fyi @dominofire @karann-msft

[knocte]

So it seems you still cannot feed a .nuspec file to dotnet pack even if this issue is marked as closed? In my case it seems I cannot use the workarounds mentioned here because they apply to single projects, however in my scenario I have a .nuspec file that gathers many DLLs from many projects to be included in the same nuget package. I'm at a loss here I guess.

[livarcocc]

You should file an issue on nuget/home for this or see if they have one there already. Odds are that they already have a bug tracking this ask.

[knocte]

You should file an issue on nuget/home for this

But nuget pack allows to provide a nuspec file, it's dotnet pack that doesn't.

[nkolev92]

@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