Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2015.11.29;
Скачать: CL | DM;

Вниз

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

 
Дмитрий Белькевич ©   (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]


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


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


 
Кто б сомневался ©   (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"у правит?), у релизеров, тестеров и саппорта - каша, потому как несколько разных билдов с одним номером.


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

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


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

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


 
Кто б сомневался ©   (2015-03-29 13:30) [18]


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


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

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


 
Кто б сомневался ©   (2015-03-29 13:44) [19]


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


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

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


 
Германн ©   (2015-03-29 20:05) [20]


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

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


 
KSergey ©   (2015-03-30 12:16) [21]

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

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

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

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



Страницы: 1 вся ветка

Текущий архив: 2015.11.29;
Скачать: CL | DM;

Наверх




Память: 0.53 MB
Время: 0.008 c
15-1427439353
KSergey
2015-03-27 09:55
2015.11.29
Неожиданный синтаксис Си


15-1426787074
Rouse_
2015-03-19 20:44
2015.11.29
Просто опрос, мне для статистики для статьи


15-1428244463
Pavelnk
2015-04-05 17:34
2015.11.29
Учебник Symphony


15-1428130841
brother
2015-04-04 10:00
2015.11.29
получить иконки из imageres.dll


15-1427583211
Германн
2015-03-29 01:53
2015.11.29
Ещё раз об "IncDay"