Octopack dumps NuGet help during build

So a few setup points first. I have added the NuGet OctoPack to my project and I have modified the csproj file to have true in the debug property section so that building thru vs.net also triggers an octopack build.

When I build the project I get this output. The nuspec file is generated (and now copied from my root to the octopacking folder, but the obj\octopacked folder is empty post build.

1>------ Build started: Project: AccountService, Configuration: Debug Any CPU ------
1> AccountService -> C:\code\Services\AccountService\bin\AccountService.dll
1> OctoPack: Written files: 196
1> OctoPack: Files will not be added because the NuSpec file already contains a section with one or more elements and option OctoPackEnforceAddingFiles was not specified.
1> OctoPack: pack: invalid arguments.
1> OctoPack: usage: NuGet pack <nuspec | project> [options]
1> OctoPack:
1> OctoPack: Creates a NuGet package based on the specified nuspec or project file.
1> OctoPack:
1> OctoPack: Specify the location of the nuspec or project file to create a package.
1> OctoPack:
1> OctoPack: options:
1> OctoPack:
1> OctoPack: -OutputDirectory Specifies the directory for the created NuGet package file. If not specified, uses the current directory.
1> OctoPack: -BasePath The base path of the files defined in the nuspec file.
1> OctoPack: -Verbose Shows verbose output for package building.
1> OctoPack: -Version Overrides the version number from the nuspec file.
1> OctoPack: -Exclude + Specifies one or more wildcard patterns to exclude when creating a package.
1> OctoPack: -Symbols Determines if a package containing sources and symbols should be created. When specified with a nuspec, creates a regular NuGet package file and the corresponding symbols package.
1> OctoPack: -Tool Determines if the output files of the project should be in the tool folder.
1> OctoPack: -Build Determines if the project should be built before building the package.
1> OctoPack: -NoDefaultExcludes Prevent default exclusion of NuGet package files and files and folders starting with a dot e.g. .svn.
1> OctoPack: -NoPackageAnalysis Specify if the command should not run package analysis after building the package.
1> OctoPack: -ExcludeEmptyDirectories Prevent inclusion of empty directories when building the package.
1> OctoPack: -IncludeReferencedProjects Include referenced projects either as dependencies or as part of the package.
1> OctoPack: -Properties + Provides the ability to specify a semicolon “;” delimited list of properties when creating a package.
1> OctoPack: -MinClientVersion Set the minClientVersion attribute for the created package.
1> OctoPack: -Help (?) help
1> OctoPack: -Verbosity Display this amount of details in the output: normal, quiet, detailed.
1> OctoPack: -NonInteractive Do not prompt for user input or confirmations.
1> OctoPack:
1> OctoPack: For more information, visit http://docs.nuget.org/docs/reference/command-line-reference
1> OctoPack:
1> OctoPack: OctoPack successful
========== Build: 1 succeeded, 0 failed, 26 up-to-date, 0 skipped ==========

Once I turned on more detailed MSBuild logging in vs.net, I found this:

1> OctoPack: Running NuGet.exe with command line arguments: pack “C:\code\Services\AccountService\obj\octopacking\AccountService.nuspec” -NoPackageAnalysis -BasePath “C:\code\Services\AccountService” -OutputDirectory “C:\code\Services\AccountService\obj\octopacked” -Version Developer build

The -Version Developer build is the problem.

However, that “Developer build” is being pulled from the AssemblyInformationalVersion property of the dll, which can contain text and not just numbers.

Hi Chris,

Thanks for getting in touch. There are a number of ways that OctoPack figures out which version number to use, from top to bottom:

  • Whatever you pass in using /p:OctoPackPackageVersion=1.0.3
  • AssemblyInformationalVersion
  • AssemblyVersion

If you need to use AssemblyInformationalVersion for something else and it can’t contain a valid SemVer, then you’ll need to pass it explicitly as an MSBuild parameter.

Hope this helps!



Although helpful this to me would seem like a bug. AssemblyInformationalVersion shouldn’t be parsed as a version number. MSDN documentation refers to using various other types of information “For example, an informational version could be “Common Language Runtime version 1.0” or “NET Control SP 2”.”(https://msdn.microsoft.com/en-us/library/51ket42z(v=vs.110).aspx). We use this to disambiguate the level of quality expected (pre-alpha/alpha/beta and the service release levels). It’d be more helpful for them to be:

  • Command-line switch
  • AssemblyVersion
  • AssemblyInformationalVersion