Automatic versioning with Team Foundation Server 2012; Enlarged only on a modified assembly

Question

I was instructed to create a new Team Foundation / Build server in my company, from which we will start a new project. I currently have no experience with TFS, so I learn all this myself. Everything is still working; The server was configured, the repository and team project were created, the build server was created, and I created a simple welcome application to check the correct source control and build continuous integration (on the build server).

However, I had a problem setting up automatic version control. I installed the TfsVersioning project and it works fine; I can determine the format for my build versions. I have not yet decided which format I will use; probably something like Major.Minor.Changeset.Revision (I know about the potential problem of using the change set number in the build version, so I can decide to switch to Major.Minor.Julian.Revision before we start development).

Problem: I do not want assemblies to have new versions of files if their source code has NOT changed since the last build. With a continuous integration build, this is not a problem, since the build server will only capture source files that have been modified, resulting in an incremental build that produces only updated modules; existing immutable modules will not be built, so their version will remain unchanged. If I set up the nightly build, I want to clear the workspace and run Build-All. However, this means that ALL assemblies will have a new version (provided that the version of the assembly file contains the assembly number).

Decision? This prompted me to consider using the latest change set number in the build file version. Thus, if nothing has been done between two consecutive Build-Alls, the versions will not increase. However, this would mean that modifying and committing in one file would increase the number of instances in all assemblies.

I am looking for one of two things:

• A way to only increase assembly version numbers if their original / dependent changes have changed since the last build. Successive Build-Alls should not cause changes in version numbers.

OR

• For testers and developers who are able to report the version of WXYZ and version WXYZ + 1, the "Foo" assemblies are identical, even if they have different versions of the files.

I probably read about 20 articles on this subject, and no one (except this guy ) seems to solve the problem. If what I am asking is not common practice in the ALM Team Foundation, how can I address the second marker point above?

Thank you for your time!

Answer 1

This is what I have done in the past. The solution has two critical points:

• You must use incremental assembly i.e. Clean Workspace = None
• The change in AssemblyInfo.cs must be calculated in each project.

This is the last most difficult, and I’ll just prepare a solution here.

In the custom MSBuild properties, use CustomAfterMicrosoftCommonTargets to introduce the hook into normal Visual Studio compilation

/property:CustomAfterMicrosoftCommonTargets=custom.proj 

Also send value for version

 /property:BuildNumber=1.2.3.4 

In custom.proj, override BeforeCompile target with something similar

 <Target Name="BeforeCompile" Inputs="$(MSBuildAllProjects); @(Compile); @(_CoreCompileResourceInputs); $(ApplicationIcon); $(AssemblyOriginatorKeyFile); @(ReferencePath); @(CompiledLicenseFile); @(EmbeddedDocumentation); $(Win32Resource); $(Win32Manifest); @(CustomAdditionalCompileInputs)" Outputs="@(DocFileItem); @(IntermediateAssembly); @(_DebugSymbolsIntermediatePath); $(NonExistentFile); @(CustomAdditionalCompileOutputs)" Condition="'$(BuildNumber)'!=''"> <Message Text="*TRACE* BuildNumber: $(BuildNumber)"/> <MyTasksThatReplaceAssemblyVersion BuildNumber="$(BuildNumber)" File="$(MSBuildProjectDirectory)\Properties\AssemblyInfo.cs"/> </Target> 

You should have the task to replace AssemblyFileVersion in the source AssemblyInfo.cs. The MSBuild Extension Pack has an AssemblyInfo task for this purpose.

I posted the full information on my blog here , here and here .