Why is the version in the .nuspec file ignored?

This thread is closed to comments, so I’m starting a new thread: http://help.octopusdeploy.com/discussions/questions/378-is-the-version-element-in-nuspec-file-ignored

Why wouldn’t you consider the version number in the .nuspec file? I was going to call it a bug, but you documentation (http://docs.octopusdeploy.com/display/OD/Using+OctoPack) indicates you only look at the command line or the assembly info. It just took me several iterations of trying to get the version in the .nuspec file to work before I figured out that it just doesn’t work and the documentation confirmed it doesn’t. It sure seems like you should use the version in the .nuspec file if it’s there. I’d put the priority in this order:

  1. command line
  2. .nuspec
  3. AssemblyInfo

Hi Michael,

Thanks for getting in touch! I’m sorry to hear that decision caused you problems. The most common case we see is people using OctoPack to package .NET applications, so the path of least resistance has typically been to simply inspect the application version, allowing for command-line to override. A common theme we’ve seen is that people don’t typically like to maintain/touch/tweak a .nuspec file - this is the first time someone has asked the question!

I can see some value in making OctoPack.exe work a bit more like NuGet.exe (principal of least surprise) but I can’t make it a high priority right now. The nice thing is that OctoPack.exe is Open Source Software and we’d love to accept a working pull-request, especially if this would help you with other projects! https://github.com/OctopusDeploy/OctoPack

We are going to be looking into PR’s on OctoPack after the release of v3.0.

Would you mind replying with a quick summary of how you manage versioning in your build chain? I’m interested to understand why your situation is slightly unique so we can keep it in mind for future work.

Hope that helps.


Most of our products are SaaS and the assemblies historically have not been versioned because they don’t leave our servers. Furthermore, our existing versioning scheme isn’t compatible with .Net or NuGet. I’m looking at policies and procedures and may change these things in the future, but that’s the way it has been and is now. The .nuspec file was a quick way to get some better information in a NuGet package without introducing much change to existing projects as I evaluate Octopus Deploy. If we do adopt OD I might see what I could do with .nuspec files to use the descriptive nodes to better tell me what’s in a package.

I can pass a version number on the command line, so it’s not a huge deal, but I was looking at the NuGet spec and thought it would work like that. If I don’t have a version node in the .nuspec file, it complains.

Hi Michael,

Thanks for the reply. I’m glad you took the time to get back to me with some details of your specific case.

I’ve created an Issue to track this enhancement: https://github.com/OctopusDeploy/Issues/issues/1688