Allow additional properties to be passed to NuGet pack
It would be great if we could easily pass additional properties to the NuGet pack command without having to manually add the command in to a build script (which I can't get working, by the way). I'd like to be able to pass in the version and the commit message as properties. If this can't be done, what is the correct syntax to use in a PS script to accomplish this?
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
? | Show this help |
---|---|
ESC | Blurs the current field |
Comment Form
r | Focus the comment reply box |
---|---|
^ + ↩ | Submit the comment |
You can use Command ⌘
instead of Control ^
on Mac
Support Staff 1 Posted by Feodor Fitsner on 18 Sep, 2014 05:25 PM
If you are creating a NuGet package from
*.csproj
then version number is inferred from assembly metadata. AFAIK, you can specify only version number fromnuget pack
command line. If you are building from*.nuspec
all variables must be substituted (by updating XML) before callingnuget pack
. To use AppVeyor build version variable in PowerShell you can use:Let me know if you have any questions.
2 Posted by Scott Dorman on 18 Sep, 2014 05:46 PM
The version number is supposed to be inferred from assembly metadata but it doesn't seem to work. I always see the NuGet package version getting set to 1.0.
3 Posted by Scott Dorman on 18 Sep, 2014 05:59 PM
Here is what I have in the "After build script":
nuget pack $env:APPVEYOR_BUILD_FOLDER\src\cadru.core\cadru.core.csproj -properties "Configuration=$env:configuration;Platform=$env:platform;Version=$($env:appveyor_build_version)"
nuget pack $env:APPVEYOR_BUILD_FOLDER\src\cadru.core\cadru.core.csproj -symbols -properties "Configuration=$env:configuration;Platform=$env:platform;Version=$($env:appveyor_build_version)"
This fails with the following errors:
nuget pack $env:APPVEYOR_BUILD_FOLDER\src\cadru.core\cadru.core.csproj -properties "Configuration=$env:configuration;Platform=$env:platform;Version=$($env:appveyor_build_version)"
39nuget pack $env:APPVEYOR_BUILD_FOLDER\src\cadru.core\cadru.core.csproj -symbols -properties "Configuration=$env:configuration;Platform=$env:platform;Version=$($env:appveyor_build_version)"
40Attempting to build package from 'cadru.core.csproj'.
41nuget : Unable to find 'Cadru.Core.dll'. Make sure the project has been built.
42At line:1 char:1
43+ nuget pack $env:APPVEYOR_BUILD_FOLDER\src\cadru.core\cadru.core.csproj -properti ...
44+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
45 + CategoryInfo : NotSpecified: (Unable to find ...has been built.:String) [], RemoteException
46 + FullyQualifiedErrorId : NativeCommandError
47
48Attempting to build package from 'cadru.core.csproj'.
49nuget : Unable to find 'Cadru.Core.dll'. Make sure the project has been built.
50At line:2 char:1
51+ nuget pack $env:APPVEYOR_BUILD_FOLDER\src\cadru.core\cadru.core.csproj -symbols ...
52+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
53 + CategoryInfo : NotSpecified: (Unable to find ...has been built.:String) [], RemoteException
54 + FullyQualifiedErrorId : NativeCommandError
55
56Command executed with exception: Unable to find 'Cadru.Core.dll'. Make sure the project has been built.
Support Staff 4 Posted by Feodor Fitsner on 18 Sep, 2014 06:11 PM
You are passing
configuration
andplatform
into nuget pack command. Is project built with the same props? Try adding-Verbosity detailed
to nuget pack command to see what's going on. Also, you can add-Build
option to make sure the project has been built.5 Posted by Scott Dorman on 18 Sep, 2014 06:13 PM
I'm basically trying to match the command line that would automatically be used if I checked the "Package NuGet projects" option.
Support Staff 6 Posted by Feodor Fitsner on 18 Sep, 2014 06:15 PM
OK, do you get any errors with "Package NuGet projects" option checked?
7 Posted by Scott Dorman on 18 Sep, 2014 06:15 PM
Correct, no errors when that option is checked.
Support Staff 8 Posted by Feodor Fitsner on 18 Sep, 2014 06:20 PM
Then try using exactly the same command as you see in the build log. For symbols just add another command with appropriate option.
9 Posted by Scott Dorman on 18 Sep, 2014 06:21 PM
I was trying to avoid hard-coding full paths and variable values, but I'll try it and see if that works.
10 Posted by Scott Dorman on 18 Sep, 2014 06:23 PM
So the actual command generated when I check the Package NuGet projects option looks like this:
nuget pack "C:\projects\cadru\src\Cadru.Core\Cadru.Core.csproj" -Properties "Configuration=Debug;Platform=AnyCPU" -OutputDirectory "C:\Users\appveyor\AppData\Local\Temp\w9sthuye54"
The problems I have are:
1. The configuration will change depending on whether it's running a debug or release build.
2. I don't know what the output directory will be each time the build runs, although I think that's optional.
Support Staff 11 Posted by Feodor Fitsner on 18 Sep, 2014 06:30 PM
OK, I think I know where the problem is with your original command. It's
platform
parameter. When you set it toAny CPU
on UI it setsplatform
toAny CPU
(with space). When building solution AppVeyor takes correct platform value for the project from solution file, which isAnyCPU
(no space). This is why nuget pack complains the project is not built.I think you can get back to your initial command, but use hard-coded or set another variable for platform:
or add another environment variable on project settings, say
nuget_platform=AnyCPU
and then:12 Posted by Scott Dorman on 18 Sep, 2014 06:49 PM
That was the problem. Since I'm always building AnyCPU (and have no plans to do otherwise) I opted to just hard-code the value. The only reason I even need to do this is that NuGet doesn't seem to be pulling the version metadata properly.
I don't think that's an AppVeyor problem, though you could work around the bug by including the version in the properties list like I'm doing.
Support Staff 13 Posted by Feodor Fitsner on 18 Sep, 2014 07:35 PM
Cool, thanks for the update!
14 Posted by Scott Dorman on 19 Sep, 2014 03:33 AM
It looks like this issue has been fixed in NuGet 3.0, which isn't released yet (of course). The workaround for now is to explicitly specify the version using the -Version option.
Scott Dorman closed this discussion on 01 Sep, 2017 01:06 PM.