Я делал так (кстати эта метода подробно описана или в MSDN или KB TEchNet ща уже точно не помню, тк это давно было, а потом отпала необходимость в автоматическом увеличении билда):
1. Поскольку *.rc модифицируется автоматически визуальным редактором по законам, которые одному БГу известны, существует незаметный файл *.rc2. В него выносится весь блок Version
/////////////////////////////////////////////////////////////////////////////
//
// Version
//
#include "VersionNo.h"
VS_VERSION_INFO VERSIONINFO
FILEVERSION FILEVER
PRODUCTVERSION PRODUCTVER
... дальше по тексту
2. Вводим доп. .h файл с дефайнами для версий продукта и файла - численной и строковой - в моём примере это VersionNo.h и инклудируем его. Это делается для удобства парсинга. Он выглядит так, у меня просто версия файла и продукта всегда совпадают, у кого это не так ясно, что нужно сделать:
#define FILEVER 1,0,1,0
#define STRFILEVER "1. 0. 1. 0\0"
#define PRODUCTVER FILEVER
#define STRPRODUCTVER STRFILEVER
3. Пишем небольшой VB C# и тд скрипт, у кого на что ума хватит, который парсит этот .h-файл и увеличивает последнюю цифру в версиях на 1. Вот так выглядит файл после работы этого скрипта:
#define FILEVER 1,0,1,1
#define STRFILEVER "1. 0. 1. 1\0"
#define PRODUCTVER FILEVER
#define STRPRODUCTVER STRFILEVER
Ессно, что в этом месте можно делать ВСЁ что угодно.
4. Указываем имя скрипта в соответствующем поле Pre-Build Event или Post-Build Event, как кому какая логика больше нравится.
Я делал это в пост. Те я компилировал текущую версию, после этого у меня увеличивался билд. Те я работаю с версией, которая будет скомпилирована. Но это не есть стандарт.
Ну и в принципе ясно что с этими эвентами можно запускать любые скрипты для любых задач. Например подготовки языковых ресурсов, радикального изменения линкуемых библиотек (типа динамического MSLU), переименовывания и копирования получившихся бинарников и тд и тп