OctoPack NuGet Package Version and Replacement tokens

Legacy Uncategorised
#1

Hi,

Is there a reason why OctoPack does not support the following nuspec replacement tokens?

  • $id$ The Assembly name.
  • $version$ The assembly version as specified in the assembly’s AssemblyVersionAttribute.
  • $author$ The company as specified in the AssemblyCompanyAttribute.
  • $description$ The description as specified in the AssemblyDescriptionAttribute.

It actually throws exception during build when i try to use the above tokens in nuspec file except the $version$ token, but then again it does not make use of the version token when generating the package. Infact It is always generating it as 1.0.0. I came across one discussion where this version issue can be resolve by passing it via the MSBuild command line using:

/p:OctopusPackageVersion=1.3.1

but then again i am using visual studio to build my packages for now and i would like my AssemblyVersionAttribute (e.g. 1.0.*) to be used. Is this possible ?

#2

Apology for posting the same question under “Question” group as well.

#3

Hi,

There isn’t currently a way to do this - when those tokens are used, NuGet pack needs to be called against the .csproj file, but because of the way NuGet packages things the resulting package is incorrect.

Instead, I call NuGet pack against the folder and NuSpec, but at that point assembly information isn’t available. I had an idea to write a custom MSbuld task that uses reflection to figure out the version and automatically pass that, but it hasn’t been implemented yet.

I’ve created an issue on GitHub for this:

https://github.com/OctopusDeploy/OctoPack/issues/3

Hope that helps,

Paul

#4

The following Octopack.targets uses the assembly version to create the package. Just put $version$ on nuspec file to work.

#5

the andre has a good solution … however it only works if the csproj filename matches AssemblyName defined in csproj. If you have overwritten the properties of your csproj it will no longer work.

#6

I agree Leblanc, and that’s one of the reasons I haven’t merged it yet - I think it should be possible to use an MSBuild variable to get the output assembly name for versioning but I haven’t had time to try it yet. Also, if -OctopusPackageVersion is passed from the command line, it should overwrite the value from the assembly.

Paul

#7

This has been merged in:

The /p:OctopusPackageVersion parameter will continue to take precedence.

Paul

#8