Как изменить версию приложения в visual studio

Обновлено: 06.07.2024

Всем хорош Visual Studio (хоть и не все так думают), но порядка в нем нет. Нет порядка с номерами версий и билдов, вот и изгаляются несчастные программисты создавая папки типа 08_02_2004_12_47_56 или смотрят напрягая натруженные глаза на дату создания файла. А ведь иногда хочется, чтобы и в заголовке окна любимой программы было написано V2.0 Build 2600 SP2 или что-то типа того.
В этой статье я расскажу как это сделать. Мой способ не претендует на рулезность, но работает и я им давно пользуюсь.

Мы используем возможность сборщика Visual Studio выполнять так называемый Pre-Build step. Обычно такие вещи используются для регистрации COM компонентов, но мы вдохнем в него новую жизнь.
Идея такая: будем в тех местах, где нам нужен номер версии или билда, использовать макросы, определенные в специальном заголовочном файле, а этот файл у нас будет генерировать/обновлять специальная прога, которую мы сейчас напишем.

Итак, создаем новый проект, Win32 console project под названием version, ставим поддержку для ATL и MFC и редактируем файл чтобы получилось что-то типа (если не в лом, прочитайте комментарии – сразу все ясно станет):

// The one and only application object

using namespace std;

// Разобрать макрос VERSION
arIn.ReadString(sLine);
i=0;
sLine.Tokenize("\"",i);
int nVersion1=atoi(sLine.Tokenize(".",i));
int nVersion2=atoi(sLine.Tokenize(".",i));
int nVersion3=atoi(sLine.Tokenize(".",i));
int nVersion4=atoi(sLine.Tokenize("\"",i));

// Разобрать макрос BUILD
arIn.ReadString(sLine);
i=0;
sLine.Tokenize("\"",i);
int nBuild=atoi(sLine.Tokenize("\"",i));

// Теперь обработка - увеличим номер билда
// И младший номер версии

nVersion4++;
nBuild++;
// Переоткроем файл на запись
arIn.Close();
fileIn.Close();

int _tmain(int argc, _TCHAR* argv[])
return 0;
>

int _tmain(int argc, _TCHAR* argv[])
std::cout

D:\andrew\Projects\test1\Debug>test1
Megacooltest Version 1.0.0.1 Build 1 compiled 07.09.2004 14:08:53

А теперь компилируем еще раз и опять запускаем, только выберем Rebuild solution, иначе VS подумает, что раз ничего не изменилось, то и делать ничего не надо:

D:\andrew\Projects\test1\Debug>test1
Megacooltest Version 1.0.0.2 Build 2 compiled 07.09.2004 14:10:29

Вуаля! Теперь заказчик будет видеть сколько раз вы компилировали несчастную прогу пока добились результата. А еще он увидит во сколько времени несчастный программист
этого добился. Если надо сбросить номер билда, то просто сотрите файл versioninfo.h и он будет создан заново с номером билда 1. Или измените в файле versioninfo.h номер билда, и нумерация пойдет дальше с этого номера.

Описанное выше не есть руководство к действию, а скорее метод. Экспериментируйте, улучшайте, затачивайте под себя. К примеру, можно изменять номер версии как-то по другому, или добавить имя юзера, скомпилировавшего файл. В общем, много еще чего можно делать под нашу музыку (©Масяня). Удачи.

Набор инструментов платформы

Набор инструментов платформы состоит из компилятора C++ (cl.exe) и компоновщика (link.exe) вместе со стандартными библиотеками C/C++. Studio 2015, Visual Studio 2017 и Visual Studio 2019 совместимы на уровне двоичного кода. Об этом свидетельствует основной номер версии набора инструментов, который остался равным 14. Проекты, скомпилированные в Visual Studio 2019 или Visual Studio 2017 обратно совместимы на уровне ABI с проектами, скомпилированными в Visual Studio 2017 или Visual Studio 2015. Дополнительный номер версии обновляется на 1 для каждой версии с выпуска Visual Studio 2015:

