Uploading extensions to TFS

When creating a TFS extension, one ends up uploading it to the server all the time. Doing so through the Web UI is tedious, so here's a script for that.

It takes two parameters:

• Server - the URL of the TFS instance, e. g. http://tfs.acme.com:8080/tfs/
• File - the filename of the compiled .VSIX file, wildcards allowed

Since the file name of a compiled VSIX extension contains its version, the script takes wildcards in the File parameter. If there are multiple files that match the wildcard, the one with the latest modification date will be taken.

The script looks inside the VSIX to determine the publisher, the extension ID, and the version.

The script was meant for on-prem TFS. Microsoft's TFX command line tool can do the same for VSTS, but it doesn't support NTLM auth (because Node.js' HTTP client doesn't). Mine is in Powershell, where NTLM support comes out of the box.

All OAuth scopes in TFS

Did I already complain that the API surface of Team Foundation Server is sorely underdocumented? Well, it is. In today's episode, we're going to explore the gamut of things an OAuth Web client can and cannot do.

In my work, the OAuth clients are TFS client-side extensions. In order to access the TFS API, they need to declare the set of scopes they're interested in in the extension manifest. The scopes are supposed to be documented here, but the list over there is incomplete.