When passing in the msbuild property /p:BuildVersionNumber - this number is appended to the version number in your module's manifest file, to produce the version Number for the NuGet package that is produced for your module.
The idea is, that you can pass in an incrementing number, from a build server for example, and the NuGet deployment packages that are produced will automatically have an incremented version number, even if a developer has forgotten to update the version in the module's manifest file. This ensures each build generates uniquely identifiable deployment packages that can be traced back to said build.
However, there is some logic currently that treats this property as a cruise control build number i.e 1.0.12345.A
and reformats it to extract the 5 digit changeset number - i.e the 12345.
This is all specific to Cruise Control and needs to be removed.
Remove this formatting logic, and honour the build number passed in.
This does mean that people will have to pass in a number that is valid when appended to the version number in their modules manifest, for a NuGet package version number.
Dnn version numbers are max 3 digit, so the typical scenario would be to use 3 digit version numbers on the dnn manifest file, and then an integer value for the build number - which would produce a 4 digit numbered NuGet package, where the last digit is the build number.
When passing in the msbuild property
/p:BuildVersionNumber- this number is appended to the version number in your module's manifest file, to produce the version Number for the NuGet package that is produced for your module.The idea is, that you can pass in an incrementing number, from a build server for example, and the NuGet deployment packages that are produced will automatically have an incremented version number, even if a developer has forgotten to update the version in the module's manifest file. This ensures each build generates uniquely identifiable deployment packages that can be traced back to said build.
However, there is some logic currently that treats this property as a cruise control build number i.e 1.0.12345.A
and reformats it to extract the 5 digit changeset number - i.e the 12345.
This is all specific to Cruise Control and needs to be removed.
Remove this formatting logic, and honour the build number passed in.
This does mean that people will have to pass in a number that is valid when appended to the version number in their modules manifest, for a NuGet package version number.
Dnn version numbers are max 3 digit, so the typical scenario would be to use 3 digit version numbers on the dnn manifest file, and then an integer value for the build number - which would produce a 4 digit numbered NuGet package, where the last digit is the build number.