We’ve been using OctoPack to produce a nuget package from our builds. This has been working fine and produced a build with a 4 part number that is deduced from the AssemblyVersion of the dll.
However, on one of our TeamCity branches the behaviour has changed to only produce a 3 part version number. The output is below and the version number is getting changed from 5.5.7.0 (correct) to 5.5.7 (incorrect). This is not happening on our other TeamCity branches for this build. The nuspec file and build scripts are unchanged. Any ideas?
OctoPack:
OctoPack: Get version info from assembly: C:\ws\git\Test\testSigCorporateAPI\Capita.SignalCorporate.Api\BuildOutput\Capita.SignalCorporate.Api.dll
Using package version: 5.5.7.0
OctoPack: Written files: 163
OctoPack: Copy file: C:\ws\git\Test\testSigCorporateAPI\Capita.SignalCorporate.Api\Capita.SignalCorporate.Api.nuspec
OctoPack: Packaging an ASP.NET web application (Web.config detected)
OctoPack: Add content files
OctoPack: Added file: Service References\Application Insights\ConnectedService.json
OctoPack: Added file: Web.config
OctoPack: Add binary files to the bin folder
…
OctoPack: Attempting to build package from ‘Capita.SignalCorporate.Api.nuspec’.
OctoPack: Setting version to 5.5.7
OctoPack: Successfully created package ‘C:\ws\git\Test\testSigCorporateAPI\Capita.SignalCorporate.Api\obj\octopacked\SignalCorporateService.Manual.5.5.7.nupkg’.
The version should be determined from the AsssemblyInfo (dll version).
I’ve investigated a bit further and it looks like when using a later version of OctoPack (3.4.1) a three part number in the nuget package is created, as opposed to the four part number with the older version of Octopack (3.0.43). I’ve changes the nuget dependency for Octopack in the project and this is the case.
e.g. Octopack 3.4.1 creates a package - SignalCorporateService.DIVI.0.22.28.nupkg
Octopack 3.0.43 creates a package - SignalCorporateService.DIVI.0.22.28.0.nupkg
Dll version is, 4 part. This is from the test site hence a different version number:
[cid:image001.png@01D20382.66D6F140]
The xml element in the nuspec file is set to 0.0.0.0. I’ve changed this to $version$ and the three part number still persists when Octopack 3.4.1 is used.
The following arguments are passed to the build:
“C:\Program Files (x86)\MSBuild\14.0\Bin\msbuild” .\msbuildSignalCorporateAPI.proj /target:ReBuild /p:Configuration=Release /p:VisualStudioVersion=14.0 /p:RunOctoPack=true /p:OctoPackAppendToPackageId=Manual /p:OctoPackPublishPackageToFileShare=Octoartifacts
We have the same issue with OctoPack 3.4.1.
We send the following arguments to MSBUILD:
/p:RunOctoPack=true /p:OctoPackPackageVersion=1.2.33.0
and it produces nugetpkg 1.2.33 which is breaks further deployment pipeline for us since it’s not exactly the same as specified.
Please could you change OctoPack to use the version given as input explicitly?
The reason behind the trailing 0 in version numbers being removed is basically because of this design choice from the Nuget team that was implemented in Nuget 3.4: https://github.com/NuGet/Home/issues/3050 .The latest version of Octopack uses Nuget 3.4, so it “suffers” from that design choice as well.
We are currently discussing with the team what to do about this. We are not fans of this behavior from Nuget, but we are also hesitant in maintaining our own branch of Nuget.exe to “fix” this version normalization, as It’ll implicate going against the Nuget wagon where all us .NET devs are trapped in.
For the time being the recommended approach is to go back to Octopack 3.0.41 which keeps the trailing 0. Unfortunately using Octopack 3.4.1 there’s no way to keep that 0.
Once we make a decision about this matter (which is being discussed right now), we’ll create a github issue and link it on this ticket.
Any update on the decision? We are having the same issue. The work around of using the old version is working but we’d like to know what direction this is going to take.
We discussed this with the team last night and decided to create a github issue to do something about it. We still haven’t come up with an approach yet, but you can follow the below issue to get a notification when we do.
