December 07, 2022
VSVersion Manager

Gyrum Visual Studio Version Number Manager (sorry, I could not think of anything longer than that) is a macro that fires at the beginning of the build process to update the version numbers in the AssemblyInfo.cs or AssemblyInfo.vb files. The version numbers are generated by rules you can specify. The macro reads the AssemblyInfo file, searches for the AssemblyVersion and AssemblyFileVersion lines and, using the rule specified in comment at the end of the line, updates the version number.


A version number consists of four parts separated by the '.' character. The four parts are:

  • Major Version
  • Minor Version
  • Build Number
  • Revision

For example: or 1.07.0345.6789

Each part of the version number has it's own rule and each rule part is also separated by the '.' character.

Rule Parts

Rule parts are made up of predefined tags that are used to update the related version number part.

The available rule parts are:

* - leave the version number part unchanged
+ - increment the version number by one
Y - the current year (minus 2000; i.e. 2008 returns 8)
YY - same as Y except returns two characters
YYYY - returns four digit year
M - current month
MM - current month (two characters)
D - current day of month
DD - two character day of month
h - current hour
hh - current hour (two characters)
m - current minute
mm - current minute (two characters)
s - current second
ss - current second (two characters)
YYMM - two digit year and two digit month
MMDD - two digit month and two digit day
DDhh - two digit day and two digit hour
hhmm - two digit hour and two digit minute
mmss - two digit minute and two digit second
hhmmss - two digit hour, two digit minute, and two digit second
nY - number of years from the given date (default of 1/1/2000)
nM - number of months from the given date (default of 1/1/2000)
nW - number of weeks from the given date (default of 1/1/2000)
nD - number of days from the given date (default of 1/1/2000)

Note: date parts are upper-case and time parts are lower-case.

Specifying rule part length

A rule part can have a length specifier appended to force the rule part to have a minimum number of characters. The lenght specifier takes the form ":n" where n is the desired minimum length. If the resulting number is longer than the length specified, the result is NOT truncated.

For example:

M:2 - returns a two digit month with a leading zero if required 02 for February, etc.
nW:4 - returns the number of weeks from the given date (default of 1/1/2000)

Multi-part rules

Rules can be combiled with the ";" character to create composite rules.

For example:

h:2;m:2 - returns four characters; two for the hour and two for the minute (same as hhmm)

Creating the rule

Now that you know what a rule is made of, it might be nice to actually create one.

On the same line as the version you want to apply the rule to, append a comment in the following format:


[assembly: AssemblyVersion("1.00.0806.0007")]        // Rule: *.*.YYMM.+
[assembly: AssemblyFileVersion("1.08.0627.1857")]    // Rule: *.YY.MMDD.hhmm


<assembly: AssemblyVersion("1.00.0806.0007")>        ' Rule: *.*.YYMM.+
<assembly: AssemblyFileVersion("1.08.0627.1857")>    ' Rule: *.YY.MMDD.hhmm

Notice that the AssemblyVersion and the AssemblyFileVersion each have their own rule.

Specifying the base date

The default date (1/1/2000) used in calculations can be overridden with any date of your choosing. One option is to use the date that the project was started so that the rules such as "nD" will calculate from the project start date.

To specify a custom start date, add a StartDate: entry to the rule comment like this:


[assembly: AssemblyVersion("1.00.0806.0007")]        // Rule: *.*.YYMM.+        StartDate: 1/1/2008
[assembly: AssemblyFileVersion("1.08.0627.1857")]    // Rule: *.YY.MMDD.hhmm    StartDate: 1/1/2008


<assembly: AssemblyVersion("1.00.0806.0007")>        ' Rule: *.*.YYMM.+        StartDate: 1/1/2008
<assembly: AssemblyFileVersion("1.08.0627.1857")>    ' Rule: *.YY.MMDD.hhmm    StartDate: 1/1/2008

AssemblyVersion and the AssemblyFileVersion can have different dates specified if desired.

Invalid Rules

Any rule part that generates a number greater than 65535 will cause the build to be cancelled.
An error message will be written to the output window and an entry added to the error list window.

If you want to know why I'm doing this, see here.

Global Rules

You can now specify a global rule that will apply to all projects by editing the entries
in the EnvironmenEvents macro file.

        Dim assemblyVersionRule As String = String.Empty     ' replace with your rule; default is "*.*.*.+"
        Dim assemblyFileVersionRule As String = String.Empty ' replace with your rule; default is "*.*.*.+"
The global rule will apply to all projects that do not have their own rule specified. Rules defined
at the project leve take precedence.

Lagging Version Numbers (HACK)

Since it appears that VS caches a copy of the AssemblyInfo file before the BuildEvents_OnBuildProjConfigBegin
event is triggered, the version assigned to the compiled output lags behind the version in the
AssemblyInfo file. If you are not using date/time rules, you may not care about this issue.
However, it may cause a problem for some people especially with date/time rules.

The workaround i have in place is to respone to the BuildEvents_OnBuildBegin event and process
all projects in the solution. This works fine for me, but it does mean that if you want to
build a single project in the solution, all projects will be processed by the version number
macro. Any projects that have modified files will get a new version number generated.

You can choose which method you prefer by editing the EnvironmentEvents macro file.


 Installation of the macro is a simple process in the Macros IDE:

  1. Open the VS2008 IDE
  2. From the "Tools" menu, select "Macros", then "Macros IDE..."
  3. Right-click on "MyMacros" and select "Add" then "Add Module..."
  4. Name the new module "Version" and click the "Add" button
  5. From the zip file, open the Version.txt file and copy all its contents to the clipboard. (Ctrl-A, then Ctrl-C if you didn't know already...)
  6. Replace the contents of the Version module you just created with the text you just put into the clipboard. (Ctrl-A, then Ctrl-V)
  7. Save the Version module.
  8. Open the EnvironmentEvents module (under MyMacros) by double-clicking it.
  9. Open the EnvironmentEvents.txt file.
  10. If you have no other macros in the EnvironmentEvents module, you can just replace the entire contents of it just as you did with the Version module.  
  11. If your EnvironmentEvents module already has "stuff" in it, you will need to merge the BuildEvents_OnBuildProjConfigBegin procedure from the txt file to the module file. Most likely, you can copy the lines from BuildEvents_OnBuildProjConfigBegin in the txt file and paste them in at the beginning of the existing BuildEvents_OnBuildProjConfigBegin in the module.
  12. Save everything.
  13. Select "Build" from the "Debug" menu to check for any errors or typos.
  14. Modify your AssemblyInfo file to customize you rules and dates.
  15. Modify your EnvironmentEvents file to customize your global rules.
  16. Test that the rules work to your satisfaction.

Title Description
Gyrum VSVersion 1.2


  1. Allow for global version rules.
  2. Check for invalid version numbers. (Any version part > 65535)
Gyrum VSVersion 1.1


  1. Do NOT update the version number if none of the project's files have changed. (Thanks to Sagi Matosevich for pointing this out and providing the code.)
  2. If files have changed, but the version number has not, do not update the AssemblyInfo file. (Thanks to Pavel Stoev for the feedback and code.)
  3. VS appears to cache the AssemblyInfo file before firing the OnBuildProjConfigBegin event causing the exe/dll to have a version number that is (dpending on the rule) one version behind the one in the AssemblyInfo file. The workaround I put in place is to loop through all projects in the OnBuildBegin event. This may end up updating more projects then the current build is processing, but seems to work out ok for me. (Thanks to John M. for pointing out this issue.)
Gyrum VSVersion 1.0 Initial release of VS Version Manager.