• Visual Studio 2015: v140
• Visual Studio 2017: v141
• Visual Studio 2019: v142

Целевая платформа (только для проектов C++/CLI)

Создавая пользовательские наборы инструментов платформы, можно расширить поддержку целевой платформы. Дополнительные сведения см. в блоге по Visual C++ Нативное многоплатформенное нацеливание в C++ .

В обозревателе решений Visual Studio выберите проект. В строке меню откройте меню Проект и выберите Выгрузить проект. Это выгружает файл проекта (VCXPROJ) для вашего проекта.

Проект на языке C++ не может быть загружен, пока вы редактируете файл проекта в Visual Studio. Однако можно использовать другой редактор, например блокнот, чтобы изменить файл проекта, пока проект загружен в Visual Studio. Visual Studio определяет, что файл проекта был изменен и отображает запрос о необходимости перезагрузить проект.

В строке меню последовательно выберите Файл, Открыть, Файл. В диалоговом окне Открыть файл перейдите к папке проекта и откройте файл проекта (с расширением VCXPROJ).

Сохраните изменения и закройте редактор.

В разделе Обозреватель решений откройте контекстное меню своего проекта и выберите Перезагрузить проект.

Изменение набора инструментов платформы

В диалоговом окне выберите страницу свойств Свойства конфигурации > Общие.

На странице свойств щелкните Набор инструментов платформы и выберите необходимый набор инструментов из раскрывающегося списка. Например, если вы установили набор инструментов Visual Studio 2010, выберите Visual Studio 2010 (версия 100) для использования в проекте.

В Интернетах написано немало статей об инкрементировании версий своих приложений и каждый использует свой метод. У кого-то ревизии используются в качестве «билдов», у кого-то это количество секунд текущих суток (например, Microsoft), у кого-то что-то другое.

В моем проекте используются 4 определяющие версии.

Например, 1.2.34.56, где:
1 — Major version: Критические изменения проекта (введен новый функционал, в корне переработан существующий и пр.). Устанавливается вручную;
2 — Minor version: Изменение функциональных частей приложения, значительное улучшение кода и пр. Устанавливается вручную;
24 — Build: номер релиза, попадающего в общество. Назначается автоматически;
56 — Revision: номер ревизии, полученный с GIT. Назначается автоматически.

Я не буду рассматривать кто какими методами пользуется, поэтому напишу как достиг данного результата.

Шаг 1. Подготовка

Сперва нам нужно зайти в настройки проекта (Project -> MyProject Properties). Здесь, во вкладке Application, идем в Assembly Information и проверяем, чтобы все 4 поля параметра Assembly version были заполнены, причем, первые 2 цифры указываем соответствующие нашему релизу. В моем случае это версия "2.3", а остальные цифры ставим любые.

После внесения изменений нам нужно зайти в папку проекта и найти файл AssemblyInfo.cs, который обычно находится в папке Properties.
Открываем файл на редактирование и в самом низу ищем строки:

Удаляем закомментированную строку:

Сделать это необходимо по той причине, что при записи новой версии будет использоваться регулярное выражение, считывающее ключевые цифры версии (major, minor) из первого найденного совпадения.
Удалили, сохранили, закрыли файл. Более он нам не понадобится.

Шаг 2. «ChangeRevision»

Для удобства я скомпилировал консольное приложение, которое считывает значения major, minor и build из файла Properties\AssemblyInfo.cs, а также количество коммитов GIT.
Итак, код ChangeRevision.exe:

Скомпилированный файл кладем в директорию Solution.

Ниже подробнее распишу как работает данный код.

Шаг 3. Pre-Build Event

Так как мне необходимо изменить версию билда перед компиляцией, код вписывается в окно Pre-Build Event.

