Team Foundation Server Team Foundation Server and Exchange

Team Foundation Server and Exchange

Build a Ticketing System Using Exchange and Team Foundation Server

Mohammad Jalloul

Download the Code Sample

Team Foundation Server (TFS) provides a great mechanism for creating and managing tickets via its powerful work item tracking functionality. Such tracking is typically accomplished in one of two ways. In the first, a support representative with access to TFS via its Web interface (known as Team System Web Access, or TSWA) creates a custom work item type for a support ticket, entering the necessary details. In the second method, an interface is created to wrap around the work item functionality and simplify access to it for external users who don’t need to know about TFS. The work item is then typically assigned to a software engineer who tracks and manages the work item from within Visual Studio. The goal of both methods is to move ticket creation from e-mail or proprietary database systems to TFS due to its many advantages—in particular that TFS work items have a workflow that defines the lifecycle of a ticket. Anyone can keep track of a ticket by monitoring changes to the work item and viewing the work item history. Integration with the TFS data warehouse provides an added benefit, as you can leverage the powerful reporting capabilities of SQL Server Reporting Services (SSRS) or Excel Services.
Despite such methods, e-mails often get sent around anyway, to further explain the issue or add more detail. This additional e-mail-thread information is sometimes lost, and other times manually copied into the work item history to keep the context of the work item as complete as possible. This manual intervention defeats the purpose of work items and can kill the productivity that work items were designed to provide.
I’ll present a third method in this article that takes the best of both worlds: e-mail and work items. This approach starts with e-mail—just as support reps have been doing for a long time.

Exchange Web Services

The process I’ll present uses the power of Microsoft Exchange Web Services (EWS) to subscribe to notifications for e-mails sent to an Exchange 2007/2010 distribution list. The listening Web service creates a work item based on any new e-mail received. Any subsequent e-mails related to the same thread are appended to the work item history, using the conversation-tracking capabilities of Microsoft Exchange Server, thus mirroring the e-mail thread in the work item. The work item also maintains a workflow. This way the users—the support representatives—are not changing their habits to adapt to a new technology; instead, the technology is taking their process and automating it.
Figure 1 shows how the process will typically flow.

Figure 1 Process Flow for the Support Ticket Work Item
The following explains the flow in more detail:

1. The flow starts when a support representative is notified of an issue with a product.
2. The support rep sends an e-mail describing the issue to a distribution list (DL) in Exchange. The DL includes anyone who needs to know about the issue and can assign it to the appropriate developer to resolve it. The DL also contains a “watcher” e-mail account that exists only for notification purposes. The watcher account is registered with Exchange so that it will receive notifications at a specific Web service address.
3. Exchange processes the e-mail, routing it to all the members of the DL and sending notifications to any Web services that are registered to receive them for a specified e-mail account.
4. The support ticket Web service receives a notification from Exchange via its Web service interface.
5. The Web service processes the notification and requests additional information related to the e-mail address. It then creates a Support Request work item in TFS, which is populated with information extracted from the e-mail message.
6. The DL members also receive the e-mail and they may respond by asking for more information, which the support rep will send. Because the DL is included in the To or CC fields of the e-mail message, the watcher e-mail account is aware of this and the notifications Web service receives notifications of all the e-mails happening in the thread. TFS updates the Support Request work item with the additional information.
7. The ticket is assigned to a developer using the Assigned To field of the Support Request work item just created.
8. The developer starts working on the issue, changing the state of the work item to In Progress. When the code containing the fix is reviewed, tested and completed, it will be checked in. The resulting changeset is associated with the Support Request work item. This work item now tracks both the e-mail conversation and the changeset related to the fix.
9. If the support rep has access to TFS, the Support Request can be assigned to him for closing. Otherwise, the DL can be notified via e-mail. Typically, project managers and leads will set up TFS Alerts so they’re notified when a Support Request work item has been resolved. This takes place when the work item is changed from In Progress to Done.

The process is actually similar to what usually takes place in real-life scenarios involving support issues—except, in real life, the e-mail thread and ticketing system are typically two completely different and separate systems.

The Support Ticket Notifications Web Service

The Support Ticket Notifications Web service uses the EWS Managed API, which lets managed .NET applications communicate with EWS using documented interfaces via familiar SOAP-based messaging. You’ll find a detailed description of the EWS Managed API at bit.ly/jGKRgG.
EWS is not a typical part of a Microsoft Exchange installation, and in many IT setups, it’s installed on a separate Exchange Client Access server. To be usable, the services have to be installed and configured with Microsoft Exchange. You’ll need to obtain the EWS Web service URL from your Exchange administrators, which will look something like https://hostname/EWS/Exchange.asmx. Note that these Web services are typically set up on an SSL endpoint.
The latest version of the EWS Managed API at the time of this writing is 1.1. This version supports Microsoft Exchange Server 2007 SP1 through Exchange Server 2010 SP1. You can download it from bit.ly/mkb7Is.
By default, the installer copies the files to [Program Files]\Microsoft\Exchange\Web Services\1.1. The API is packaged into a single assembly named Microsoft.Exchange.WebServices.dll. The installation folder includes two important files you should review before starting to work with the API: Readme.htm file and GettingStarted.doc.
The first step in interacting with EWS is to create a Web service to listen to notifications coming from Exchange. Once this Web service is created, it must be registered with Exchange in order to start receiving notifications.
The Microsoft Exchange Server 2010 SP1 Web Services SDK simplifies the creation of such Web services. You can download the October 2010 release (the latest version at the time of this writing) at bit.ly/kZtjLq.
The SDK makes it much easier to build the first Web service. It contains four samples that explore different areas targeted by the API. You can access the samples after installing the SDK by navigating to the Start menu | All Programs | Exchange Server 2010 SP1 Web Services SDK | October 2010 | Exchange Server 2010 SP1 Web Services SDK Sample Directory. The sample that’s of particular interest is PushNotification, which demonstrates a push notifications Web service that listens to and processes incoming notifications from Exchange. This sample also contains a client application you can use to create a subscription in Exchange for the Web service. Using this sample as a base implementation makes it easy to understand the way EWS works and to verify that all the required pieces are functional.

