Team Build and the AssemblyInfo Task

Gautam Goenka, dev lead for Team Build v1, wrote a blog post way back in January of 2004 that laid out an approach for using the AssemblyInfo task to update version numbers with Team Build.  I refer people to this post all the time, and have never had anyone report any issues with the post…  As such, I never really looked at it too closely, and didn’t really understand how it worked. 

Earlier this week, however, a customer was running into some trouble here and I figured the time had finally come for me to dig a bit deeper. 

The idea with the AssemblyInfo task is to (a) import Microsoft.VersionNumber.targets, (b) populate the AssemblyInfoFiles item group with the list of AssemblyInfo.* files to be updated, and (c) set whatever properties you want to modify – AssemblyMajorVersion, AssemblyMinorVersion, etc.  Internally, this all works due to the following bit of markup in Microsoft.VersionNumber.targets:

<!-- Re-define CoreCompileDependsOn to ensure the assemblyinfo files are updated before compilation. -->

This adds the UpdateAssemblyInfoFiles target, which executes the AssemblyInfo task, to the dependencies of the CoreCompile target.  By convention, each of the various project types built by MSBuild declare their CoreCompile targets as follows:

  <Target Name="CoreCompile" DependsOnTargets="$(CoreCompileDependsOn)">

This is true of Microsoft.CSharp.targets, Microsoft.VisualBasic.targets, etc.  Crucially, it is also true of Microsoft.TeamFoundation.Build.targets, which defines the Team Build build process.

So – if you want to use the AssemblyInfo task to update the version numbers for an individual C# project, you can follow the above steps in your *.csproj file.  In this case, the individual C# project’s AssemblyInfo.cs file would get updated just before the project was compiled.

If, on the other hand, you want to update the version numbers for all of the projects built during your Team Build build, you can follow the above steps in your TfsBuild.proj file, as laid out in Gautam’s blog post.  In this case, all of the AssemblyInfo.* files included in the AssemblyInfoFiles item group would get updated just before Team Build starts the compilation of all of the solutions in the SolutionToBuild item group. 

Comments (8)

  1. JaapM says:

    Hello Aaron,

    I was thinking about implementing this task, but I came around the following issue:

    In one solutions I have an assembly with components and an assembly with designers for these components. So in the first assembly there are designerattributes on the components, containing strong name references to the designers. The versionnumbers in the strong name need also to be updated.

    Any ideas about that?

    Regards, Jaap

  2. Jaap,

    Well, you’ll somehow need to get all the components pointing to the right version of the designers…  There are various options here, but I think if you want to continue using strong name references all of them will end up involving the modification of at least one file.  You might try using assembly redirection via a configuration file (see to isolate the problem to one spot.  Then you’ll probably need to write a custom task to update the configuration file to use the appropriate version.


  3. Buck Hodges says:

    The AssemblyInfo task has a new home, because the CodeGallery portion of GoDotNet is being phased out.

  4. The AssemblyInfo task has a new home, because the CodeGallery portion of GoDotNet is being phased out

  5. JaapM says:


    I have solved the problem of the designer attribute versioning.

    In the AssemblyInfo.cs of a project which must point to a Design assembly, I have added:

    namespace xxx


       internal static class Designer


            public const string DesignVersion = "";



    The Designer attribute look now like:

    [Designer("DesignerClass, DesignAssembly, Version="+Designer.DesignVersion+", Culture=neutral, PublicKeyToken=aaaaaaaaaaaaaaaa")]

    I have change the AssemblyInfoWrapper a bit, so it looks also for the

    (optional) DesignVersion in the AssemblyInfo.cs. And the AssemblyInfoTask is changed to set the DesignVersion equal to the AssemblyVersion. Offcours this works only if the assembly an it’s design assembly have the same version, but that’s way we work, so just fine.

    If you are perhaps interested to see the code, I can send it to you.

    I have another problem with the AssemblyInfoTask. I’m using it in TeamBuilds. Just fine. But in some projects, I get this message in the

    buildlog: Skipping target "UpdateAssemblyInfoFiles" because all output files are up-to-date with respect to the input files.

    But it should change the version!

    Any hints on this problem?

    Regards, Jaap

  6. terrorix says:

    For error: Skipping target "UpdateAssemblyInfoFiles" because all output files are up-to-date with respect to the input files.

    I found that it does this error when solution has only one project!

    Can anybody tells why this happens?

  7. Rajesh says:


    I tried above steps, its working fine in local machine. But if I tried build from server using Default Template build definition, its not increament the revision type.

    Default Template, each time clean workspace and build it. So its automatically revision number is zero.

    I'm using TFS2010/

    Please help me to resolve this problem

  8. iGanja says:

    I would love to see an answer for this as well Rajesh. I can't get this to work at all in TFS 2010.