I’m seeing an issue with octopack when generating revision numbers. What seems to be happening is this:
- I kick off a build and it’s numbered 22.214.171.12445 for example. This appears as a release as I’ve set Octopus to automatically create one for each package.
- I kick off a newer build, which for some reason is numbered 126.96.36.19944. This does not create a release as Octopus see’s the number as less than the greatest package number.
Is it normal for octopack to create a lower package number at a later date? Is this something I need to be controlling?
I’ve attached a document with some images in it, in case it helps.
I think the packages should really be a) sequential in some way or b) based on creation date for ordering rather than version number.
Package_problem.docx (711 KB)
Thanks for getting in touch! When you use OctoPack, the NuGet package version number will come from (in order of priority):
- The command line, if you pass
/p:OctoPackPackageVersion=<version> as an MSBuild parameter when building your project
[assembly: AssemblyVersion] attribute in your
Those would be the first places to look to know from where is Octopack getting the version number. If you could share us the current values of those 2 configs it’ll help us getting to the bottom of the issue. Screenshots would rock.
HI Dalmiro, thanks for the swift reply.
At the moment we’re not providing the MSBuild argument explicitly, so the version should be coming from the Assembly version, we have the following setup:
// Version information for an assembly consists of the following four values:
// Major Version
// Minor Version
// Build Number
// You can specify all the values or you can default the Revision and Build Numbers
// by using the '’ as shown below:
It seems the revision numbers are non sequential.
Would that suggest we’d be better using say the build number to ensure the packages are created in order to trigger the auto releases?
Per MSDN documentation:
The format of the version string is: major. minor. build. revision.
If you put a * on the place of the revision (and hardcode the rest), its value will be equal to the number of seconds since midnight local time, divided by 2. Hence this value alone cannot be trusted to systematically increment the assemblyversion on each build. (It’ll fail if the build 1.0.0.* runs one day at 2:01pm and the other day at 2:00PM)
If you put a * on the Build (and hardcode the rest), its value will be equal to the number of days since January 1, 2000 local time. This value alone cannot be trusted to systematically increment the assemblyversion on each build (It’ll create the same number if 2 builds run on the same day)
Now, if you set both values with a *, you’ll be guaranteed to always have an incremented AssemblyVersion (hence a Nuget package version), as no 2 builds will run the same day, at the exact same second.
TL;DR : go with
Let me know how it goes
Aha, I thought it would be me doing something stupid like that!
Thanks Dalmiro, I’ve updated the assembly info to use the wildcards as suggested and this now works as expected.
Hello again Dalmiro,
Sorry for re-opening this call, I was wondering if you could help me with a related version issue.
When I originally build the project and published it to the nuget feed, it had a hard coded version number of 188.8.131.52. This caused some problems as I had a ‘bad request’ issue when ocotopack was trying to publish to the nuget feed (presumably because that package version already existed).
Oddly, I seem to keep getting the 184.108.40.206 version back every now and again (like every 10th build for example (not an exact number)) which then causes all my builds to fail with a bad request until I go and delete the 220.127.116.11 package from library > packages.
Do you have any ideas where the rogue 18.104.22.168 package is coming from?
If it’s any help, I seem sometimes to get two version pushed from octopack within 2 minutes of each other when I’ve only triggered one build. I think maybe something is cached / broken in my octopack setup as this doesn’t happen on other projects.
Any thoughts on how to clean up the octopack settings, or anywhere in octo server I could look?
Octopack_versioning.docx (433 KB)
No worries for re-opening the ticket! Are you building more than 1 project in that solution? If that is the case, have you modified the
AssemblyInfo.cs file on all the projects that you wanted to pack?
What is inside this rogue package? The same content as in the correct package?
In this solution there are several projects but only one is set to use octopack (it’s a website with a few supporting class libraries).
I’m afraid I’ve deleted the rogue package (this time) but will kick off a few builds and have a look inside when it comes back. In terms of what’s output into the ‘pairs’ of packages where are produced they seem to have the same number of items, but slightly different size on disk. Doing a quick visual comparison of the folders, even the KB sizes of each files seem to the same, so they must be multiple tiny size changes which add a few bytes to each file, when rounded they seem to total a few hundred KB.
I’m wondering whether I should clean everything down remove octopack and re-add it, perhaps something odd had got in there.
Any ideas what I’d need to clean? Are there octopack settings / configs I can remove somehow?
Is this project a website or a webapp? Octopack doesn’t work with websites, as they dont have a
I can confirm that the project is a web application (sorry I meant website in its loosest sense).
Is there anything I can do to clear things down?
I think I found the culprit.
After removing and re-adding octopack I checked my .csproj file and found this section duplicated:
I’m not sure how but I seemed to have two of these in there, which I guess may have been causing the duplicate package?
I will keep an eye on it and let you know if I hit any more snags,