15

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
variables

This is my workflow step
workflow

And this is what the build prints
build output

jessehouwing
  • 106,458
  • 22
  • 256
  • 341
Suchiman
  • 1,636
  • 2
  • 20
  • 30

3 Answers3

10

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.

jessehouwing
  • 106,458
  • 22
  • 256
  • 341
AHMED EL-HAROUNY
  • 836
  • 6
  • 17
4

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: cmd prompt expansion of variables 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.

CJBS
  • 15,147
  • 6
  • 86
  • 135
PatrickLu-MSFT
  • 49,478
  • 5
  • 35
  • 62
  • Hi. sorry if i wasn't clear. I've added the requested Images to my question. The problem is that it doesn't seem to work in the same build definition where this variable is exported as environment variable during the build step. The title was supposed to refer to use build variables from the same build in the definition of another variable. – Suchiman Dec 03 '15 at 09:55
  • Come to same result in my enviroment. Not sure if this is supported in CMD. Will double check it tomorrow and update my answer. – PatrickLu-MSFT Dec 03 '15 at 13:07
  • hi, it's almost tomorrow :) got any news to share? – Suchiman Dec 10 '15 at 08:35
  • to that (not sure why), it's explained here: https://msdn.microsoft.com/en-us/Library/vs/alm/Build/scripts/variables (see the Paragraph above Secret Variables). Indeed i see how this works but i still think it's a workaround. I would have to declare `Some` as `%BUILD_STAGINGDIRECTORY%\Some` which wouldn't allow to use this variable outside of the script context. The Build Agent should try to expand all `$(...)` variables Prior to exporting them to the Environment i think. – Suchiman Dec 10 '15 at 11:06
  • @Suchiman It seems not. At least test results meet it. The Build Agent will only expand $(Some) as Some= $XX and $XX will be expand in the environment which you use it. Cause $ is not support in cmd, so cmd consider $XX is just $XX and print it out . And MsBuild is support $. That's why you can get the right result. I was wondering if the reason is Vnext Build agent is running step by step , before the step 'execute cmd' the agent will not to use the $XX , and certainly not expand it. – PatrickLu-MSFT Dec 10 '15 at 12:10
  • thanks so far. My Point though is that this not only works in msbuild but also in build agent text boxes. E.g.: if you create a batch script build step, and pass $(Some) as Argument, it will receive the correct result `"C:\a\1\a\Some"` instead of `$(Build.StagingDirectory)\Some`. Making this also work when exporting the Environment variables seems just intuitive. – Suchiman Dec 10 '15 at 13:13
  • Since i got lost while trying to find TFS / VSTS on connect, i send a frown with a suggestion to make this work. – Suchiman Dec 10 '15 at 13:19
2

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.

knipp
  • 196
  • 4
  • 12