Compartilhar via

How To: Use the AssemblyInfoTask With Source Code Control

  • Artigo

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>

<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)"/>
</Target>

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

[ Author: Neil Enns ]

Comments

  • Anonymous
    January 05, 2006
    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.

  • Anonymous
    January 05, 2006
    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!

    Faisal

  • Anonymous
    January 06, 2006
    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.

    Neil

  • Anonymous
    January 12, 2006
    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.

  • Anonymous
    May 11, 2006
    hi

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

    Regards

    raj kishore

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

  • Anonymous
    November 02, 2007
    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? TIA, Alan