build.vcs.number and AssemblyInfo

I've been using the build.vcs.number is my builds such that I'm setting up my build number as

3.0.%build.vcs.number%.{0}

I'm building using my MSBuild task and everything looks great, but a fellow developer asked me a question that I haven't been able to answer.  The microsoft AssemblyVersion only handles up to 65535 in any element in the version number.  See here

http://blogs.msdn.com/b/msbuild/archive/2007/01/03/why-are-build-numbers-limited-to-65535.aspx

If I'm using Subversion for my VCS, then it can create a build.vcs.number up to 2^31 - 1.

Does build.vcs.number account for this situation?

At the point of build.vcs.number > 65535 will my build fail?

Could build.vcs.number possibly work mod 65535 so that I never get a number greater than supported?

4 comments
Comment actions Permalink

Right, there is such issue.
Unfortunately, TeamCity does not aware of .NET Assembly wersion format. Build number for TeamCity is a simple string.
There is such problem.

To fix it you may write a build script to generate build number and than to report it into TeamCity.
See http://confluence.jetbrains.net/display/TCD7/Build+Script+Interaction+with+TeamCity#BuildScriptInteractionwithTeamCity-ReportingBuildNumber
for details.

0
Comment actions Permalink

We would also like to have the AssemblyInfo patcher writing only valid strings to the AssemblyInfo files. IMHO it must be aware of the .NET assembly version format as this is exactly what the patcher is done for. Just doing a modulo 65k would be fine for us. If this does not fit into the desing of this feature then we would like to be able to do the math in the string.
Also, introducing additional steps in msbuild files for all projects will be quite some work.

0
Comment actions Permalink

Could you please post this as an issue for TeamCity in the  http://youtrack.jetbrains.com/


You may move away from using SVN revision in the version number to prever TeamCity counter instead.

0

Please sign in to leave a comment.