Is there any way for Octopack to auto increment the version number of the NuGet packages?
Hi,
Thanks for getting in touch! Copied right from the Octopack documentation on Github:
When you use OctoPack, the NuGet package version number will come from (in order of priority):
1 - The command line, if you pass /p:OctoPackPackageVersion= as an MSBuild parameter when building your project
2- The [assembly: AssemblyVersion] attribute in your AssemblyInfo.cs file
I personally recommend the 2nd option,
Hope that helps!
Dalmiro
Thanks for your note but I should have mentioned that I reviewed those and they do not fit the need.
The need is for Autopack to determine the last Nuget package version and increment that, automagically, the next time I run Octopack. I want all of this to happen without any user intervention.
Hi,
Octopack works at the build level and it can only get values from those 2 options mentioned above. There is a 3rd option where Octopack can get the values from a Nuspec file added by you but this wont help you either, as you’ll have to manually insert the value.
The only possible way would be for you to add a step to your build process where you fetch the value of your last package version (from your nuget feed or anywhere else where you have these values stored) and then pass that value to octopack using /p:OctoPackPackageVersion
Thanks,
Dalmiro
I’m working on a solution that involves manually creating the nuspec file. But I see nowhere in the documentation that explains where the nuspec file should be placed.
So, where should I put the nuspec file?
Hi,
You were right, we did not explain where the nuspec file was supposed to be placed. Thanks to your heads up we added that info to our documentation. Open it again and look for this line:
“The nuspec file needs to be in the same directory as your csproj file.”
When you run octopack using your own nuspec, Octopack will use the AssemblyInformationalVersion to version your package. If you want it to fall back to the value on your Nuspec file, you’re gonna have to comment the following lines on “[YourProject]\packages\OctoPack.x.x.x.x\tools\OctoPack.targets”
https://github.com/OctopusDeploy/OctoPack/blob/master/source/tools/OctoPack.targets#L47-L49
Hope that helps!
Dalmiro
Thanks! In the interim I was able to setup a simple text file – and a batch file that auto-increments the version number. I then pass that updated version number along to the comment line for OctoPack. It’s working well now, until we can come up with a slightly more elegant solution!
@Dalmiro: I have a similar issue/question. What I would like to achieve is that the nuspec-version should be derived from: 1. The Assembly-version information, 2. The build number.
You say that Octopack works at the build level, fine In the CI-process, the build number is available. Btw: @md.odw: If your process is fully automated, the build number should map 1-1 with the “last package version” right? Maybe you can use the upcoming solution to my question to achieve what you want?
Example:
- A web site with [assembly: AssemblyInformationalVersion(“0.9.1-beta”)
- Build using TeamCity of TFS, packed with OctoPack
If “OctoPack package version” is not specified during the build, Octopack will pick up information from assemblyinfo, great! But how can we append the build-number to the version here? What I would like is the NuGetPackage to have version: 0.9.1-beta-[build number from teamcity here]
Most solutions/suggestions I see online involves completely definind the version outside of Visual Studio, eg in TeamCity, but it seems sub-optimal. The developer knows at the time of changing the code if there should be changes to the major/minor/patch-parts of the version information and he/she should be able to specify this information at checkinand then not having to worry about that anymore.
So my question is: How can I “append” version information (build number) to the NuGet version information created by OctoPack during the automated build process?
Ok, I have a solution that works for me, hopefully it is useful to anyone else. The overall process looks like this (using TeamCity):
- use msbuild to run a custom msbuild target that will parse the AssemblyInformationalVersion into Major/Minor/Patch-variables (see http://stackoverflow.com/questions/2042350/how-to-read-the-assemblyversion-from-assemblyinfo-cs/28363076#28363076 Answer by Emil G at the bottom)
- Have Your build server pick up/redefine configuration parameters (in TeamCity this can me made by using service messages ##teamcity[setParameter…] based on the output of your custom msbuild target
- Now you have Major/Minor/Patch and buildnumber from your server, you can define a complete (semver) version number on the form: {Major}.{Minor}.{Patch}-{Prerelease}+{BuildNumber} (except NuGet doesnt fully support SemVer so you’ll have to use -{BuildNumber instead}.
There were some quirks in TeamCity that took some time to figure out (configuration variables have to be defined in a previous step to OctoPack. I can provide more details if someone needs it.
I ended up doing the exact same thing that mdw-od had done. Came here looking for a more elegant solution, but I suppose there is none.
here’s the batch file that I run:
set /p version=<version.txt
call “%VS120COMNTOOLS%\vsvars32.bat”
msbuild [YOUR SOLUTION FILE] /t:Build /p:Configuration=Release /p:RunOctoPack=true /p:OctoPackPublishPackageToHttp=http://dragon/deploy/nuget/packages /p:OctoPackPublishApiKey=API-AY5YAKRUW9SHZN0H4VGWIYC3Q /p:OctoPackPackageVersion=1.0.0.%version%
@echo off
if not exist version.txt >version.txt echo 0
for /f %%x in (version.txt) do (
set /a var=%%x+1
)
version.txt echo %var%
Save that as a .bat file. It will create the “version.txt” file if it doesn’t exist. If you’re using VS, you can then add the batch file as an external tool, and then add that external tool to your toolbar to achieve a one-click Pack & Push functionality.
The problem I have with this is that the version file keeps getting locked by my source control, so I have to manually check it out every time I want to pack&push.
What I wish I could do is simply put in the msbuild command:
/p:OctoPackPackageVersion=increment
or something similar
Based on this:
If you modify assemblyInfo.cs from:
[assembly: AssemblyVersion(“1.0.0.0”)]
[assembly: AssemblyFileVersion(“1.0.0.0”)]
to:
[assembly: AssemblyVersion(“1.0.*”)]
//[assembly: AssemblyFileVersion(“1.0.0.0”)]
And then in OctoPack.Targets you change:
1.0.0.0
to:
Then You’ll get incrementing version numbers set by the assembly 
Example attached.
I like it, but why comment out the file version?
I have another problem with this solution. I changed the version number as follows:
[assembly: AssemblyVersion(“2.0.*”)]
//[assembly: AssemblyFileVersion(“1.0.0.0”)]
The resulting AssemblyVersion on the build DLL seems bizarre:
2.0.5724.24831
Any ideas how I can get rid of the .5724.24831?