Subscribing with Exchange

You’ll need an Exchange account to create a notifications subscription with Exchange. The subscription will set up the routing such that any e-mails sent to that account’s mailbox will result in Exchange making a call to the notifications service registered for that account. Note that it’s possible to register more than one notification for any given account. In fact, it’s even possible to create more than one subscription for the same Web service endpoint. From an Exchange and EWS perspective, this is perfectly legitimate.
The only requirement for Web services registered with EWS is that they implement a certain interface, INotificationServiceBinding, which has the following signature:

public interface INotificationServiceBinding {
  SendNotificationResultType SendNotification(
    SendNotificationResponseType sendNotification);
}

The only requirement is that the Web service contains an implementation of the SendNotification method. This is the Web method that will be called by Exchange whenever an e-mail matching the subscription attributes is received.
Going back to the PushNotification sample and, in particular, the PushNotificationSubscriber console application, it becomes clear what a subscription entails. Figure 2 shows the SubscribeForPushNotification method taken from the PushNotificationSubscriber.cs file.
Figure 2 Subscription Code from the PushNotification Sample

public static void SubscribeForPushNotifications()
{
  System.Net.ServicePointManager.ServerCertificateValidationCallback =
    delegate(Object obj, X509Certificate certificate, X509Chain chain,
    SslPolicyErrors errors)
  {
      // Replace this line with code to validate server certificate.
      return true; 
  };
 
  // Create the bindings and set the credentials.
  ExchangeServiceBinding esb = new ExchangeServiceBinding();
  esb.Url = "https://CAS01.contoso.com/EWS/exchange.asmx";
  esb.Credentials = new NetworkCredential("username", "password", "domain");
 
  // Create a new subscription.
  SubscribeType subscribeRequest = new SubscribeType();
  PushSubscriptionRequestType pushSubscription = 
    new PushSubscriptionRequestType();
 
  // Subscribe to events in the inbox folder.
  BaseFolderIdType[] folders = new BaseFolderIdType[1];
  DistinguishedFolderIdType folderId = new DistinguishedFolderIdType();
  folderId.Id = DistinguishedFolderIdNameType.inbox;
  folders[0] = folderId;
  pushSubscription.FolderIds = folders;
 
  // Subscribe to all events.
  NotificationEventTypeType[] eventTypes = 
    new NotificationEventTypeType[6];
  eventTypes[0] = NotificationEventTypeType.NewMailEvent;
  eventTypes[1] = NotificationEventTypeType.CopiedEvent;
  eventTypes[2] = NotificationEventTypeType.CreatedEvent;
  eventTypes[3] = NotificationEventTypeType.DeletedEvent;
  eventTypes[4] = NotificationEventTypeType.ModifiedEvent;
  eventTypes[5] = NotificationEventTypeType.MovedEvent;
  pushSubscription.EventTypes = eventTypes;
 
  // Receive push notifications every 1 minutes.
  pushSubscription.StatusFrequency = 1;
 
  // Identify the location of the client Web service.
  pushSubscription.URL = "http://clientWebService/Service.asmx";
 
  // Form the subscribe request.
  subscribeRequest.Item = pushSubscription;
 
  // Send the subscribe request and get the response.
  SubscribeResponseType subscribeResponse = 
    esb.Subscribe(subscribeRequest);
 
  // Check the result.
  if (subscribeResponse.ResponseMessages.Items.Length > 0 &&
    subscribeResponse.ResponseMessages.Items[0].ResponseClass ==
      ResponseClassType.Success)
  {
    SubscribeResponseMessageType subscribeResponseMessage =
      subscribeResponse.ResponseMessages.Items[0] as   
        SubscribeResponseMessageType;
 
      using (StreamWriter sw = new StreamWriter("MailboxEventLog.txt"))
      {
        sw.WriteLine("Subscribed for Push notifications: {0}", 
          subscribeResponseMessage.SubscriptionId);
      }
  }
 
  CreateXmlMessageTextFile(subscribeRequest, subscribeResponse);
 
}

I’ve included the code in Figure 2 here because it illustrates the key features available when registering a subscription. In particular, notice how the sample assigns the first piece of information, the Client Access server URL:

esb.Url = "https://CAS01.contoso.com/EWS/exchange.asmx";

It then uses the credentials of the e-mail account to authenticate with EWS:

esb.Credentials = new NetworkCredential("username", "password", "domain");

Notice also that once you’ve created a subscription object, you can configure it so that it only subscribes to certain events (new mail, copying, moving, deleting, modifying and so on) or to specific mail folders. This provides great flexibility, as you can delegate the filtering to Exchange rather than subscribing to all events and filtering in the application later.
Finally, note the StatusFrequency property. This is a numeric value that defines, in minutes, how often Exchange sends heartbeat calls to the Web service to make sure that the registered endpoint is alive. This helps Exchange cancel subscriptions to endpoints that are no longer valid, such as for a Web service that’s moved to a new host and hence has a new URL. If you forget to unsubscribe before moving the Web service, the subscription can last indefinitely, and Exchange would keep sending notifications unnecessarily to a nonexistent endpoint.
Now let’s look at the customized implementation to support the creation of Support Request TFS work items. The best way to present the functionality is to start with a demo of the Web service and then dive into the implementation.

