Автоинкремент билда при сборке из командной строки.

← →
Дмитрий Белькевич © (2015-03-27 16:12) [0]

Нунжо, что бы версия сборки поднималась при сборке из командной строки. В опциях автоинкремент проектов настроен, само собой. Сейчас версия поднимается только средой.
Чем и как пробую.

Delphi 2010, сборка с помощью компилятора (правда - через эврикалог, но, думаю, всё равно). Сборка с помощью msbuild. win32.
Delphi XE6. Сборка с помощью msbuild. win32 и win64.

Нигде версия не увеличивается, хотя нужно. Может есть какой-то секретный, или не очень, ключ у msbuild"а и/или у dcc?

Не хочется в dproj и в ресурсы лезть руками.

Спасибо всем ответившим.

← →
DVM © (2015-03-27 16:30) [1]

Версия хранится в ресурсе, msbuild имхо не умеет. Я не находил подходящих тасков для него. Все какие то костыли делают. Да и по-разному всем надо.

Я всегда делаю внешний ресурсный файл, содержащий версию, в котором инкремент версии делается небольшой утилитой.

← →
DVM © (2015-03-27 16:40) [2]

> Не хочется в dproj и в ресурсы лезть руками.

В любом случае туда кому то лезть. Таску от MSBuild или твоей утилите.
Вот можно свой таск сделать: http://tech.pro/tutorial/934/creating-msbuild-tasks-in-csharp
который будет инкременировать версию.

Я вот этим пользуюсь: http://cc.embarcadero.com/Item/15118

← →
DVM © (2015-03-27 16:51) [3]

Вот, кстати, все же есть готовый таск:
https://github.com/loresoft/msbuildtasks/blob/master/Source/MSBuild.Community.Tasks/Version.cs

← →
Дмитрий Белькевич © (2015-03-27 17:57) [4]

>В любом случае туда кому то лезть

Я понимаю, но лучше бы это компилятор или билдер делал. Посмотрю ссылки, спасибо!

← →
Rouse_ © (2015-03-27 19:29) [5]

Вообще эта опция помогает только тем кто не использует системы контроля версий.
Если же ты ее используешь (SVN/GIT/HG), то категорически советую номером билда ставить номер заливки в репозиторий. Оно так в дальнейшем проще будет для детекта различных ошибок.
К примеру софт упал по такому адресу. Не вопрос, смотрим билд софта, откатываемся на ревизию и воспроизводим ситуацию.

Во всех остальных случаях билд излишен.

← →
Rouse_ © (2015-03-27 19:32) [6]

> Может есть какой-то секретный, или не очень, ключ у msbuild"а
> и/или у dcc?

Есть, как "Джек полбайта" придет на форум (извиняюсь - "Капитан Джек полбайта") он тебе сможет рассказать как ручками через MsBuild все это выставить.

← →
Кто б сомневался © (2015-03-28 22:48) [7]

> Автоинкремент билда при сборке из командной строки.

Нафиг он вообще нужен? Знать количество билдов - что это дает программисту?
Ничего.
Нафига заморачиваться из за такой ерунды?

← →
Кто б сомневался © (2015-03-28 22:56) [8]

> К примеру софт упал по такому адресу. Не вопрос, смотрим
> билд софта, откатываемся на ревизию и воспроизводим ситуацию.
>

И что потом? Править этот билд? А с самым последним билдом что делать? Сравнивать код с последним билдом? Тогда проще проверить с последним билдом сразу.

Одни вопросы у меня сегодня :)

← →
jack128 © (2015-03-28 23:57) [9]

