Eric lippert - Amazon Web Services

Since these event handlers execute on TFS itself (in fact,
within the process of TFS), these can be written using any of the
Microsoft .NET languages. It does not matter which client
performed the activity that triggered the event, which means
that even if your project is a Java project, the event handler will
still have to be written in .NET.
The same Team Foundation Object Model can also be used to
access Team Foundation Services from standalone applications.
For example, we can create new Requirement type work items
when a requirement document is approved in SharePoint. For
this purpose, we can write a SharePoint workflow application
in which we can refer to the TFS APIs, use those to create new
Requirement type work items as desired and then associate that
workflow with the appropriate library on the SharePoint portal.
Following code shows how to do that (Some of the methods to
handle worksheet data are not shown as they are secondary to
the purpose)
private void CreateRequirements()
{
prj = (string)workflowProperties.Item[“Team Project
Name”];
collection = new TfsTeamProjectCollection(new
Uri(“http://ssgs-vs-tfs2012:8080/tfs/
DefaultCollection”));
store = collection.GetService();
SPWeb web = workflowProperties.Web;
SPFile file = web.GetFile(@”http://ssgs-vs-tfs2012/
sites/DefaultCollection/SSGS%20CMMI/Requirements%20
Documents/RequirementDocument.xlsx”);
SPFileStream dataStream = (SPFileStream)file.
OpenBinaryStream();
SpreadsheetDocument document = SpreadsheetDocument.
Open(dataStream, false);
WorkbookPart workbookPart = document.WorkbookPart;
IEnumerable sheets = document.WorkbookPart.
Workbook.GetFirstChild().
Elements();
string relationshipId = sheets.First().Id.Value;
WorksheetPart worksheetPart =
(WorksheetPart)document.WorkbookPart.
GetPartById(relationshipId);
Worksheet workSheet = worksheetPart.Worksheet;
SheetData sheetData = workSheet.
GetFirstChild();
IEnumerable rows = sheetData.
Descendants();
int i = rows.Count();
foreach (Cell cell in rows.ElementAt(0))
{
string Title = GetCellValue(document, cell);
WorkItem Requirement = new WorkItem(store.
Projects[prj].WorkItemTypes[“Requirement”]);
Requirement.Title = Title;
Requirement.Save();
}
}
public static string GetCellValue(SpreadsheetDocument
document, Cell cell)
{
SharedStringTablePart stringTablePart = document.
WorkbookPart.SharedStringTablePart;
string value = cell.CellValue.InnerXml;
if (cell.DataType != null && cell.DataType.Value ==
CellValues.SharedString)
{
return stringTablePart.SharedStringTable.
ChildElements[Int32.Parse(value)].InnerText;
}
else
{
return value;
}
}
Another use of this object model is to create custom check-in
policies. Such a custom check-in policy will exclusively use client
side objects of Team Foundation Server. Checks on the code or
associated work items can be done by using those. For example,
we can check if the code being checked in has an associated
work item of a specific type like a ‘Code Review’ and make
further check on it to ensure that it is having the state as
‘Approved’, for allowing the check-in to succeed. Since check-in
policy is enabled on TFS but executes on the client side, it has to
be developed using a language that is appropriate for the
client environment. To develop check-in policies for Visual
Studio, we can use Microsoft .NET languages, but for Team
Explorer Everywhere 2012, that is a plug-in to Eclipse, we can
use TFS SDK 2012 (For Java). It can be downloaded from http://
www.microsoft.com/en-us/download/details.aspxid=22616.
Many of the applications that use the Team Foundation Object
Model are rich client applications so that they can reference the
assemblies that encapsulate these objects. Size of such
applications along with the TFS API assemblies is not optimized
for lean environments like Windows Phone, Android Apps and
Windows Store Apps (for Surface). For such environments, we
need a broker that will consume TFS data using heavy TFS API
assemblies and then in turn publish that same data as a lean
HTTP service.
60 | DNCmagazine www.dotnetcurry.com