How To: Use the AssemblyInfoTask With Source Code Control

Several people have written our feedback alias with problems using the AssemblyInfoTask when the projects are under source code control. When the files are checked in the AssemblyInfo files are read-only, and the task fails with an error that the file can't be updated.

The best way to handle this is to check the AssemblyInfo files out before running the AssemblyInfoTask. After the build completes you can then either revert the files, or check them back in with the updated version numbers.

To check the files out and then check them back in using Team Foundation Server add the following lines to your TFSProj file after the <Imports> line for Microsoft.VersionNumber.targets:

<Target Name="AfterGet" Condition="'$(IsDesktopBuild)'!='true'">
Exec WorkingDirectory="$(SolutionRoot)" Command="&quot;$(TeamBuildRefPath)\..\tf.exe&quot;
checkout /recursive $(AssemblyInfoFiles)"

<Target Name="AfterCompile" Condition="'$(IsDesktopBuild)'!='true'">
Exec WorkingDirectory="$(SolutionRoot)" Command="&quot;$(TeamBuildRefPath)\..\tf.exe&quot;
checkin /comment:&quot;Auto-Build: Version Update&quot; /noprompt /override:&quot;Auto-Build:
     Version Update
&quot; /recursive $(AssemblyInfoFiles)"

Thanks to Gautam from the Team Build team for this tip!

[ Author: Neil Enns ]

Comments (7)

  1. I don’t think release builds should be done in your development path, but basically offline and outside of the IDE. If so, why not just "attrib -r" the AssemblyInfos.

    This is what I do.

  2. Mike Fourie says:

    attrib -r may be fine as well. However, you have to be cautious to flip it back as well – mostly becuase different source code control systems have different levels of tolerance for writeable files that are not checked out, causing the system to confuse itself during get latest sources, etc.

    Generally, I agree that release builds should be done by a standalone machine and not on a developer workstation!


  3. Mike Fourie says:

    I agree, release builds shouldn’t be done on developer machines. However, even the build machine needs to get the source code somehow, and in many cases that’s through source code control. In those cases, depending on what processes you want to follow, it can be advantageous to check in the assemblyinfo files with the latest build number at the end of a successful build.


  4. Scott Ferrett says:

    I feel that whoever thought that putting version information into the AssmeblyInfo file was a good idea never had to manage a release of a product.

    To avoid the problem of this file and version control I never check it into the VCS. Instead I have an AITemplate.cs file that is the same thing, but I have a build task that copies AITemplate.cs to AssemblyInfo.cs then run the AssemblyInfoTask to set the appropriate build numbers.

  5. Raj kishore says:


    how to override readonly dll file while copying from source to destination using msbuild.Please if u have solution let me know


    raj kishore

  6. Steven Smith says:

    This afternoon I embarked on a quick (hah!) task to fix a problem with my CC.NET implementation. I&rsquo;m

  7. acyment says:

    Hi there! AssemblyInfoTask is having trouble with version that use the "*" to denote the use of a default value for a version element. e.g. VS uses 1.0.* when you create a VSIP package from scratch. Are you planning to support this scenario?



Skip to main content