Unlocking a file from TFS

Inevitably somebody on the team goes away on holidays and forgets to check everything into TFS (guilty, as charged!)

There’s no facility to unlock somebody else’s files through TFS Explorer, so we have to resort to the command line.  Firstly, get the list of the user’s workspaces:

tf workspaces /server:tfsserver /owner:DOMAIN\offender /computer:*

This will list the workspaces “owned” by the offending little tyke absent user, which we will feed into the next command:

tf undo /server:tfsserver /workspace:workspacename;DOMAIN\offender $/path/to/file/to/unlock

Now you’re free to change the file at will, and reprimand your teammate when he gets back from his holiday, all tanned and relaxed.

Another FYI: just type in tf on the command line, and it will open up the appropriate help file. Sweet!

Setting up the BizTalk SharePoint adapter

While deploying a solution that uses the BizTalk adapter for SharePoint, we ran into the following error in the EventLog on the BizTalk box:

Client found response content type of 'text/html; charset=utf-8', but expected 'text/xml

Not exactly helpful when you’re trying to remotely diagnose the root problem!

After a little fact checking, it turns out that we had configured the SharePoint adapter correctly on the SharePoint box, however the BizTalk side of the configuration was trying to contact the SharePoint adapter on the default port 80.  We had installed the adapter into the non-default web site on the SharePoint machine, and it was listening in on a different port.

So, the actual message being returned to BizTalk was the actual HTML page spat back from IIS, telling us that the requested endpoint did not exist (i.e. we got the port wrong), but the client proxy end of the BizTalk adapter was expecting an Xml document, not an HTML document