Internal extensions in TFS

Some of the TFS Azure DevOps functionality that comes out of the box is internally organized the same way third party extensions are. You can even see their manifests:

use Tfs_Configuration;
select p.DisplayName, p.PublisherName, e.ExtensionName,
    e.DisplayName, e.ShortDescription, cast(Content as varchar(max)) as Content
    from Gallery.tbl_Asset a
        inner join Gallery.tbl_Extension e on a.ReferenceID=e.ExtensionId
        inner join Gallery.tbl_Publisher p on e.PublisherId = p.PublisherId
        inner join tbl_FileReference r on a.FileId = r.FileId
        inner join tbl_Content c on r.ResourceId = c.ResourceId
    where AssetType = 'Microsoft.VisualStudio.Services.Manifest'
    order by e.ExtensionName, a.Version desc

I can see multiple versions of the same extension there, my TFS instance went through several version upgrades; on a freshly installed copy there would probably be only one.

Let me know, TFS

Today's obscure corner of the TFS REST API to explore would be - notifications. Some time ago, I've noticed that SOAP is no longer an option on the collection-level Notifications screen, but it's supported internally. If it's supported internally, then it must be supported by the API. Indeed it is, there's a REST API endpoint for subscription creation, and one of the parameters is called "channel", and it's supposed to be an instance of ISubscriptionChannel. That's where the docs go blank, except mentioning that it has a type property.

"Now" means last week

What the world needs is a dynamic database record/replay tool.

Okay, maybe not the world. But for me and for my software shop, that would address a need.

OAuth scopes in TFS 2019

Now that I have a TFS Azure DevOps 2019 box, let's dump the scopes from that one, too.

The same caveat applies: some of those might be cloud only.

TFS 2019 and commitment issues

My JavaScript TFS extensions broke in TFS Azure DevOps 2019. All my complaints about TFS API surface being underdocumented came to their logical conclusion: no docs means no API commitment, no commitment means the team behind the API gets to make breaking changes with no guilt.

Let me count the ways things broke:

Federating TFS tables across collections

UPDATE: the outlined logic will break if your TFS instance has a mix of pre-AzDevOps collections with recently (2019+) created ones. Details here. The linked gist was updated, too.

As I've mentioned earlier, Team Foundation Server stores its data in multiple databases - one database per team project collection, and also a global database called Tfs_Configuration. How is one supposed to run cross-collection queries, then?

Can't we just do a "Hello, world"?

The Joomla! component tutorial walks you through creating a Model-View-Controller (MVC) component. However, the Absolute basics of a component page also mentions that a component doesn't have to be MVC; it claims that a flat model is supported, but then spends no time explaining how it's supposed to work.