> Есть, как "Джек полбайта" придет на форум (извиняюсь - "Капитан
> Джек полбайта") он тебе сможет рассказать как ручками через
> MsBuild все это выставить.

не-а, у нас НЕ через мсбилд сделано, как раз как DVM говорил, у нас есть _отдельный_ rec файл, который подключен к проэкту (version.rec). Перед каждым билдом запускается ресурс компилер(ms"овский) в который дефайнами передаются номера версии, он и билдит соответствующий rc файл. а после уже запускается msbuild, который и билдит дельфийский проэкт

← →
Германн © (2015-03-29 00:57) [10]

> Кто б сомневался © (28.03.15 22:56) [8]
> > К примеру софт упал по такому адресу. Не вопрос, смотрим
> > билд софта, откатываемся на ревизию и воспроизводим ситуацию.
> И что потом? Править этот билд?

Нет. Воспроизведя ситуацию с падением софта в старой ревизии, находим место падения в коде программы и разбираемся почему упало. А затем исправляем последний билд. Вроде как всё очевидно. Какие вопросы?

← →
Кто б сомневался © (2015-03-29 02:00) [11]

> Германн © (29.03.15 00:57) [10]

Ну так баг и в последнем билде будет. Или баг будет прогрессирующий и в последнем билде нужны будут другие исправления.
Почему бы не проверять сразу последний билд?

← →
Кто б сомневался © (2015-03-29 02:00) [12]

← →
Кто б сомневался © (2015-03-29 02:11) [13]

> Почему бы не проверять сразу последний билд?

Заодно можно найти и потенциальные баги, с новым кодом.

← →
Германн © (2015-03-29 02:25) [14]

> Кто б сомневался © (29.03.15 02:00) [11]
>
>
> > Германн © (29.03.15 00:57) [10]
>
>
> Ну так баг и в последнем билде будет.

Чукча не читатель?
> К примеру софт упал по такому адресу

Какой смысл искать этот адрес в другой версии ПО?

← →
Дмитрий Белькевич © (2015-03-29 11:01) [15]

>Нафига заморачиваться из за такой ерунды?

Мне номер не особенно нужен. Релизеры сборок очень просят. Хотя иногда удобно и самому, бывает, посмотреть какая именно сборка свалилась, но я билды по датам отличаю. У релизеров так не получается. В результате - у меня проходит 2-3-5 билдов, делфи меняет билд только в ide (она ведь как-то это делает во время биолда? сама по ресурсам/dproj"у правит?), у релизеров, тестеров и саппорта - каша, потому как несколько разных билдов с одним номером.

Как-то разбираемся, конечно, но уже хочется нормально сделать.

Причем, идеально - средствами msbuild"а/dcc, не то, что бы писать лень, но просто среды, бывает, меняются, не хочется постоянно переписывать, тем более что проект - не один.

> > К примеру софт упал по такому адресу
>
> Какой смысл искать этот адрес в другой версии ПО?

Дык а что смущает то? У вас же кроме адреса, который скорее всего просто поменяется после запуска, есть и другие данные - целый стек.

Смысл такой, что править придется последнюю сборку. А значит и тестить эту ситуацию и искать баг нужно именно на ней, параллельно выискивая возможные баги с новым кодом.

> параллельно выискивая возможные баги с новым кодом.

С кодом, который был добавлен между пред. билдом и последним и который возможно будет влиять на развитие ошибки.

Т.е. вы загрузили в отладчик код предыдущего билда, нашли причину, поняли что делать.
Потом загрузили последний билд, и сделали правку - такой алгоритм работы? Или я не так все понял?

> Т.е. вы загрузили в отладчик код предыдущего билда, нашли
> причину, поняли что делать.
> Потом загрузили последний билд, и сделали правку - такой
> алгоритм работы?

В общих чертах такой.

> Кто б сомневался © (29.03.15 02:00) [12]
> Почему бы не проверять сразу последний билд?

Ну проверили. Ну не упало. и что это означает? Что ошибки нет? Что ошибка осталась - но изменились условия её воспроизведения? Что ошибка не проявляется на наших тестовых данных? Или всё же эта ошибка уже исправлена? Или нет?

А если упало - это та самая ошибка? или совсем другая и её исправлением мы не исправим ошибку, возникающую у клиента?

Потому и надо разобраться в причинах реально возникшей ошибки, часто именно на той версии, на какой она возникла - и тога уже решать что с ей делать, если ошибка еще не исправлена, либо быть уверенным, что именно эта ошибка исправлена.

Автоинкремент билда при сборке из командной строки. Найти похожие ветки