Customizing Assembly Versions in Visual Studio Builds

I discuss my issues with Visual Studio's lack of in customizing version numbers during build. I prefer using a Major.Minor.BuildDate.Revision format.

One thing I’ve never really been fond of in Visual Studio is the fact you can’t specify a custom format for your assembly version numbers when you build your projects. Sure, you could use the asterisk to tell MSBuild to increment the number, but what if you wanted to have the date of the build in the assembly version? I like the way Microsoft does their assembly version format: Major.Minor.BuildDate.Revision. So, you can tell that the .NET 2.0 Framework (v2.0.50727) was built on July 27, 2005. Wouldn’t it be nice if this was done for you?

I had never taken the time to update it until last night when I was working on a pet project (more on that hopefully later this week). Late last year the MSBuild team posted a release of the AssemblyInfoTask project on GotDotNet . After installing this project, you can specify a format string for your dynamically generated assemblies. Here’s how you’d do it:

  1. Download & install the latest release (as of this post, v1.0.51130.0) form the AssemblyInfoTask GDN CodeGallery.

  2. Unload your project in Visual Studio.

  3. Edit your project file and add the following import node at the end of all other import nodes to tell MSBuild to import the new Microsoft.VersionNumber.Targets file (assuming you installed AssemblyInfoTask to the GAC… otherwise see the documentation for the other import node to use):

    <Import Project="$(MSBuildExtensionsPath)\\Microsoft\\AssemblyInfoTask\\Microsoft.VersionNumber.Targets"/>
  4. Save & close the project file & reload your project.

  5. Make sure all your AssemblyInfo.cs project files specify version for the AssemblyVersion & AssemblyFileVersion (requirement of AssemblyInfoTask).

What if you want to change the Major.Minor version from the default 1.0 that the Microsoft.VersionNumber.Targets file specifies? The documentation tells you how, but it’s not very clear. What you have to do is create a new node and add four nodes that are used by AssemblyInfoTask… but the trick is to add this group AFTER the node that imports the Microsoft.VersionNumber.Targets file which will override what is in that file. Here’s what I did to change it to build my project as 0.2.yyMMDD.revision:

  1. Unload your project in Visual Studio.

  2. Edit your project file and add the following XML immediately after your the node you added as shown in step #3 above (notice, we don’t have to worry about the build & revision portion of the version number as that’s handled in the targets file we’re importing):

  3. Save & close the project file & reload your project.

SubVersion Fix:

Because I use SubVersion for my local source control, I had a little more work to get this to work. SubVersion creates a .svn hidden directory in all directories. Sparing you from the SubVersion details here, when I built my project, it would choke. Why? By default the Microsoft.VersionNumber.targets file was set to traverse the entire source tree looking for AssemblyInfo.*. This isn’t what you want because it will try to find one in the .svn hierarchy somewhere and throw an error when it’s not found. To fix this, open the Microsoft.VersionNumber.targets file, find the node and modify it to exclude anything in the .snv directory like this:

<ItemGroup><AssemblyInfoFiles Include="**\\AssemblyInfo.*" Exclude="**\\.svn\\**\\*.*"/>ItemGroup>
Andrew Connell
Developer & Chief Course Artisan, Voitanos LLC. | Microsoft MVP
Written by Andrew Connell

Andrew Connell is a web & cloud developer with a focus on Microsoft Azure & Microsoft 365. He’s received Microsoft’s MVP award every year since 2005 and has helped thousands of developers through the various courses he’s authored & taught. Andrew’s the founder of Voitanos and is dedicated to helping you be the best Microsoft 365 web & cloud developer. He lives with his wife & two kids in Florida.

Share & Comment