MSBuild Team Blog : AssemblyVersionInfo

Fixing invalid version number problems with the AssemblyInfoTask

msbuild — Wed, 03 Jan 2007 21:33:00 GMT

The arrival of 2007 bought a flurry of e-mails to the MSBuild team from people having trouble with the AssemblyInfoTask. The symptom is simple to describe - the builds start to fail with the following error:

Error emitting 'System.Reflection.AssemblyVersionAttribute' attribute -- 'The version specified '1.0.70102.1' is invalid

The fix to get builds going again is to change the date format used to generate the build number to something other than the default "yyMMdd". The date formats are in Microsoft.VersionNumber.target, located in %program files%\MSBuild\Microsoft\AssemblyInfoTask, and there are two of them (one for file version and one for assembly version). You can use any format you want. Within Visual Studio we're now using 01MMdd.

Note that you may have to go in and hand-edit your assemblyinfo.* files to change their version number back to a default starting point of 1.0.0.0 to get your builds going again.

Questions or problems after doing the above? Contact us using the e-mail link at the top of this page.

[ Author: Neil Enns ]

How To: Remove the Up-To-Date Check From the AssemblyInfoTask

msbuild — Tue, 28 Mar 2006 23:57:00 GMT

Every couple of weeks I get mail from someone who is using the AssemblyInfoTask on a build machine under source control. The question typically goes like this:

I added the .targets file to my project, and it works fine on my dev machine, but doesn't do anything when I'm running it in the build lab. What's wrong? Help!

The reason it "doesn't do anything" is because the default Microsoft.VersionNumber.Targets file includes MSBuild attributes that instruct the build engine to check timestamps on input and output files. These were added because it doesn't make much sense to increment the version number on an assembly if nothing is gettting re-built. This can happen if MSBuild does an incremental build on the project.

In the build lab, however, all of the input files (.cs files, generally) and the output file (assemblyinfo.cs) wind up with the same timestamps when they are synchronized from the soruce code control server.

To resolve this, simply remove the Inputs and Outputs attributes from the <Target> tag in the Microsoft.VersionNumber.Targets file. It should wind up looking like this:

[ Author: Neil Enns ]

How To: Use the AssemblyInfoTask With ASP.NET Web Deployment Projects

msbuild — Thu, 26 Jan 2006 22:06:00 GMT

About once a week we get a question from someone who wants to know how to set the assembly version information on ASP.NET projects. I spoke with Bradley, a development lead over in the ASP.NET team who worked on the Web Deployment Projects, and it turns there are two ways you can do this.

If the only thing you're interested in doing is setting the version number on the web deployment project you can do that directly through UI properties on the deployment project instead of editing MSBuild files and downloading another task. For more information look at their walkthrough documentation.

If you want to set the version number as part of a larger build process that includes desktop assemblies and other class libraries you can use the AssemblyInfoTask and custom MSBuild XML. To make this work you need to add an assemblyinfo.cs (or .vb) to a folder called app_code under your top level directory. Once that file is there you can use the AssemblyInfoTask as you normally would to set the version number, and then use the Web Deployment Project to do the compliation of the assembly for the web.

[ Author: Neil Enns ]

How To: Use the AssemblyInfoTask With Source Code Control

msbuild — Fri, 06 Jan 2006 01:48:00 GMT

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:

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

[ Author: Neil Enns ]

How To: Retrieve the AssemblyVersion using AssemblyInfoTask

msbuild — Wed, 04 Jan 2006 22:38:00 GMT

We got a great question at msbuild@microsoft.com last week:

What is the preferred method to retrieve the version of the assembly that was just built via MSBuild? Post build, we would like to automatically create and copy the assembly(ies) to version folder.

If you are using the AssemblyInfoTask and its associated Microsoft.VersionNumber.Targets file this is really easy. Here's what you do:

Now that I look at this, perhaps "really easy" isn't the right way to describe it :) In fact, I had to have Faisal show me how to do the recursive copy, and Kieran help me figure out that a CreateItem was needed.

The $(MaxAssemblyVersion) property holds the version number for the build. This is used with the MakeDir task to create the directory. The CreateItem task is used to collect all the files from the output directory into an item group so it can then be copied recursively using the Copy task. Note the use of the RecursiveDir metadata, as described in Faisal's post on recursive copy to ensure all the files are copied as a full directory tree into the archive directory.

The condition on AfterBuild prevents the directory from being created if the MaxAssemblyVersion wasn't set during the build. This happens when none of the files changed, and nothing was re-built. Instead of depending on the $(MaxAssemblyVersion) property you could also set up the Inputs and Outputs to the target to be very specific about what file updates will trigger a copy to the archive directory.

If you're interesed in where $(MaxAssemblyVersion) comes from, it is set by the Microsoft.VersionNumber.Targets file when the AssemblyInfoTask is run. The snippet from the .targets file looks like this:

This causes the value of the "MaxAssemblyVersion" property on the AssemblyInfo class (the one in .NET code) to get stuck in the MSBuild "MaxAssemblyVersion" property after the task is run. The same thing happens for MaxAssemblyFileVersion.

[ Author: Neil Enns ]

AssemblyInfoTask Version 1.0.51130.0 is now available!

msbuild — Wed, 07 Dec 2005 22:41:00 GMT

I just posted an updated version of the AssemblyInfoTask and its source code to our GotDotNet user sample page. This new release fixes support for Visual J# projects, includes an updated installer that installs the task into the Global Assembly Cache, support for installing as a non-administrator, a few bug fixes to the help documentation, and full code-signing and strong name for the compiled assembly.

Enjoy!

[ Author: Neil Enns ]

How To: Update Assembly Version Numbers with MSBuild

msbuild — Sat, 12 Nov 2005 01:38:00 GMT

UPDATE: For information on the "Y7K" or "2007" issue, see our new blog entry.

One of our most frequently asked questions is: "How do update my assembly version numbers at build time?". Unfortunately our answer has been "you can't". Until today, that is.

I just posted a new task, AssemblyInfoTask, at GotDotNet. It provides complete support for a wide variety of version number styles, from a fixed number to numbers that change daily to numbers that increment on every build. It also supports setting other properties such as AssemblyTitle, AssemblyCopyright, etc.

Even better, we've posted the complete source code, unit tests (that run in Visual Studio Team System), and raw documentation for the task under the new Microsoft Community License. Try not to laugh too hard when you look at the code. Remember, I don't write code for a living, I'm one of those touchy-feely Program Manager people :)

If all you want to do is get Visual Studio-style build numbers, of the form 1.0.yyMMdd.revision (for example, 1.0.51111.02 for the third build today), then you simply add the following line to your project file after any existing <Imports>:

If anyone has trouble getting it to work, has comments, questions, or suggestions, please send 'em our way to msbuild@microsoft.com or post to our forum.Enjoy!

[ Author: Neil Enns ]