Как очистить «измененное» состояние в TFS для расписания сборки или изменить время набора изменений?

Question

У нас есть наши проекты, настроенные с настройкой скрипта MSBuild, чтобы изменить свойство ApplicationVersion в проекте и скопировать его в файл AssemblyInfo.cs при сборке проекта. Проблема в том, что у нас есть TFS, настроенная для работы по ночному графику, с «Build, даже если ничего не изменилось со времени предыдущей сборки» не отмечен. Но поскольку сам TFS выпускает обновление этой версии, он будет восстанавливать и увеличивать каждую ночь. Так что это своего рода бесконечный цикл нашего собственного дизайна, но он пытается понять, как выйти из него.

Если обнаружение «изменено с предыдущей сборки» основано на временной отметке истории, в идеале было бы неплохо, если при обновлении версии и совершении TFS она делает это с отметкой времени, предшествующей времени сборки. Возможно ли это?

Если обнаружение «изменено с предыдущей сборки» основано на некотором логическом/битовом флаге, есть ли способ его сбросить?

Использование TFS 2012.

Answer 1

Я предполагаю, что вы проверяете в новой версии AssemblyInfo.cs когда он был обновлен, и именно поэтому TFS является очереди новой сборки. Вы пробовали добавить комментарий к checkin из ***NO_CI*** Это, безусловно, подавит сборку CI, но я не уверен на 100%, если он будет работать в вашем сценарии.

Другой вариант - генерировать номер версии с помощью алгоритма, а затем просто увеличивать счетчик и проверять его обратно на Version Control. Это обходит вопрос о новых сборках, которые инициированы

т.е. если номер версии выглядит как 1.2.3.4

Где 1 Major (модифицированный человек не процесс сборки)

2 является несовершеннолетним (также измененный человеком)

последние 2 цифры затем обновляются автоматическим процессом.

Вы можете использовать количество дней с января 2000 года для цифры 3 (произвольное число, но что-то, что будет меняться ежедневно) и либо последний номер набора изменений в контроле версий, либо общее количество сборок, выполняемых TFS для цифры 4.

Это выполнит 2 требования, номера версий уникальны для данной сборки сборки, они всегда идут вверх.

Answer 2

Я бы предположил, что вы не проверяете номер новой версии в TFS. Нет никакой ценности в наличии номера версии.

Обычно я устанавливаю проверенные в информационных номерах сборки все нули. (0.0.0.0) и никогда не обновлять их, кроме локально для сборки.

Это дает вам возможность всегда идентифицировать локально созданные библиотеки DLL.