TFS 2013 environment variables always empty - tfs

I've defined custom arguments in my xaml build script and provided values:
Then In my build I get the following instead of actual TF_BUILD_BUILDDIRECTORY. This is the string that writes: "dotCover Report..."
String.Format("dotCover Report Path: {0}\{1}", DotCoverReportPath, DotCoverReportFileName)
It's not translating to actual BUILDDIRECTORY path. What am I doing wrong? I've hit "refresh" several times and still no go. I wanted to get "C:\temp..." etc

Possible duplicate with this case TFS How to GetEnvironmentVariable value. You can't use $TF_BUILD_BUILDDIRECTORY in a custom build process.
Please refer more detailed info about how to use it from this blog Using Environment Variables in Visual Studio 2013 and TFS 2013

Related

Is there a way to link variable group in TFS 2017 Build definition?

I know i can link my variable group stored in Library into a Release Definition, but my build definition doesn't have an option to link the variable group. I see it is available in TFS 2018. We are not upgrading our Prod instance from TFS 2017 anytime sooner. Is there any out of box method/way that i can link and read the library group?
Is there any out of box method/way that i can link and read the library group?
Sorry for any inconvenience.
I am afraid there is no such out-of-the-box method to link variable group in TFS 2017 Build definition.
There were many user voices about it before, and this request is resolved at Team Foundation Server 2018, MS team has no plans to apply it to TFS2017:
Variable group support
Variable groups have been available to use in release definitions, and now they are ready to be used in build
definitions, too. Learn more about creating a variable group. This has
been developed and prioritized based on related suggestions for
project-level build/release variables and variable groups in build
definitions.
And, AFAIK, there is currently no better workaround to solve this issue for TFS 2017.
So, we have to repeatedly define variables for each build pipeline before updating our TFS to 2018.
Hope this helps.
I was able to get TFS 2017 variable groups in JSON format. I'm now loading the JSON and instantiate the library groups.
http://tfsinstance/collectionname/teamproject/_apis/distributedtask/variablegroups/
Idea is to encapsulate this as a custom task and fetch required variable groups in the build definitions.
Variable group,in tfs 2017, are available only in release :(

What is the VSTS Link Settings feature?

I am talking about this:
The documentation I found is here - https://learn.microsoft.com/en-us/azure/devops/pipelines/process/parameters?view=vsts, but I must be plain stupid, because I do not understand one bit of it.
I do not know why it is so hard, but I cannot find anything meaningful on the web.
We have an on-premises TFS.
Let's say you have a build configuration ("Release") that you want to use in conjunction with multiple instances of the Visual Studio Build task.
You could add a variable called BuildConfiguration and then put the value $(BuildConfiguration) in the "Configuration" box for all of your Visual Studio Build tasks.
Or, you could enter the actual value, "Release", and then link the Configuration field in Visual Studio build to a pipeline parameter. Then you can manage the value from the "Pipeline" view.

How to access TFS 2013's $(Rev:.r) property from within a Build Template?

The default build template for TFS has a format of $(BuildDefinitionName)_$(Date:yyyyMMdd)$(Rev:.r)
This translates to something like BuildName_20141111.1 for the first build of the day, BuildName_20141111.2 for the second and so on that.
That's all well and good but what I'd like to do is pull out that .r and insert it into the assembly before it's compiled by the build server.
I've already edited the build template to update the various AssemblyInfo.cs files and such and that's working fine. Right now we are toying with the idea of Major.Minor.yyDDD (Day of year).r but the catch is that very last part - how do we get $(Rev:.r) from within a build template?
I've tried looking through the various environmental variables and I can pull out the entire Build definition string (i.e. BuildName_20141111.1) but really all I want is that .1 (or more specifically "1"). Is there a way to do this programmatically? Is there an environment variable I've missed? Or is there a way that I can actually access things like $(Rev:.r) directly?
I am relatively new to TFS but this is the last hurdle before I can move a lot of projects to it.
You effectively need to parse this off yourself from the BuildName parameter. If you are using TFS 2013 you can do it in PowerShell. Prior versions need a customized build template.
There are prebuilt solutions to this. Best is the TfsVersion activity or the VersionAssemblies.ps1 that is provided as part of the TFS Community Build Tools.

How can I refer to the workspace path from msbuild in team build?

I've got a boatload of legacy project files that use a $(ProjectRoot) variable in include paths to refer to the root of the source tree. We define the variable in our visual studio environment so desktop builds can find their way to the tfs workspace in use.
I would like to define this variable in the Team Build environment via an MSBuild command line option in my tfs build definition, but I can't seem to find a way that works. I found an answer (List of msbuild properties TFS passes to a build script) with a list of variables and SolutionRoot looked promising.
When I put /p:ProjectRoot=$(SolutionRoot) in the MSBuild Arguments for my build definition, ProjectRoot ends up empty. I want it to expand to something like D:\Builds\18\TfsProject\BuildDef\src\
Is there a way to define my variable with the value of the root of the workspace sources in Team Build?
Note: I tried to figure this out in TFS2010 and finally gave up and modified the BuildProcessTemplate to define the variable using the SourcesDirectory variable that's available inside that context. I thought I'd take another run at it in the hopes of using the new template in TFS2013 without modification, but I'm still stumped.
UPDATE: Turns out the syntax I had in my MSBuild Arguments would work if the variable I'm dereferencing were actually being passed to msbuild. The list from the other post I reference seems to no longer be valid. Looking at the detailed Team Build logs, it looks like the only variables being passed in to msbuild in Team Build are OutDir, BuildId, BuildLabel, BuildTimestamp, BuildSourceVersion, and BuildDefinition. None of those gives me the info my current msbuild scripts need at build time so I'm stuck with either reworking all our project files or continuing with the BuildProcessTemplate modifications I've been using. Unless someone comes along with a better answer here.
You should be able to specify /p:ProjectRoot=$(TF_BUILD_SOURCESDIRECTORY) in the MSBuild Arguments of your build definition when using TFS2013.
See the Team Foundation Build environment variables documentation for more information.
Set the property using the other property. Use condition to only set it if its empty.
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="xxxxxxxxxxxx">
<PropertyGroup>
<ProjectRoot Condition="$(ProjectRoot)==''"/>$(SolutionRoot)</ProjectRoot>
</PropertyGroup>

Retrieving path to solution(s)?

We are currently setting up Team Build 2010 for our company, and I am trying to use workflow activities to retrieve the exact local path to the current solution being built. I haven't found a way to get this value, does anybody know how (without writing a custom activity)?
Either one of server or local path would suffice (i.e $/TeamProject/Branch/OurProject or C:\TeamBuild\src\path\to\branch\OurProject) since we can use the conversion activities on the server item.
The reason we need this path is for updating version info files, and that needs to be done for only the current solution being built, and the files have the same names (AssemblyInfo.cs, for example).
In this similar question, the solution is to define a parameter, but since this information is particular to the solution being built and not some external path, we were hoping that this info would retrievable.
You can retrieve this particular info without adding anything. If you navigate within your Build Process Template to the position where MSBuild breaks out, you will see that the solution that shall be build is set as a string named localProject. This will contain the local path where TFS has downloaded your SLN, something like C:\TeamBuild\src\path\to\branch\OurProject\OurProject.sln.Open the XAML and navigate to:
Run On Agent
Try Compile, Test, and Associate Changesets and Work Items
Compile, Test, and Associate Changesets and Work Items
Try Compile and Test
Compile and Test
For Each Configuration in BuildSettings.PlatformConfigurations
Compile and Test for Configuration
If BuildSettings.HasProjectsToBuild
For Each Project in BuildSettings.ProjectsToBuild
Try to Compile the Project
Compile the Project
Run MSBuild for Project
if you select Run MSBuild for Project & hit F4 you see it.
In order to retrieve what you are after you can define another string-variable solutionPath in your Build Process Template & insert under the Run MSBuild for Project a new Assign activity withTo : solutionPath andValue : Path.GetDirectoryName(localProject)
Have you looked at the TFS Community Build Extensions, they give you a assembly versioning out of the box?
You can use the variable called SourcesDirectory to get the current Source Directory on the Build Server. You can also use an ConvertWorkspaceItem activity to convert between server and local paths.
There's also a blog post that cover's all of this here.

Resources