Available modules for TFS 2015 build tasks

Mario Majcica November 14, 2015 6 Comments

It is not yet well documented but if you are writing a custom build task for your TFS 2015 build system, you get at your disposition some of the modules that are made available by your VsoWorker.
As I couldn’t find a list of available modules and cmdlets they expose, I decided to dig into them and see what is there. I also wanted to check if with the Update 1 (and the new version of the build agent) there will be more of them.
I wrote a handy task that will list all of the available cmdlets for all of the modules shipped by the agent worker. Following are my results.

With TFS 2015 the agent version delivered is 1.83.2. It offers the following modules:

• Microsoft.TeamFoundation.DistributedTask.Task.Common.dll
• Microsoft.TeamFoundation.DistributedTask.Task.Deployment.Azure.psm1
• Microsoft.TeamFoundation.DistributedTask.Task.Deployment.Chef.psm1
• Microsoft.TeamFoundation.DistributedTask.Task.DevTestLabs.dll
• Microsoft.TeamFoundation.DistributedTask.Task.DTA.dll
• Microsoft.TeamFoundation.DistributedTask.Task.Internal.dll
• Microsoft.TeamFoundation.DistributedTask.Task.TestResults.dll

I will now list of all importable functions and cmdlets in those modules.

• Microsoft.TeamFoundation.DistributedTask.Task.Common.dll
• Add-TaskIssue
• Complete-Task
• Find-Files
• Get-LocalizedString
• Set-TaskProgress
• Set-TaskVariable
• Write-TaskDetail
• Microsoft.TeamFoundation.DistributedTask.Task.Deployment.Azure.psm1
• Get-AzureCmdletsVersion
• Get-AzureModuleLocation
• Get-AzureVersionComparison
• Get-RequiresEnvironmentParameter
• Get-SelectNotRequiringDefault
• Import-AzurePowerShellModule
• Initialize-AzurePowerShellSupport
• Initialize-AzureSubscription
• Microsoft.TeamFoundation.DistributedTask.Task.Deployment.Chef.psm1
• Get-DetailedRunHistory
• Get-PathToNewtonsoftBinary
• Get-ShouldWaitForNodeRuns
• Get-TemporaryDirectoryForChef
• Initialize-ChefRepo
• Invoke-GenericMethod
• Invoke-Knife
• Invoke-WithRetry
• Wait-ForChefNodeRunsToComplete
• Microsoft.TeamFoundation.DistributedTask.Task.DevTestLabs.dll
• Complete-EnvironmentOperation
• Complete-EnvironmentResourceOperation
• Complete-ResourceOperation
• Copy-FilesToAzureBlob
• Copy-FilesToRemote
• Copy-FilesToTargetMachine
• Copy-ToAzureMachines
• Get-Environment
• Get-EnvironmentProperty
• Get-EnvironmentResources
• Get-ProviderData
• Invoke-BlockEnvironment
• Invoke-EnvironmentOperation
• Invoke-PsOnRemote
• Invoke-ResourceOperation
• Invoke-UnblockEnvironment
• New-OperationLog
• Register-Environment
• Register-EnvironmentDefinition
• Register-Provider
• Register-ProviderData
• Remove-Environment
• Remove-EnvironmentResources
• Microsoft.TeamFoundation.DistributedTask.Task.DTA.dll
• Invoke-DeployTestAgent
• Invoke-RunDistributedTests
• Microsoft.TeamFoundation.DistributedTask.Task.Internal.dll
• Add-BuildArtifactLink
• Add-BuildAttachment
• Convert-String
• Copy-BuildArtifact
• Get-JavaDevelopmentKitPath
• Get-MSBuildLocation
• Get-ServiceEndpoint
• Get-TaskVariable
• Get-ToolPath
• Get-VisualStudioPath
• Get-VssConnection
• Get-X509Certificate
• Invoke-Ant
• Invoke-BatchScript
• Invoke-IndexSources
• Invoke-Maven
• Invoke-MSBuild
• Invoke-PublishSymbols
• Invoke-Tool
• Invoke-VSTest
• Publish-BuildArtifact
• Register-XamarinLicense
• Unregister-XamarinLicense
• Microsoft.TeamFoundation.DistributedTask.Task.TestResults.dll
• Invoke-ResultPublisher
• Publish-TestResults

The Update 1 RC1 for TFS increased the agent to the version 1.89.0 and the RC2 incremented it to version 1.89.1. As of the time I’m writing this blog post, the RC2 is the latest version available, I’ll list and show the differences with a plain TFS 2015 build agent.

Three new modules are added:

• Microsoft.TeamFoundation.DistributedTask.Task.CodeCoverage
• Microsoft.TeamFoundation.DistributedTask.Task.Deployment.Internal
• Microsoft.TeamFoundation.DistributedTask.Task.Deployment.RemoteDeployment

Following the list of all importable functions and cmdlets in the those modules.

• Microsoft.TeamFoundation.DistributedTask.Task.CodeCoverage
• Enable-CodeCoverage
• Publish-CodeCoverage
• Microsoft.TeamFoundation.DistributedTask.Task.Deployment.Internal
• Get-OperationLogs
• Get-ResourceCredentials
• Get-ResourceFQDNTagKey
• Get-ResourceHttpsTagKey
• Get-ResourceHttpTagKey
• Get-ResourceOperationLogs
• Get-SkipCACheckTagKey
• Get-SqlPackageCommandArguments
• Import-DevtestLabsCommomDll
• Write-ResponseLogs
• Microsoft.TeamFoundation.DistributedTask.Task.Deployment.RemoteDeployment
• Invoke-RemoteDeployment

Furthermore some cmdlets are added to the existing modules:

• Microsoft.TeamFoundation.DistributedTask.Task.Deployment.Azure.psm1
• Set-CurrentAzureRMSubscription
• Set-CurrentAzureSubscription
• Microsoft.TeamFoundation.DistributedTask.Task.DevTestLabs.dll
• Get-ExternalIpAddress
• Get-ParsedSessionVariables
• Microsoft.TeamFoundation.DistributedTask.Task.Internal.dll
• Get-IndexedSourceFilePaths
• Get-TfsClientCredentials

It also seems that in the Microsoft.TeamFoundation.DistributedTask.Task.Internal.dll, Invoke-IndexSources cmdlet is not available any more.

You can reference these modules from your custom Build tasks by calling a standard import module cmdlet.

import-module "Microsoft.TeamFoundation.DistributedTask.Task.Common"

If you are interested about the agent version, you can check it by executing the vsoagent on your build server, with the following parameter:

VsoAgent.exe /version

As soon as an RTM version of the Update 1 becomes available, I’ll update this post.

In case you are interested in a short description of these functions, you can their source code for further info

A good practice for mapping TFS collections on local path

Mario Majcica June 7, 2012 0 Comments

How many times did you asked yourself, what now, in front of a very simple question? Then you chose a first thing that came under your mouse? I did it many times! Later this lead me also many times to a problem. One of this banal situations is mapping a local path for a TFS Collections/Projects. Hands up who went creating a directory on C drive and indicating a newly created map as TFS local path! Great, I did the same! However later on, based on experience, I found a way of mapping collections which I believe is a good practice. In the following lines I will share my ideas with you. Any suggestion or observation is welcome, so feel free to comment this post.

Why is not a good idea to just create a folder Projects on a C drive and map everything under it? Well, at first this PC may be used by others, this arise a problem, that can be first of security nature, second can create confusion and problems if the new user chooses the same directory for mapping.

Based on this information, a good place where to store your code is user folder. Generally you can find your user folder in C:\Users\%username% on Vista, 7 and 8, C:\Documents and settings\%username% on XP and 2000. What I follow as a rule is to create a top folder called Projects and then inside that folder a sub folder for every collection I have access to. Supposing that my collection is called ACNProject the full path on my PC looks like C:\Usersmario.FLORES\Projects\ACNProject.

However in some cases this can be a problem. If you are using a roaming profile, you will need to do a couple of tweaks. You must exclude this newly create folder from synchronization and in order to be sure about that, you need to check the following registry key:

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\ExcludeProfileDirs

You will then find a similar content as on the following image:

Now you need to edit this key by adding at the end the folder name that is situated in Users directory, in this case Projects. Different folders are separated by ; sign. If this became a company rule, you can avoid this step by applying the same changes via a group policy.
In case you do not have the rights for editing the registry and you are still using a roaming profile, a good place where to store the files can be C:Documents and settings%username% AppDataLocal which by default is never synced.

Now we are ready to map our collection. Open Visual Studio and Team Explorer.

Click on local path and digit the above mentioned path. Make sure that you clicked on collection folder (the $ sign will be visualized as a server folder) and that Recursive check is on. In this way for all the projects in that collection, automatically a folder will be created and mapping will have a recursive effect (all the projects in the collection will be automatically mapped).

Now you will be prompted about getting the latest version of all data from the server, choose no if there are many projects and you need a specific one and then get the latest version of that specific project, otherwise choose yes.

Certainly there can be a case that this approach will not fit, however I consider this a good practice. If you have any suggestions or comments, they are always welcome and I’m always ready to reconsider this task if anything meaningful pops up.

Cheers!