Here's what I did, for stamping the AssemblyFileVersion attribute.
Removed the AssemblyFileVersion from AssemblyInfo.cs
Add a new, empty, file called AssemblyFileInfo.cs to the project.
Install the MSBuild community tasks toolset on the hudson build machine or as a NuGet dependency in your project.
Edit the project (csproj) file , it's just an msbuild file, and add the following.
Somewhere there'll be a <PropertyGroup>
stating the version. Change that so it reads e.g.
<Major>1</Major>
<Minor>0</Minor>
<!--Hudson sets BUILD_NUMBER and SVN_REVISION -->
<Build>$(BUILD_NUMBER)</Build>
<Revision>$(SVN_REVISION)</Revision>
Hudson provides those env variables you see there when the project is built on hudson (assuming it's fetched from subversion).
At the bottom of the project file, add
<Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" Condition="Exists('$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets')" />
<Target Name="BeforeBuild" Condition="Exists('$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets')">
<Message Text="Version: $(Major).$(Minor).$(Build).$(Revision)" />
<AssemblyInfo CodeLanguage="CS" OutputFile="AssemblyFileInfo.cs" AssemblyFileVersion="$(Major).$(Minor).$(Build).$(Revision)" AssemblyConfiguration="$(Configuration)" Condition="$(Revision) != '' " />
</Target>
This uses the MSBuildCommunityTasks to generate the AssemblyFileVersion.cs to include an AssemblyFileVersion attribute before the project is built. You could do this for any/all of the version attributes if you want.
The result is, whenever you issue a hudson build, the resulting assembly gets an AssemblyFileVersion of 1.0.HUDSON_BUILD_NR.SVN_REVISION e.g. 1.0.6.2632 , which means the 6'th build # in hudson, buit from the subversion revision 2632.
I'd suggest using TeamCity's AssemblyInfo patcher build feature:
http://confluence.jetbrains.net/display/TCD65/AssemblyInfo+Patcher
Just create your projects from VisualStudio, configure the build feature in the BuildSteps page (see http://confluence.jetbrains.net/display/TCD65/Adding+Build+Features), and as long as you keep the default AssemblyInfo.cs file, it will work.
This approach is working great for me.
Advantages:
- Developers can build the solution in their machines.
- You don't need to touch the .sln or .csproj files. It just works.
- By using TeamCity variables you can easily make the version number match some other project's version, etc.
Disadvantages:
- You can't easily switch to another CI server from TeamCity because you don't have a build script (but switching CI servers is like switching ORM or database: it is very unlikely and will require a lot of work anyway).
Best Answer
I would recommend you to adopt the semantic versioning scheme
{major}.{minor}.{patch}
and append a 4th element for the build number{major}.{minor}.{patch}.{build}
. This is way more useful as to include the build date into the versioning scheme.TeamCity 6.5 (you haven't specified a version) has a build feature which could be used to patch the version in the AssemblyInfo.cs during the build. See the documentation for the AssemblyInfo Patcher.
You could then define the build number format in the way you would like to have in your assembly and use the format for the build itself, as also for the patching feature.