How can I remove/fix a ghost workspace

Question

Somehow I have ended up with a \"ghost\" workspace. It doesn\'t show up in Visual Studio under Manage Workspaces. When I connect to VS Team Services and open source control expl

Answer 1

You can use tf workspaces command to get detailed XML info for all workspaces, including owner uniqe id and owner alias user names:

tf workspaces /owner:* /format:xml

Sample output:

<Workspace computer="computer" name="wrkspacename" ownerdisp="Some Name" 
    ownerid="S-1-5-00-0000000000-0000000000-000000000-0000" 
    ownertype="System.Security.Principal.WindowsIdentity"
    owner="12345678-90ab-cdef-1234-567890abcdef"
    owneruniq="12345678-90ab-cdef-1234-567890abcdef">
  <Comment />
  <Folders>
    <WorkingFolder local="C:\Folder" item="$/Folder" />
  </Folders>
  <LastAccessDate>2019-01-01T01:02:03.456+00:00</LastAccessDate>
  <OwnerAliases>
    <string>SERVER\Name</string>
    <string>Name</string>
    <string>Some Name</string>
  </OwnerAliases>
</Workspace>

You can then try some of the OwnerAliases as owner to delete workspace or directly use owneruniq:

tf workspace /delete wrkspacename;12345678-90ab-cdef-1234-567890abcdef

Answer 2

Buck is most certainly right about the identity issue. I stumbled upon it yesterday after an Azure AD migration. Fortunately there is a way around. Here is the PowerShell solution that I found with the help of the Team Foundation .NET assemblies. (For the record I am using PowerShell version 5.0.)

1. Load these assemblies into your PowerShell session (where the version matches your installation of Visual Studio; in my case Version=12.0.0.0 corresponds to VS 2013):

Add-Type -AssemblyName 'Microsoft.TeamFoundation.Client, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
Add-Type -AssemblyName 'Microsoft.TeamFoundation.VersionControl.Client, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

2. Connect to the VSTS version control server:

$uri = 'https://me.visualstudio.com/defaultcollection'
$tfs = [Microsoft.TeamFoundation.Client.TfsTeamProjectCollectionFactory]::GetTeamProjectCollection($uri)
$vcs = $tfs.GetService([Microsoft.TeamFoundation.VersionControl.Client.VersionControlServer])

3. Query for the workspace you want to delete and retrieve its qualified name:

$vcs.QueryWorkspaces('WorkspaceName', $null, $null) | % QualifiedName

You might have a look at the QueryWorkspaces online help. If the call to QueryWorkspaces() does not return anything, which is the case if you only pass a computer name, you might have to issue it this way instead:

Invoke-Method -InputObject $vcs -MethodName 'QueryWorkspaces' -Arguments $null, $null, 'ComputerName' | % QualifiedName

It seems to be dued to the fact that $null cannot be passed directly from within PowerShell. I had the issue before and this post helped me (but it seems to be now retired).

4. Pass the qualified name to TF.exe to delete the workspace (remember it is PowerShell, hence the --%):

tf workspace /collection:$uri --% /delete 'WorkspaceName;11111111-2222-3333-4444-555555555555'

Notice that you might as well call the Delete() method on the Workspace object returned by the QueryWorkspaces() issued against VCS...

HTH

Answer 3

What's happened here is that you have two identities with the same display name. One of the identities is an old identity that was created with your Microsoft Account (MSA). The new identity is your Azure AD account (AAD). Internally, they have different GUIDs. When you run the tf command workspace /delete command with the owner name that was displayed, the ambiguous display name is resolved to the current identity (AAD) rather than the old identity (MSA) that actually owns the workspace.

I can't remember for sure, but it's possible you could run tf workspace /delete and use a wildcard for the owner if you are certain that you can safely delete all workspaces for any owner with that workspace name (be very careful to make sure you don't delete someone else's workspace).

I'd recommend trying the Attrice Sidekick for TFS and using the manage workspaces functionality there to see if you can delete the workspace under your old identity. That will be the safest and easiest route if it works.