Где:
"$(SolutionDir)ChangeRevision.exe" — Указывается путь к solution с указанием запуска нашего скомпилированного файла, о котором написано выше.
$(ConfigurationName) — Тип конфигурации (Debug или Release).
Если при запуске файла ChangeRevision.exe был передан параметр Debug, то в версии проекта будет увеличено только значение ревизии, то есть, если было 2.3.0.0, то станет 2.3.0.х, где «х» — количество коммитов по проекту. Если передан параметр Release, то автоматически будет инкрементирован номер билда совместно с изменением ревизии по количеству коммитов. Например, было 2.3.0.0, станет 2.3.1.х, где «х» — количество коммитов по проекту.
"$(ProjectName)" — Имя проекта

UPD: Из кода программы был удален параметр, содержащий имя проекта, так как при компиляции проекта стартовой директорией запуска файла с параметром являлась $(ProjectDir)\bin\Debug / Release, вследствие чего возникала ошибка. Таким образом, передача наименования проекта отпала как таковая, так как в работе приложения ChangeRevision.exe используется переход на верхний уровень относительно директории запуска, то есть, указав путь "..\..\Properties\AssemblyInfo.cs" программа переходит в директорию проекта и от туда в «Properties», где и находит необходимый файл AssemblyInfo.cs"

UPD 2: Как показала практика, если в Solution находится несколько проектов и выбрать на компиляцию не тот, что по-умолчанию, то стартовой директорией будет, почему-то, директория проекта по-умолчанию. В общем, код еще немного доработан и изменен вверху, а именно, вновь введен параметр передачи наименования проекта, который в ChangeRevision.exe перехватывается вторым по счету. Таким образом, путь к к AssemblyInfo.cs был изменен на:

То есть, при компиляции любого проекта стартовая директория смещается на 3 ступени вверх (директория solution), а затем перемещается в папку проекта, указанную в параметре запуска файла, переходя к искомому файлу.

Количество коммитов можно узнать путем передачи параметра

Это в том случае, если нужно получить количество коммитов из ветки MASTER.

По завершению работы приложения будет изменен файл Properties\AssemblyInfo.cs, переданного в первом параметре, проекта, после чего среда разработки скомпилирует файл самого проекта с указанной в файле версией.
P.S.: При изменении версии AssemblyVersion также изменяется и значение в параметре AssemblyFileVersion, а в некоторых случаях и AssemblyFileVersionAttribute.

Таким образом я достиг полуавтоматического инкрементирования версии своего приложения.

P.S.: Конечно, работая в команде или выполняя регулярное объединение версий, данный вариант не подходит ВООБЩЕ не подходит, так как количество коммитов может внезапно сократиться, таким образом получем «новую» «старую» версию ПО. А для одного человека, без использования объединения версий, данный вариант более чем достаточен.

Спасибо за внимание!

UPD: Внес изменения в код на Шаге 2. Поправил описание
UPD 2: Все на том же шаге вновь изменения в коде.

Шаг 1. Запуск Portability Analyzer

Запускаем Portability Analyzer и указываем расположение исходного кода проекта:

Portability Analyzer

После этого откроется файл Excel с отчётом по проверке. У меня этот файл выглядел следующим образом:

Лист Portability Summary

Шаг 2. Миграция .csproj в SDK-стиле

А вот так будет выглядеть контекстное меню проекта без пункта:

Откроется XML-файл примерно такого содержания:

Вместо только что удаленного текста вставьте следующий код необходимый для консольного приложения(здесь небольшое расхождение с первоисточником):

У меня такой блок оказался всего один, поэтом итоговый файл *.cproj стал выглядеть вот так:

Помогло удаление файла AssemblyInfo.cs

После этого проект запустился, работоспособность не нарушилась. Однако встретилась другая проблема.

Теперь необходимо добавить в проект пространство имен:

И можно пользоваться классами Point и Rect :

Читайте также:

  
• Ожидание нажатия клавиши visual studio
  
• Как сделать точечный рисунок в paint
  
• 1с 7 как перенести дату начало дня
  
• Excel закрепить строку vba excel
  
• Adobe animate почему не рисует