У меня есть некоторое встроенное программное обеспечение C, хранящееся в TFS, а также соответствующее определение сборки TFS, которое успешно проверяет код и собирает его с использованием соответствующих компиляторов. Так что для ясности, хотя это TFS, я не создаю приложение .NET.

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

Собранный исходный код имеет заголовочный файл, в котором есть #defines для трех переменных: Major Version, Minor Version и Build Number. Этот заголовочный файл затем используется для запирания номера версии в программное обеспечение во время компиляции. Концепция заключается в том, что разработчик несет ответственность за обновление только старшего и младшего номеров версий в рамках разработки. Номер сборки всегда остается равным 0 в источнике и не должен изменяться разработчиком.

В случае, если разработчик производит сборку локально на своем компьютере, основная и вспомогательная версия будут установлены так, как определено в коде, но номер сборки останется равным 0, что указывает на неконтролируемую сборку. Однако для официальных сборок на сервере я бы хотел, чтобы TFS автоматически увеличивал номер сборки, чтобы последующие сборки с той же самой указанной основной и вспомогательной версией приводили к увеличению номера сборки для обеспечения общего уникального дескриптора версии.

После небольшого прочтения я определенно вижу, как эта работа определяет формат чисел сборки TFS следующим образом: $ MajorVersion. $ MinorVersion. $ (Rev: .rr), где MajorVersion и MinorVersion - это переменные, которые я определяю как часть процесса сборки.

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

Теперь, наконец, к проблеме. Кажется, мой подход ошибочен. Как только я ставлю в очередь сборку, номер сборки TFS оценивается немедленно, по-видимому, чтобы дать имя сборке в очереди. На этом этапе я не смог запустить свой скрипт для извлечения основной и вспомогательной версий и, следовательно, также получить неверный номер ревизии. Таким образом, основываясь на моем ранее упомянутом выше формате номеров сборки, я получаю номер сборки и имя результата, например, "..01" или "0.0.01", в зависимости от того, инициализирую ли я основные и второстепенные переменные в определении сборки.

Так может ли кто-нибудь увидеть способ, которым я могу отложить оценку номера сборки TFS до тех пор, пока у меня не будет возможности прочитать мои основные и второстепенные версии из источника через этап сборки Powershell? Если я могу это сделать, ревизия должна быть правильно рассчитана на основе реальных основных и вспомогательных версий. Затем я воспользуюсь другим сценарием, чтобы установить только номер сборки #define в моем заголовочном файле, чтобы соответствовать ревизии в номере сборки TFS. Кроме того, поскольку кажется, что TFS использует номер сборки в качестве имени сборки в очереди, я не уверен, как с этим справиться, так как не знаю окончательный номер сборки TFS в тот момент, когда сборка ставится в очередь. Можно ли изменить имя в процессе сборки?

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