TFS 2015 Можно ли создавать переменные для доступа к другим переменным сборки?

Когда я определяю пользовательскую переменную в новой команде TFS 2015, выполните следующие действия:
Имя: SomeOutput
Значение: $(System.DefaultWorkingDirectory)\Some

... он не расширяет $(System.DefaultWorkingDirectory).
Есть ли способ обойти это?

РЕДАКТИРОВАТЬ:
По крайней мере, кажется, он не повсюду расширялся.

Например, в MSBuild-Arguments /p:OUTPUT="$(SomeOutput)" расширяется до /p:OUTPUT="C:\TfsData\BuildAgents\_work\3\s\Some" но когда я добавляю строку cmd построить задачу с помощью инструмента, установленного в cmd и установить параметр /k set, он печатает
SOMEOUTPUT=$(System.DefaultWorkingDirectory)\Some

EDIT 2: Вот мои переменные

Это мой рабочий шаг

И это то, что печатает печать

Ответы

Ответ 1

Вы можете использовать расширение VSTS Variable Tasks из Visual Studio Marketplace.

Когда вы определяете переменную на экране Variables и используете другие переменные в качестве значения, они не будут расширяться (как вы могли ожидать). Вместо этого буквальный текст передается задачам рабочего процесса. Без этой небольшой задачи следующая конфигурация не будет работать:
Variable              Value
Build.DropLocation    \\share\drops\$(Build.DefinitionName)\$(Build.BuildNumber)
Добавив задачу Expand variable (s) в начало рабочего процесса, она позаботится о расширении, поэтому любая задача под ней получит значение, которое вам нужно.

^{https://github.com/jessehouwing/vsts-variable-tasks/wiki/Expand-Variable}

PS: Новый агент (версия 2.x) автоматически расширяет переменные.

Ответ 2

Это может быть достигнуто.

Вам может потребоваться использовать % % вместо $ чтобы вызвать переменные в cmd для печати результата. Также необходимо добавить call в начале команды. Вот простой пример:

Примечание: System.DefaultWorkingDirectory недоступен в cmd (не уверен, почему); вам нужно вместо этого использовать System_DefaultWorkingDirectory. Детали можно просмотреть в журналах.

Ответ 3

У меня была такая же проблема - хотелось собрать кусок пути, состоящего из нескольких встроенных переменных, и передать его сценарию PS.

Обход: Я в конечном итоге объединение переменных в фактическом сценарии через соответствующее сгенерированный переменное окружение (например $env:BUILD_SOURCESDIRECTORY).

Не то, что я имел в виду изначально, но он работает как минимум. Недостаток - если мне нужно изменить путь, мне всегда нужно изменить сценарий PS вместо переменной сборки.