Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dotnet pack doesn't let me provide my own nuspec #5525

Closed
ljw1004 opened this issue Mar 31, 2016 · 34 comments
Closed

dotnet pack doesn't let me provide my own nuspec #5525

ljw1004 opened this issue Mar 31, 2016 · 34 comments

Comments

@ljw1004
Copy link

ljw1004 commented Mar 31, 2016

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
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

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

@waynebrantley
Copy link

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
Copy link
Contributor

@waynebrantley Nuget team removed 'dotnet nuget pack'. See NuGet/Home#4254 for a request to bring back this functionality.

@waynebrantley
Copy link

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

@derekgreer
Copy link

derekgreer commented Apr 23, 2017

"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
Copy link

lindydonna commented Aug 9, 2017

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
Copy link

plioi commented Aug 18, 2017

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
Copy link
Contributor

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
Copy link

plioi commented Aug 18, 2017

@dasMulli Great, thanks!

@georgekargakis
Copy link

georgekargakis commented Nov 10, 2017

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
Copy link

@dasMulli That was immensely helpful, thanks.

@mattfrear
Copy link

mattfrear commented Mar 19, 2018

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
Copy link

@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
Copy link

Styxxy commented May 1, 2018

@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
Copy link

mwpowellhtx commented May 13, 2018

@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. 👎

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
Copy link

mwpowellhtx commented May 13, 2018

@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
Copy link

mwpowellhtx commented May 13, 2018

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
Copy link
Contributor

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
Copy link

@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
Copy link

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
Copy link

kraigb commented May 14, 2018

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
Copy link

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

@wli3
Copy link

wli3 commented Aug 19, 2018

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
Copy link
Contributor

@pshirshov
Copy link

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 (NuGet/Home#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
Copy link

dquist commented Sep 12, 2019

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
Copy link

wli3 commented Sep 12, 2019

@nkolev92

@nkolev92
Copy link
Contributor

nkolev92 commented Sep 13, 2019

@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.
dotnet/docs#14411

fyi @dominoFire @karann-msft

@knocte
Copy link

knocte commented Sep 21, 2019

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
Copy link
Contributor

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
Copy link

knocte commented Sep 24, 2019

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
Copy link
Contributor

nkolev92 commented Sep 24, 2019

@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 NuGet/Home#4254

@msftgits msftgits transferred this issue from dotnet/cli Jan 31, 2020
philipdaubmeier added a commit to philipdaubmeier/GraphIoT that referenced this issue Apr 17, 2020
…an no longer be built via nuget pack, the project references the nuspec file and is packed during built time. Replaced tokens in nuspec file as they dont work if dotnet pack or msbuild -t:pack is used. More info / conversation on this topic found here: dotnet/sdk#5525
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests