c:\>TFS

Today, we're going to take a look at another wonderfully disjoint area of TFS Azure DevOps administration - command line clients. There are four Microsoft provided ones (that I know), and another that's probably the best of them all.

Tf.exe, the Visual Studio one

This is the command line utility that comes with Visual Studio. As of Visual Studio 2019, it resides under (Visual Studio)\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer, and its primary focus is source control, both TFVC and Git. Plays nicely with the Visual Studio TFVC integration, in the sense that it's aware of local workspaces. By default, it's not under PATH, but it is if you open the Developer Command Prompt.

Since it ships along with Visual Studio, it's definitely by Microsoft. Historically, it's probably the oldest command line TFS client.

Tfx, the node.js based one

This one is familiar to anyone who has ever developed TFS extensions. It comes as an NPM package called tfx-cli, its NPM home is here, and its sources are out on Github, under Microsoft. The focus is different; it has three sections:

1. extension
2. build
3. workitem

Unlike Tf.exe, it's cross platform. For the same reason, it doesn't support Windows (NTLM) authentication when connecting to on-prem TFS from a Windows client; that's a major functional gap of the node.js HTTP client.

To the best of my knowledge, this tool is the only way to compile an extension to a VSIX file.

Az devops, the misleadingly named one

"Az" is a command line utility for administering all things Azure, including the bits that are branded as Azure but are not cloud based (e. g. the on-prem Azure DevOps Server, formerly known as TFS). It ships as a standalone installation script (MSI), but internally, it's a Python app. A copy of Python 3.6 ships along with it (at least for Windows). Like the previous one, it's cross platform by virtue of its Pythonic nature, and incapable of using Windows auth for the very same reason.

It's home on Github is under Azure, definitely a Microsoft property.

Az has a plugin based architecture, and TFS relevant bits are but a small subset of downloadable functional areas. It used to be that all TFS commands were under "devops", but not anymore; as of April 2020, the following areas are supported:

1. az devops
2. az pipelines
3. az boards
4. az repos
5. az artifacts

Which roughly correspond to the functional areas of the TFS Web UI.

vsts, the not-quite-abandoned old version 

An old version of az devops that's still documented and offered up for download separately. This tool was renamed, rebranded and rewritten as az devops; you can see its old forks on Github being still called "vsts-cli", but pointing at Azure/azure-devops-cli-extension.

VSTeam, the Powershell one

It's a Powershell downloadable module, installed via Install-Module. It's under active development, and it also has functionality pretty much across the board. It provides a plethora of Powershell cmdlets; the only downside is, well, Powershell. Does Powershell even count as a command line? They claim it runs under Powershell Core under *nix (I've never tried), but on Windows, it supports NTLM auth.

Its home is at the Powershell Gallery, and the sources are out on Github. This one is not branded as Microsoft, but the principal maintainer is a Microsoft employee who blogs about TFS a lot. I'm not sure what to make of this arrangement.

The set of functionality is eclectic and uneven. This tool is not vying to cover the whole API surface (az devops does); they don't even try with the work item functionality, and there's almost nothing you can do with TFVC source control. Most cmdlets are rather thin wrappers on top of REST API calls. This tool is mostly concerned with setup-type tasks as opposed to day-to-day software development. That said, the maintainers tend to honor feature requests, and release fairly often.