Deploying the Web Service

The code project that accompanies this article contains only a Web service and several other supporting artifacts. There’s no separate console application to take care of the registration because it’s built into the Web service.
Once built, the Web service can be deployed either from Visual Studio 2010 or by copying the resulting precompiled Web site to a host. You’ll need to manually create the Web application and a corresponding application pool. Set the identity of the application pool to the watcher user account. This is important because the Web service can impersonate the identity of the app pool and use that to perform the subscription. This has two benefits:

1. The credentials won’t have to be re-entered every time the Web service needs to be reregistered.
2. The credentials won’t need to be stored where they might be accessible in order to use them to resubscribe.

The Web service needs to have write permissions to two folders: the folder to which it writes logs and the folder it uses as the TFS cache. In addition, you’ll need to configure the following settings in web.config, as they depend on the particular environment where the Web service is used:

• EWSServiceUrl: The Exchange Service URL; get this URL from the Exchange administrators.
• TeamFoundationServerUrl: The URL of the TFS project collection where the work items are deployed (for example: http://<servername>:8080/tfs/).
• WorkItemTeamProject: The name of the TFS Team Project that contains the support ticket work item type (for example: SupportWorkFlow).
• WorkItemType: The actual name of the support ticket work item type (for example: Support Request). If the work item is renamed or if the Web service is used to support some other work item type (as I’ll show later in this article), you can use this to set the name of the new work item.
• RequestSupportTeamName: The work item contains a “Request Support Team” field for directing different teams to different support tasks. This is driven by a global list called Teams in the work item definition. To use this feature, keep the field definition and create the global list (instructions are included in the next section of this article, “Configuring the Work Item”) and assign one of the values of the global list to the RequestSupportTeamName configuration key (for example: Customer Service). If not, remove the global list for the field and the “Required” constraint from the work item and leave the value of the RequestSupportTeamName key blank.

At this point the Web service is ready to be used. You can verify it’s set up correctly using IIS Manager on the Web server to navigate to the Web application folder (remember to click on the Content View tab at the bottom if using IIS 7 or later). Then right-click on the Service.asmx file and click on Browse, as shown in Figure 3. You should see a Web page identical to the one shown in Figure 4.

Figure 3 Browsing to the ASMX Page

Figure 4 Default Web Service URL with localhost as the Host
Before you can start using the Web service, you’ll need to import the work item into TFS. This article assumes you’re using TFS 2010, but the same work item and Web service can be used with TFS 2008.

Configuring the Work Item

The sample code for this article (which you can download at code.msdn.microsoft.com/mag201108TFS) contains a sample support ticket work item type called Support Request. In order to view the work item type definition, workflow and layout prior to importing into TFS, you need to install TFS Power Tools, available at bit.ly/hyUNqo. When you install TFS Power Tools, a new menu called Process Editor is added to the Visual Studio IDE under the Tools menu. Double-click on Support Request.xml (located under the Work Item folder in the sample solution). The Work Item Editor window will be loaded with three tabs: Fields, Layout and Workflow, as shown in Figure 5.

(click to zoom)
Figure 5 Workflow for the Support Ticket Work Item
The work item Workflow shows the different states that the work item supports: New, when the work item is first created; In Progress, when the issue documented in the work item is actually being worked on; and Done, when work on the issue concludes.
If you decide to configure the Request Support Team field, as discussed earlier, locate the Request Support Team field under the Fields tab, double-click it to open the Field Definition dialog, and then click on the Rules tab. If you don’t plan on using this field, just delete the two rules listed (ALLOWEDVALUES and REQUIRED). If you do want to use the field but would like to configure it to use a different global list, double-click on the ALLOWEDVALUES rule and then on the only entry present: GLOBALLIST: Teams. In the List Item Edit dialog, pick a global list and click OK.
If you don’t have a global list set up yet, you can create one (you’ll need to have TFS Administrator permissions):

1. In the Visual Studio IDE, go to Tools | Process Editor | Global List and then click on Open Global List from Server.
2. You’ll be presented with a dialog. Select the Team Project Collection and click on Connect.
3. In the Global List dialog, right-click on any item and then click on New Global List.
4. Enter a name for the global list. You can keep the same name as in the work item: Teams.
5. Right-click the new global list and click on New Item. Repeat this step for as many times as needed to enter the team names.
6. Click OK to save the new global list.

Note that if you’ve given the new global list a different name, you’ll need to edit the work item and update its definition with the global list name.
At this point, all that’s left is to import the work item into TFS, like so:

1. In the Visual Studio IDE, go to Tools | Process Editor | Work Item Types and then click on Import WIT (WIT stands for Work Item Type).
2. Click the Browse button and navigate to the location of the Support Request.xml file.
3. In the Project to Import to list, click on the name of the TFS Team Project into which you want to import the work item and then click OK.

You can verify that the work item was successfully imported into TFS by right-clicking on the Work Items node for that Team Project from within Team Explorer and then expanding the New Work Item window. You should see Support Request as one of the available options. If you don’t see it there, right-click the Work Items node and then click on Refresh.

Creating a Subscription

As shown in Figure 4, the Web service has three methods: Check Status, SendNotification and Subscribe. The Subscribe Web method is used to create the notification subscriptions.
The subscription process will create a subscription for the user account that’s set as the identity of the Web service App Pool. To use the notifications effectively, that account—the watcher account—should be part of a DL that is to be monitored, as shown in Figure 6.

Figure 6 Adding the Watcher E-mail Account to a Distribution List
To create a subscription, click on the Subscribe link on the Web page shown in Figure 4. Then click on the Invoke button on the resulting Web page. Upon success, you’ll see a subscription ID. This is also logged into the logs folder defined in the web.config file.
The details of the subscription are logged into two files. The first logs the request sent to EWS to perform the subscription and has the form SubscribeType-<timestamp>.xml. The second file logs the response received from EWS to confirm the subscription, and has the form SubscribeResponseType-<timestamp>.xml. A third file named SubscriberEventLog.txt logs all the events received by the Web service from Exchange, including a heartbeat status event every minute and New Mail events whenever they’re triggered.
The status of the subscription can be verified at any point by calling the CheckStatus Web method, which produces a result similar to that shown in Figure 7, which shows the time the last heartbeat event was received and the status of the Web service subscription. If there’s an active subscription, you’ll see “Status: Subscribed,” as shown in the figure.

Figure 7 Sample Output from the CheckStatus Web Method
The overall process is depicted in the sequence diagram in Figure 8.

Figure 8 The Subscription and Notification Process

Using the Ticketing System

The easiest way to start using the ticketing system is to mimic a real scenario and send an e-mail to the DL that contains the watcher account. Figure 9 shows a sample e-mail to the DL shown in Figure 6, and Figure 10 shows the Support Request work item that’s generated as a result of the notification sent from Exchange to the notifications Web service.

Figure 9 The First E-mail in a Mail Thread

(click to zoom)
Figure 10 The Work Item Generated as a Result of the First E-mail
Figure 11 shows the result of sending other e-mails as part of the same e-mail thread and how that’s translated into the work item history. The first thread gets a distinct color for its header. The rest of the threads get another distinct color (yellow in this case, but the colors can be configured in web.config).

(click to zoom)
Figure 11 The Work Item After a Second E-mail

Customizing the Code

Now let’s take a look at the different pieces of code that make the system operate. The sample code for this article contains a Visual Studio 2010 solution called Email2Workitem.sln. When you load this solution in Visual Studio, you’ll see that the structure is divided into four solution folders: Diagrams, Subscription Library, Web Service and Work Item.
For the most part, the Web service is based on the PushNotification SDK sample. However, I made some changes in order to keep the solution generic and easy to use. I’ll go over the changes and customizations I made to turn the sample into a ticketing solution.
The first major change is the functionality that lets the subscription process be integrated into the Web service. This is crucial because it allows the Web service to subscribe without having to manage the account credentials. Sometimes the subscription needs to be renewed, such as when the server hosting the Web service undergoes some maintenance activities, for example. When that happens, the App Pools are typically stopped and Exchange cancels the subscriptions because the heartbeat event gets no response. The auto-renewal of the subscription is achieved by calling the InitializeTimer method in the Web service constructor. InitializeTimer, shown in Figure 12, creates a timer with an interval specified in web.config. This timer is responsible for renewing a subscription after service interruptions, for example.
Figure 12 The InitializeTimer Method

private void InitializeTimer()
{
  int autoSubscribeTimeoutThresholdInMinutes = Convert.ToInt32(
    ConfigurationManager.AppSettings["AutoSubscribeTimeoutThresholdInMinutes"]);
 
    lock (_pollingTimerSyncLock)
    {
      if (autoSubscribeTimeoutThresholdInMinutes > 0)
      {
        // Seed the timer with the polling interval specified in config.
        if (_pollingTimer == null)
        {
          TimerCallback timerCallback = OnTimedEvent;
          _pollingTimer = new Threading.Timer(timerCallback, null, 0, 
          _pollingIntervalInMilliseconds); // Enable the timer.
        }
      }
      else
      {
        // Dispose of the timer.
        if (_pollingTimer != null)
        {
          _pollingTimer.Dispose();
          _pollingTimer = null;
        }
      }
    }
}

The second important change has to do with inspecting the incoming message to determine whether it’s the first e-mail in a thread. Figure 13 shows this functionality.
Figure 13 Determining the First E-mail in a Thread

// Get either the folder or item identifier for a 
// create/delete/new mail event.
if (bocet.Item is ItemIdType)
{
  // Get the item identifier.
  ItemIdType itemId = bocet.Item as ItemIdType;
 
  //
  // Get the message using the ItemIdType.
  //
 
  // From web.config
  string ewsServiceUrl = 
    ConfigurationManager.AppSettings["EWSServiceUrl"];
 
  ExchangeService esb = 
    new ExchangeService(ExchangeVersion.Exchange2010);
  esb.Url = new Uri(ewsServiceUrl);
  // From Web service App Pool identity.
  esb.UseDefaultCredentials = true;
 
  EmailMessage message = EmailMessage.Bind(esb, new ItemId(itemId.Id));
  ConvertEmailToRequestItem(message);
}

Notice how the code leverages the fact that the Web service App Pool identity is that of the mail account, which means that Web calls to retrieve the e-mail message details can be done without having to enter any credentials.
The ConvertEmailToRequestItem method does the bulk of the work. To determine whether an e-mail is the first e-mail or part of a thread, it makes use of the ConversationIndex property of the EmailMessage instance. The length of the ConversationIndex 
byte array is 22 when it’s the first e-mail. Subsequent e-mails in a thread get further bytes added to the ConversationIndex. 
ConvertEmailToRequestItem uses this to determine whether to treat the e-mail as a new message and create a new work item for it, or as part of an existing thread, in which case it looks up the existing work item and appends the thread-specific part of the mail message to the work item revision history. Exchange exposes the part of an e-mail that’s specific to the current e-mail in the thread via the EmailMessage UniqueBody property. To get the complete thread, the Body property can be used. This is quite powerful, as it allows building the e-mail thread in the work item revision history, as shown in Figure 11.
One special case that’s worth mentioning is when an e-mail arrives that’s part of a thread but with no corresponding work item available to update. This typically happens if the thread was started before the ticketing system was put in place. In that case, a new work item is created.
In order for the Web service to determine whether an e-mail already exists as a work item, it relies on a piece of information it stores in the work item when the work item is first created: ConversationIndex. The Web service queries work items based on that value to find out whether the work item exists. The querying is performed using the TFS work item query language (WIQL), as in the following code:

private const string QUERY_BY_CONVERSATION_INDEX_WIQL =
  "SELECT [System.Id] FROM WorkItems WHERE [System.TeamProject] = '{0}'  AND
    [System.WorkItemType] = 'Support Request' AND
    [MsdnMag.SupportTicket.ConversationIndex] = '{1}' ORDER BY [System.Id] desc";

WIQL gives you an easy yet powerful way to query a work item without having to load objects and enumerate through collections.
The Web service also provides a way to easily track it in the TFS activity logs. The TFS activity logs are stored in two SQL Server tables (tbl_Command and tbl_Parameter) in the database for the team project collection. Inspecting the UserAgent column in tbl_Command lets TFS administrators figure out the source of requests.
The notification Web service customizes the user agent data in order to clearly identify it by using the following statement:

TfsConnection.ApplicationName = string.Format(
  TFS_APPLICATIONNAME_TEMPLATE, WindowsIdentity.GetCurrent().Name);

In this particular case, the user agent will look something like “MsdnMagSubscribeSvc – Contoso\JDoe.”
Another potentially useful feature of ConvertEmailToRequestItem is its ability to filter e-mails according to a certain prefix in the subject line, as in the following code:

// First check if prefix-based filtering is turned on, and if so, 
// if the e-mail subject line matches the defined prefix.
string subjectPrefix = 
  ConfigurationManager.AppSettings["SubjectPrefix"];
if (!string.IsNullOrWhiteSpace(subjectPrefix))
{
  if (!title.StartsWith(subjectPrefix, 
    StringComparison.InvariantCultureIgnoreCase))
  {
    WriteEventToLog(
      string.Format(SUBJECT_DOES_NOT_MATCH_PREFIX_TEMPLATE,
      subjectPrefix, title));
 
    return;
  }
}

You can use this feature to restrict the service’s functionality to only certain e-mails; for example, to code review e-mails where the prefix can be defined as “Code Review.”

Other Use Cases: Code Reviews

The use case presented here is a support ticket. However, the flexibility of the approach presented in this article makes it easy to apply the same techniques to other use cases, such as tracking code reviews. The process flow for the code review use case is depicted in Figure 14.

Figure 14 Process Flow for the Code Review Work Item
Development organizations tend to conduct code reviews via e-mail. There have been many attempts to integrate code reviews into TFS by creating code review work items and building add-ins to allow managing the code review process from within Visual Studio. However, the same technique employed for support tickets can provide an easy way to integrate code review e-mail threads into the TFS work item tracking system. The following steps outline a suggested process for using the notifications infrastructure with code reviews:

• Start by creating a Code Review work item similar to the Support Request work item.
• Set up a watcher account in a DL to monitor e-mails sent to the DL.
• Use the SubjectPrefix feature presented earlier to define a prefix that distinguishes e-mails as code review e-mails. Code review requests sent via e-mail often have the subject line follow this pattern: “Code Review: My-Shelveset-Name.”

As shown in Figure 14, associating the actual check-in of the shelveset contents with the work item provides traceability into the lifetime of the code from when the code was done, when it was sent for code review, when it was approved for check-in and, finally, to when it was checked in. This association is a powerful feature of TFS that provides great visibility into any code that gets checked in via source control. It’s an especially useful asset for organizations that require traceability for audit reasons.

What Next

The key goal of this article was to demonstrate one of the many possibilities for using TFS and Exchange together to increase both productivity and efficiency. One of the great things about work items, especially in TFS 2010, is how they’re integrated inside TFS. Work items can be linked to changesets. They can represent and track test plans. They can be easily reported on, using Excel or SSRS, and they can also be synchronized with Microsoft Project.
Armed with the use case and techniques presented in this article, you should be able to leverage the notifications Web service and the work item customizations in many other scenarios that are particular to your own environment.    

HTML 5

HTML5

Building Apps with HTML5: What You Need to Know

Brandon Satrom

HTML5 is here, and the Web will never be the same.

You’ve no doubt heard that before, or something like it. I’d guess that when you did, you got excited, rolled your eyes, or mouthed the word “why?” and furrowed your brow a bit. Perhaps your reaction was a mix of all three.

I wouldn’t blame you for any of these. HTML5 is exciting, and it does have the potential to change the Web as we know it, but it also gets blown out of proportion. What’s more, its true meaning can be elusive. I’ve experienced each of those reactions myself while building applications with HTML5. It’s a broad topic, so it’s difficult to wrap your head around HTML5, much less know where to begin with this exciting new set of technologies.

This is the first article in a series for MSDN Magazine, and the goal is to give you a complete picture of why the first sentence in this article is true—and important. Over the next several months, I want to help you understand what HTML5 means to you—both as a Web developer and as a developer who uses Microsoft tools and technologies. I hope to simplify some of the complexity around HTML5 for you, and demystify much of the hype. I’ll also introduce some HTML5 features that are available today, as well as some exciting technologies that, though a bit further out, are worth paying attention to. Finally, I’ll leave you with some tips that will help you adopt HTML5 technologies now, while you continue to 
provide great experiences to users with older browsers.

If you’re excited about HTML5, I want to help you turn that excitement into ideas you can put into practice immediately. If you’re skeptical, I want to help you understand just why HTML5 is important. And if you’re just confused about what HTML5 even means, fear not: that’s our first stop in this series.

What Is HTML5?

You might have discovered by now that HTML5 means different things to different people. To some, it just means new tags like <header> and <footer> and a handful of new attributes available in markup. To others, it means everything that’s new and interesting on the Web, including technologies implemented in just a single browser or other specifications not officially part of HTML5. To be sure, understanding the real meaning of HTML5 is often the first roadblock many of us face.

And, honestly, there’s some justification for the number of varying definitions. HTML5 is huge! Formally defined by an international standards body known as the World Wide Web Consortium (W3C), HTML5 consists of more than 100 specifications that relate to the next generation of Web technologies. By putting all 100-plus of these specifications under the moniker HTML5, you could argue that the W3C oversimplified things. And while it’s hard to take something as broad as HTML5 and define it in an unambiguous way, I believe that the W3C was trying to address the scope of what’s changing on the Web by introducing HTML5 as a unifying concept for that change.

In fact, HTML5 is an umbrella term describing a set of HTML, CSS and JavaScript specifications designed to enable developers to build the next generation of Web sites and applications. What’s notable in that definition is its three parts: HTML, CSS and JavaScript. They define how developers use improved markup, richer style capabilities and new JavaScript APIs to make the most of new Web development features. Simply put, HTML5 = HTML + CSS + JavaScript.

And that’s it. HTML5 is about changes to HTML, CSS and JavaScript. Rather than worrying about all 100-plus specifications, those three terms describe the breadth and scope of HTML5. Still think that’s a bit simplistic? It may be, but as you’ll soon see, a comprehensive definition of HTML5 doesn’t matter as much as the technologies you choose as worthy of your time and effort to adopt.

With a definition in hand, let’s spend a few moments talking about where Microsoft fits into the HTML5 space.

HTML5 and Internet Explorer

As I mentioned, the set of specifications that make up HTML5 are stewarded by the W3C. The W3C consists of staff, organizations and individuals invested in helping to drive and define the future of the Web. The WC3 is a consensus-based organization, and typically operates by forming committees (called working groups) to divide up chunks of work on related specifications. Specifications can be proposed by any member, and all specifications owned by the W3C—more specifications than those that fall under the HTML5 umbrella—move through a five-stage process from first draft to official recommendation.

Microsoft is a member of the W3C and plays a very active role in the specification process for many HTML5 standards and working groups. Just like all of the major browser vendors, Microsoft is heavily invested in HTML5 and is working with the W3C and other vendors to ensure that developers can count on HTML5 technologies being reliably implemented in an interoperable way on all major browsers.

In the context of Microsoft the browser vendor, the approach is fourfold:

1. Deliver the best site-ready HTML5 today via Internet Explorer 9.
2. Expose upcoming features to developers via Internet Explorer Platform Previews.
3. Invest in interoperability through tests submitted to the W3C.
4. Prototype unstable standards via HTML5 labs.

“Site-Ready HTML5” is the term Microsoft uses to describe HTML5 technologies that you can use today because they have broad support across all major browsers. Technologies like the new HTML tags, Canvas, Scalable Vector Graphics, Audio and Video, Geolocation, Web Storage and many new CSS3 modules all fall into this space, and they’re implemented in Internet Explorer 9, as well as the other mainstream browsers. We’ll spend a fair amount of time in this series discussing these technologies, as well as how you can adopt them today.

Beyond what’s available at present, Microsoft is using public Platform Previews to inform developers of what’s coming in the next version of the browser, as well as to gather feedback. For Internet Explorer 9, Microsoft released Platform Previews every six to eight weeks, each time announcing new HTML5 enhancements, features and performance improvements for developers to try out and evaluate. Internet Explorer 9 was released in March and as of early July, Microsoft has released two Platform Previews for Internet Explorer 10, signaling that Microsoft is continuing a regular release cadence for Internet Explorer previews. As a developer, you’ll want to take advantage of the latest previews to learn, test and influence how the browsers evolve. You can download the latest Internet Explorer Platform Preview at IETestDrive.com.

To ensure that HTML5 works consistently across all browsers, Microsoft has invested heavily in interoperability, creating and submitting the single largest suite of test cases related to HTML5 to the W3C. For the first time, this suite of test cases will be used by the W3C as the authoritative source of HTML5 “readiness” in each browser. The end result for you and me as developers is that we can adopt and implement HTML5 technologies once, and trust that they’ll work consistently across all browsers. For more information on Microsoft’s work around interoperability, go to bit.ly/dxB12S.

While some HTML5 technologies already exist in Internet Explorer 9, and others are being announced for Internet Explorer 10 via Internet Explorer Platform Previews, some popular and newsworthy specifications need a bit more work by the W3C and the browser vendors before they’ll be ready to implement in our applications. One such example is Web Sockets, an exciting specification that lets developers open bidirectional communication channels with back-end servers, thus enabling a level of “real-time” connectivity not previously available in Web applications. As a developer, you can no doubt imagine countless uses for Web Sockets in the applications you’re building right now. But the Web Sockets specification is still changing at a rapid pace, with key aspects still in flux and being discussed within the W3C. Given that situation, it would be difficult to provide this feature consistently and reliably across all browsers today.

For unstable or evolving specifications like Web Sockets (which we’ll cover in depth in a future article), Microsoft created HTML5 Labs, a site for developers to experiment with draft implementations of these technologies. The site provides prototypes you can download and try locally, as well as hosted demos for some specs. The goal is to give you a place to try these specs out for yourself, and for you to give both Microsoft and the W3C feedback on these specs as they stabilize and near implementation in browsers. For more information on HTML5 Labs, go to html5labs.com.

HTML5 and Microsoft Developer Tools

Beyond Microsoft’s involvement with the W3C and the HTML5 technologies supported in the browser, there’s another dimension to Microsoft’s approach to HTML5 that’s important for developers: its approach to HTML5 tooling.

In early 2011, Microsoft updated two of its development tools with service packs: Visual Studio 2010 and Expression Web 4. The service packs for both of these tools provided an HTML5 document type for validation, as well as IntelliSense for new HTML5 tags and attributes. If you’re using Visual Studio 2010 SP1, you can enable the HTML5 Schema by clicking Tools | Options | Text Editor | HTML | Validation, and then selecting the HTML5 option in the Target drop-down list, as shown in Figure 1. You can also set HTML5 as the default schema from the HTML Source Editing Toolbar in any HTML file, as shown in Figure 2.

Figure 1 Enabling the HTML5 Schema via the Options Dialog

Figure 2 Setting the HTML5 Schema on the HTML Source Editing Toolbar

Once your default schema is set, you’ll gain IntelliSense support in Visual Studio for the 28 new semantic tags in HTML, as well as new tag-specific and global attributes, as show in Figure 3.

Figure 3 HTML5 IntelliSense in Visual Studio 2010 SP1

Microsoft further updated its HTML5 support with its release of the Web Standards Update for Microsoft Visual Studio 2010 SP1 in June 2011. This extension, which works with all editions of Visual Studio 2010, adds further HTML5 IntelliSense and validation to Visual Studio, includes JavaScript IntelliSense for new browser capabilities like Geolocation and DOM Storage, and provides comprehensive CSS3 IntelliSense and validation. You can download this extension, which will be regularly updated to provide enhanced tooling for HTML5 development, from bit.ly/m7OB13.

For Expression Web 4 SP1, setting the HTML5 schema under Tools | Page Options offers the same IntelliSense, and the tool also provides CSS3 IntelliSense for several draft CSS3 modules like border-radius, box-shadow, transform and the like.

If you’re using WebMatrix (see web.ms/WebMatrix), you may have noticed that all new .html, .cshtml or .vbhtml documents you create contain default markup similar to what’s shown in Figure 4. As I’ll discuss in the next article in this series, this is a basic, valid HTML5 document. Most notably, the doctype and meta charset tags have lost a lot of cruft. Using this simple doctype triggers HTML5 mode across all modern browsers, and WebMatrix makes it easier for you by providing an HTML5 document by default.

Figure 4 A Default HTML Document in WebMatrix

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <title></title>
  </head>
  <body></body>
</html>

If that’s not enough new HTML5 tooling for you—all since January 2011, by the way—ASP.NET MVC recently got in on the fun with the ASP.NET MVC 3 Tools Update announced at MIX11 in April. Along with a number of other great new tooling features, the ASP.NET MVC 3 Tools Update provides the option to use the HTML5 doctype for new projects—and ships Modernizr 1.7 in the Scripts folder of new applications. Modernizr is a JavaScript library that greatly eases HTML5 development; I’ll discuss it in depth in a future article.

The takeaway here is that even though HTML5 is just emerging in our browsers, official tool support is quickly being added, and Microsoft is even adding support for libraries (like Modernizr) from the community. You can target HTML5 with some help from Microsoft tools today, and expect that that HTML5 support will continue to grow and improve over time.

‘Adopting’ HTML5 in Your Applications

By now, you should realize that HTML5 isn’t a single entity that you can adopt or migrate to in one fell swoop. Adopting HTML5, rather than being a wholesale choice, is about making a technology-by-technology evaluation and determining which technologies are right for your application. For each HTML5 technology you evaluate, look at (at least) the following factors when deciding whether that technology is ready for you to adopt:

1. How widely implemented across all major browsers is the technology?
2. How would you adopt this technology and “polyfill” support for browsers that don’t support a given feature?

The first factor is the most important, and when combined with an understanding of the browsers commonly used by visitors to your site, should give you a clear picture of which subset of the 100-plus specifications is worth evaluating further. That subset should consist of a set of stable specifications you can reliably adopt today for your users.

However, even with that stable set of HTML5 technologies, you shouldn’t ignore your users who haven’t moved to a newer browser. If you’re heavily involved in the day-to-day development for your site, you no doubt have some rough idea of the percentages of users visiting your site with a given browser. For most of us, it would be easy to look at the percentage of users visiting with an older browser and come to the conclusion that adopting any HTML5 technologies would negatively impact those users. Luckily there’s “polyfilling” to save us from waiting until some foggy date in the future to adopt HTML5.

Paul Irish (a developer on the jQuery and Modernizr projects) defines a polyfill as “… a shim that mimics a future API, providing fallback functionality to older browsers.” A polyfill is like spackle for your Web sites; it’s a way to determine if a given HTML5 feature is available to the user currently browsing your site, and to provide either a shim that “fills in” that support or a course of graceful degradation that enables your site to still function fully.

The most popular library associated with polyfilling is Modernizr, the JavaScript library I mentioned earlier. Modernizr provides some basic polyfills for semantic markup, feature detection for major HTML5 technologies and support for conditional CSS based on supported features. As noted, Modernizr will be the subject of an upcoming article; it will also feature prominently (along with many other polyfilling libraries) throughout this series. To learn more, download Modernizr at modernizr.com. 

When it comes to choosing which technologies to adopt, your final list may be a combination of widely supported specifications and other specifications for which you’ll have to polyfill support for certain browsers. Only you will know the exact makeup of that list based on your current needs and context.

In the coming months, I’ll discuss several notable specifications, from Geolocation and Forms and Canvas, to Web Workers, Web Sockets and IndexedDB. Some of these are widely supported and “site-ready,” and some, like Web Sockets, are too groundbreaking to ignore, regardless of where they stand today. With each specification, I’ll discuss current and known future support, some basics about how you can implement the specification’s features on your sites, and how to polyfill support for browsers that don’t support a given feature.

If you want to dig more into HTML5 today, I suggest you pick up a couple of books on the subject. In particular, I recommend “Introducing HTML5” (New Riders, 2010) by Bruce Lawson and Remy Sharp and “HTML5 Up and Running” (O’Reilly Media, 2010) by Mark Pilgrim. Also, be sure to visit W3C.org for up-to-date information on all specifications, as well as BeautyoftheWeb.com and IETestDrive.com to download Internet Explorer 9 and the Internet Explorer 10 Platform Preview, respectively, and learn more about the great HTML5 experiences Microsoft is delivering through the browser.

Above all else, start adopting HTML5 today. The Web won’t ever be the same, really, and you can be part of the catalyst by building the next great Web applications using HTML5.

Ubunutu 11.04

Ubuntu has tried to be the friendly face of Linux since it launched seven years ago. Maker Canonical has steered the operating system (OS) toward becoming one you can use on a daily basis, without recourse to typing text commands into a command-line console.

RELATED ARTICLES

• Ubuntu 10.10 Maverick Meerkat review
• Ubuntu 10.04 LTS Lucid Lynx review
• Ubuntu Netbook Edition review
• Linux Mint 9 review
• Ubuntu Netbook Edition review

In our tests with a few laptops – always the most difficult PCs to support because of driver issues – Ubuntu 11.04 has largely succeeded. But Canonical has set itself another goal: to create a modern interface to control the existing functions of this popular Linux OS.

GUI goes Unity

Graphical user interfaces (GUIs) were first developed in the 1970s, but the paradigm of a desktop with drag-and-drop files and folders on the PC can be traced back to the Macintosh of 1984.

Back then, Microsoft tried to copy Apple's windows-based interface; it called its version ‘Windows’. When the GUI came to Linux in the early 90s it was based on the X Windows system of UNIX, before evolving into something closer to the Windows look and feel.

Two popular interface options have been available to desktop Linux in recent times. Most distros are based on either KDE, which imitates the Windows Start Menu and Taskbar, and the more Mac-like GNOME, which is often seen with a top menu bar.

Canonical has traditionally leaned toward the GNOME interface in Ubuntu 11.04 (while still offering a KDE-based Kubuntu build), but was less satisfied with the development of GNOME 3. It went on to develop its own GUI, based on one first pioneered in Ubuntu for netbooks.

In the process, it’s taken Ubuntu 11.04 another step closer to the appearance and layout of Apple's Mac OS X.

Install stage

The principal version of Ubuntu 11.04 is simply named Desktop 32-bit, with a 64-bit version also available. Both are free to download from ubuntu.com, and weigh in at 718MB and 732MB respectively.

We thought we’d chance our arm first with the 64-bit version. All went smoothly on a Lenovo ThinkPad Edge 11 laptop, until we tried to install Skype. Canonical offers plenty of software in its own Software Center, although it hosts only the 32-bit version of Skype.

Following an easy installation of the OS, the system reboots into Ubuntu’s new Unityenvironment. In place of the usual top menu with drop-down links to Applications, Places and Preferences, you’ll find a plain top bar with icon shortcuts to Wi-Fi and Bluetooth settings, speaker volume, Evolution mail, the current time, and the shut down/log out options.

At the top left of the screen is the Ubuntu logo. Clicking this brings up a full-screen search app, with oversized icons for common tasks such as Browse the Web, View Photos and Check Email. You can also invoke this screen with a dab of the Super key (usually the one with the Windows logo).

Ubuntu 11.04: The Dash is a quick way to find files or installed apps

But the most arresting sight from the Ubuntu 11.04 desktop is the Launcher, which is attached to the left edge of the screen. In common with OS X‘s Dock, it’s an icon-based app launcher and switcher, and populated with useful shortcuts. Unlike Apple's Dock, though, there doesn't appear to be any way to move it to a different screen edge other than the left side.

If you want to keep an open application here for ready access, you simply right-click its icon and select the ‘Keep in Launcher’ icon.