TFS 2015 Can build variables access other build variables?

Question

When I define a custom variable in the new TFS 2015 team build as follows:
Name: SomeOutput
Value: $(System.DefaultWorkingDirectory)\Some

...it doesn't seems to expand $(System.DefaultWorkingDirectory).
Is there a way around this?

EDIT:
At least it seems it's not expanded everywhere.

For example, in MSBuild-Arguments, /p:OUTPUT="$(SomeOutput)" is expanded to /p:OUTPUT="C:\TfsData\BuildAgents\_work\3\s\Some" but when i add a cmd line build task with tool set to cmd and parameter set to /k set, it prints
SOMEOUTPUT=$(System.DefaultWorkingDirectory)\Some

EDIT 2: Here are my variables

This is my workflow step

And this is what the build prints

Answer 1

You can use the VSTS Variable Tasks extension from the Visual Studio Marketplace.

When you define a variable in the Variables screen and use other variables as value, they won't be expanded (as you may have expected). Instead the literal text is passed to the tasks in the workflow. Without this little task the following configuration won't work:

Variable              Value
Build.DropLocation    \\share\drops\$(Build.DefinitionName)\$(Build.BuildNumber)

By adding the Expand variable(s) task to the top of your workflow, it will take care of the expansion, so any task below it will receive the value you're after.

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

PS: The new agent (version 2.x) auto-expands variables now.

Answer 2

It can be achieved.

You may need use % % instead of $ to call the variables in cmd to print the result. It is also necessary to add call in the front of the command. Here is a simple example:

Note: System.DefaultWorkingDirectory is not available in cmd (not sure why); you need use System_DefaultWorkingDirectory instead. Details can be viewed in the logs.

Answer 3

I had the same problem - wanted to piece together a path made up of several built-in variables and pass it to a PS script.

Workaround: I ended up combining the variables in the actual script through the corresponding generated environment variables (for example $env:BUILD_SOURCESDIRECTORY).

Not what I had in mind originally, but it works at least. Drawback - if I need to change the path, I always have to change the PS script instead of a build variable.