James Schaffer - All Things .NET

Undoing WiX Custom Actions During Uninstall

James Schaffer — Sun, 28 Oct 2012 17:13:00 GMT

In my previous post about creating Custom Actions with WiX, I showed how to create a custom action project and invoke the custom action from a setup project. In my particular case, the custom action was making several edits to an existing web.config file to incorporate a new HTTP module that was being installed. Since these edits to the web.config are not automatically removed during uninstall of the HTTP module, I need a compensating custom action to perform this task.

Since I already have a custom action project and the associated CustomActions class from the previous post, the easiest thing to do is to incorporate the custom action for the uninstall into the same class (Remember, a custom action is represented as a static method annotated with the CustomAction attribute that ultimately gets generated into a DLL entry point that is callable by the MSI engine). So to add the new custom action, I simply need to add another method to my CustomActions class. The original custom action to make the web.config edits and the new custom action to remove the edits on uninstall are shown below.

public class CustomActions

{

    [CustomAction]

    public static ActionResult ConfigurEwsFilter(Session session)

    {

        try

        {

            session.Log("Begin Configure EWS Filter Custom Action");

  

            // TODO: Make changes to config file

  

            session.Log("End Configure EWS Filter Custom Action");

        }

        catch (Exception ex)

        {

            session.Log("ERROR in custom action ConfigureEwsFilter {0}", 

                        ex.ToString());

            return ActionResult.Failure;

        }

  

        return ActionResult.Success;

    }

  

    [CustomAction]

    public static ActionResult RemoveEwsFilterConfig(Session session)

    {

        try

        {

            session.Log("Begin Remove EWS Filter Configuration Custom Action");

  

            // TODO: Remove changes to config file

  

            session.Log("End Remove EWS Filter Configuration Custom Action");

        }

        catch (Exception ex)

        {

            session.Log("ERROR in custom action RemoveEwsFilterConfig {0}", 

                        ex.ToString());

            return ActionResult.Failure;

        }

  

        return ActionResult.Success;

    }

}

As with the original custom action, I need a reference to the new custom action in the *.wxs file. The original Binary element and CustomAction element are shown along with the new CustomAction element (lines 8-12) to remove the configuration changes.

"EwsAction.CA.dll" 

        src="..\EwsAction\bin\$(var.Configuration)\EwsAction.CA.dll" />

"ConfigurEwsFilter" 

              Return="check" 

              Execute="immediate" 

              BinaryKey="EwsAction.CA.dll" 

              DllEntry="ConfigurEwsFilter" />

"RemoveEwsFilterConfig" 

              Return="check" 

              Execute="immediate" 

              BinaryKey="EwsAction.CA.dll" 

              DllEntry="RemoveEwsFilterConfig" />

The only differences between the two CustomAction elements are the Id and DllEntry attributes, where the DllEntry attribute indicates the CustomAction method to invoke.

Up to this point, the process of adding the compensating CustomAction is exactly the same as adding the original CustomAction. However, I only want the new custom action to run during uninstall of the HTTP module. I can control that with a condition on the custom action’s entry in the InstallExecuteSequence.



  "AssignConfigFile" After="CostFinalize" />

  "ConfigurEwsFilter" Before="InstallFinalize">

    NOT Installed

  

  "RemoveEwsFilterConfig" Before="InstallFinalize">

    Installed AND NOT UPGRADINGPRODUCTCODE

  



The entry for the new custom action is shown on lines 6-8 above. Line 7 provides the condition when the custom action should be run. In this case it references the Installed and UPGRADINGPRODUCTCODE properties, indicating that the product should already be installed and an upgrade to the product is not being performed (i.e. during uninstall).

You’ll also notice the condition NOT Installed added to the original custom action performing the configuration edits. That’s because I want it to only run during install, not during uninstall, otherwise I’ll get my edits added back into the web.config file.

Creating WiX Custom Actions in C# and Passing Parameters

James Schaffer — Tue, 23 Oct 2012 18:29:00 GMT

I’m currently working on a project where I’m creating a custom HTTP module for a customer. The module is to be used with an existing commercial product. Since the custom HTTP module is working with an existing product, the process of installing it would need to make significant changes to the web.config file of the existing product, plus be able to remove those changes during a subsequent uninstall.

I hadn’t worked with Windows Installer XML (WiX) projects before so this was a perfect opportunity to get up to speed.

Creating a Setup Project and C# Custom Action Project

Once you install the WiX toolset you’ll be able to create a new Setup Project from Visual Studio as shown below.

After creating the setup project you’ll have a Product.wxs file that defines your setup. I won’t go into details about the general process of authoring this file as this is covered in detail in the online WiX tutorial. Once we’ve created our setup project, we’ll need to add a C# Custom Action Project to our solution (you can see this project template option in the above screenshot as well). Within the custom action project you’ll have a new CustomActions class that looks like the following:

public class CustomActions

{

    [CustomAction]

    public static ActionResult CustomAction1(Session session)

    {

        session.Log("Begin CustomAction1");

  

        return ActionResult.Success;

    }

}

This is where you’ll write the code that you want to be executed when the custom action method is called. Any method that you want to expose to the setup project must be a public static method that is annotated with the CustomAction attribute and has the following method signature.

 1: public static ActionResult ActionMethod(Session session)

The Session parameter passed to the method is the object that controls the installation process. Among other things, the Session object allows you to write output to the installation log file and gives you access to global properties for passing data (we’ll use this later).

So in my particular instance I needed to write a custom action that would perform various updates to the existing product’s web.config file as part of the install. WiX provides what’s referred to as a Standard Custom Action library for manipulating XML files as part of an installation. However, after reviewing the on-line content and some examples this proved to be far too cumbersome for my needs.

So my custom action method ultimately looked similar to the following:

[CustomAction]

public static ActionResult ConfigurEwsFilter(Session session)

{

    try

    {

        session.Log("Begin Configure EWS Filter Custom Action");

  

        // TODO: Make changes to config file

  

        session.Log("End Configure EWS Filter Custom Action");

    }

    catch (Exception ex)

    {

        session.Log("ERROR in custom action ConfigureEwsFilter {0}", 

                    ex.ToString());

        return ActionResult.Failure;

    }

  

    return ActionResult.Success;

}

The code snippet shows what could be argued as a standard boilerplate approach for custom actions. Logging the entry and exit of the custom action, performing the configuration step necessary and handling an unhandled exceptions to make sure they are logged to the output correctly.

Compiling the custom action project will generate two DLLs. The additional DLL, $(TargetName).CA.dll, provides a format that is callable from the MSI engine. Therefore, this is the DLL that we want to reference from the *.wxs file in the setup project. To do that, we add a Binary element within the Product element that was generated in the *.wxs when the setup project was created.

"*" Name="SetupProject1" 

         Language="1033" Version="1.0.0.0" 

         Manufacturer="" 

         UpgradeCode="d206ba77-ddbe-41a3-893f-324f55242bef">

  

  "EwsAction.CA.dll"

          src="..\EwsAction\bin\$(var.Configuration)\EwsAction.CA.dll" />

  



In the snippet above, I’m referencing the *.CA.dll relative to the setup project (which is in the same solution). I’m also indicating that I want to base the version of the *.CA.dll on the current build configuration of the setup project using the $(var.Configuration) syntax. That way, if I build a debug version of the setup project I get a debug version of the custom action and a similar result for a release build.

Along with the Binary element, we’ll also need to add a CustomAction element to reference the Binary element’s Id and indicate the entry point that we want to execute. This should look similar to the following:

"ConfigurEwsFilter" 

              Return="check" 

              Execute="immediate" 

              BinaryKey="EwsAction.CA.dll" 

              DllEntry="ConfigurEwsFilter" />

In the above example, notice that the BinaryKey attribute matches the Id attribute of the Binary element we previously added. Also note that the DllEntry attribute references the method name that was decorated with the CustomAction attribute in the C# code.

Adding the Binary and CustomAction elements by themselves however still does not result in the custom action actually being executed. To include the custom action in the installation process we need to add an entry to the InstallExecuteSequence as shown.



  "ConfigurEwsFilter" Before="InstallFinalize"  />



Note here that we’re referencing the Id attribute of the CustomAction element while indicating that we want this action to execute prior to the standard InstallFinalize action of the installation.

Passing Parameters

The last issue we need to resolve is retrieving the location of the existing product’s web.config file and passing it to the custom action. In my case I can use a standard RegistrySearch action to read the install path of the existing product from the registry. The web.config should exist within a well known folder path within the install path. Since the RegistrySearch action will store the root install path to a property, I need a separate CustomAction to build out the full path to the web.config file. As a consequence, I’ll also need another entry in the InstallExecuteSequence to execute this new custom action. These 3 additions are shown below.

"PRODUCTINSTALLFOLDER">

  'ProductInstallDir' 

                  Type='raw' 

                  Root='HKLM' 

                  Key='SOFTWARE\Manufacturer\ExistingProduct\Setup' 

                  Name='MsiInstallPath' 

                  Win64='yes'/>



'AssignConfigFile' 

              Property='CONFIGFILE' 

              Value='[PRODUCTINSTALLFOLDER]pathtoconfigfile\web.config' />



  "AssignConfigFile" After="CostFinalize" />

  "ConfigurEwsFilter" Before="InstallFinalize"  />



The result of the above is that the web.config file’s path should now be in the global property named CONFIGFILE. With the Session object discussed earlier, I can now access this path from within my custom action code using syntax similar to the following:

session.Log("Session value for CONFIGFILE = '{0}'", 

            session["CONFIGFILE"]);

Now within my custom action method I can open the web.config file and make the necessary edits for my custom HTTP module.

Since the web.config edits are performed by a custom action, they won’t automatically be removed during an uninstall. In my next blog post I’ll discuss creating a separate custom action to remove the web.config edits and have it run only during the uninstall of the module.

Upgrading Team Projects After Migrating From TFS 2008 to TFS 2012

James Schaffer — Wed, 17 Oct 2012 17:43:00 GMT

UPDATE: The content of this post was originally a gap in the on-line MSDN documentation which has since been filled. The official MSDN documentation can now be found here.

I recently worked with a customer that was upgrading from Team Foundation Server (TFS) 2008 to TFS 2012. After the upgrade, all of the existing Team Projects were available within the new project collection as expected. However, one thing the upgrade process doesn't do for you is upgrade the team projects themselves. That means that the Team Projects were still operating off of the MSF for Agile Software Development 4.2 process template rather than the new 6.0 version of the same template. Since the customer wanted to take advantage of all the new functionality and work item types added since 2008, we needed to upgrade each of their existing Team Projects to add these features.

While there is documentation on TechNet for Adding Features Using a Manual Update Process, this focuses on upgrading from TFS 2010 to TFS 2012. That didn't quite fit the bill for our scenario since there were a great deal of changes between TFS 2008 and TFS 2010 that weren’t accounted for. I also found documentation on MSDN regarding Enabling Interfacing with Microsoft Test Manager for Upgraded Team Projects. Since the customer was interested in using MTM, that sounded promising, but this guidance focused on an upgrade from TFS 2008 to TFS 2010. So I had information for upgrading from 2008 to 2010 and from 2010 to 2012, but nothing to go directly from 2008 to 2012. So we took the approach of combining the two separate pieces of guidance into one concise approach as outlined below.

First we need to export the MSF for Agile Software Development 6.0 Process Template as parts of this will be used in subsequent steps.
Using witadmin.exe, import the following work item type definitions from the 6.0 template into each of your team projects that need upgraded.
1. UserStory
2. TestCase- This required slight modification to the following system field names to remove spaces that were added since 2008 but that still exist based on the 2008 template.
  1. External Link Count --> ExternalLinkCount
  2. Related Link Count --> RelatedLinkCount
  3. HyperLink Count --> HyperLinkCount
  4. Attached File Count --> AttachedFilecount
  5. Area ID --> AreaID
3. SharedStep- This required slight modification to the following system field names to remove spaces that were added since 2008 but that still exist based on the 2008 template
  1. Iteration ID --> IterationID
  2. External Link count --> ExternalLinkCount
  3. Related Link Count --> RelatedLinkCount
  4. HyperLink Count --> HyperLinkCount
  5. Attached File Count --> AttachedFilecount
  6. Area ID --> AreaID
4. Task - Required because there are necessary fields (StartWork, StopWork) missing in the 4.2 version
Using witadmin.exe, import the following Linked Types - NOTE: This is a one time operation for the Team Project Collection and does not need to be run for each Team Project.
1. TestedBy
2. SharedStep
Using witadmin.exe, import categories for each Team Project being upgraded.
1. We first had to comment out references to all new 6.0 WITs (e.g. Code Review Request/Response) since they do not yet exist. These will be updated during the Configure operation in Step #5.
Run Configure from the Admin site for each Team Project
1. Click on the Configure button and the Team Project should be upgraded to the new process template.
Finally, we need to copy the new Work Item Queries to each Team Project.

Create a test project based on the MSF for Agile Software Development 6.0 Process Template to copy the Work Item Queries from.
Use WiqAdmin to copy updated queries from the test project to the migrated projects

NOTE: WiqAdmin currently only supports Team Explorer 2008/2010. The 2010 version must be run from a machine with TE 2010 installed to bind to the correct assemblies.
Syntax for the copy operation should be similar to the following to copy all queries recursively without overwriting any existing queries:
1. wiqadmin copy /collectionFrom: /collectionTo:
  /projectFrom: /projectTo:
  /ondup:S /folder:"Shared Queries" /recursive
2. Replace the collectionUrl and project name parameters above for your environment

Since we had to perform the above operation for multiple team projects (upwards of 50) we tried to automate the process as much as possible to creating some simple command line files to accommodate this.

NOTE: The above outline is specific to the MSF for Agile Software Development process template but should be similar for other process templates.

The command files and the updated process template files required for the steps listed above are included in the zip file below for reference.

Upgrade Scripts and Modified WIT Files

A Re-Usable Button Control for TFS Work Item Definitions

James Schaffer — Fri, 04 May 2012 11:31:00 GMT

There’s plenty of documentation available on MSDN and from other sources that discusses how to create custom controls to be used by TFS Work Item Type (WIT) definitions. I was working with a customer recently and I needed to customize a work item to show a button that would launch a custom user interface. The custom UI would create an associated Code Review work item and a shelveset from the user’s current pending changes. I thought there might be an existing implementation of a custom WIT button control but alas, after scouring the web and other resources I couldn’t find any. So I started down the path of writing my own.

As mentioned above there is already a wealth of documentation detailing how to create custom controls, so I won’t get into most of those details. Instead I’ll focus on the code for the button control and how you can re-use the control to add similar functionality to your work item types.

The implementation turns out to be pretty straight forward. I create a new control library and add a new control that derives from UserControl and implements the IWorkItemControl interface. The IWorkItemControl interface implementation is shown below.

protected IServiceProvider _serviceProvider;

void IWorkItemControl.SetSite(IServiceProvider serviceProvider)

{

    _serviceProvider = serviceProvider;

}

 

protected WorkItem _workItem;

object IWorkItemControl.WorkItemDatasource

{

    get { return _workItem; }

    set { _workItem = (WorkItem)value; }

}

 

public event EventHandler AfterUpdateDatasource;

 

public event EventHandler BeforeUpdateDatasource;

 

public void Clear()

{

}

 

public void FlushToDatasource()

{

}

 

public void InvalidateDatasource()

{

}

 

public System.Collections.Specialized.StringDictionary Properties

{

    get { return _properties; }

    set { _properties = value; }

}

 

public bool ReadOnly

{

    get { return _readonly; }

    set { _readonly = value; }

}

 

public string WorkItemFieldName

{

    get { return _fieldName; }

    set { _fieldName = value; }

}

With the interface implemented, I then simply add a new button control to the custom control with some default settings as shown.

private Button _button;

  

public WitButton()

{

    InitializeComponent();

    InitControl();

}

  

private void InitControl()

{

    if (_button != null)

        return;

  

    _button = new Button();

    _button.Text = "Default Text";

    _button.Width = 125;

    _button.Top = 10;

    _button.Click += new EventHandler(_button_Click);

  

    base.Controls.Clear();

    base.Controls.Add(_button);

}

Finally, I expose the Text and Width properties of the internal button control so that they can be set by any derived controls. I also expose an event that is fired when the button is clicked.

public string ButtonText

{

    get { return _button.Text; }

    set { _button.Text = value; }

}

  

public int ButtonWidth

{

    get { return _button.Width; }

    set { _button.Width = value; }

}

  

public delegate void ButtonClickHandler(object sender, EventArgs args);

public event ButtonClickHandler ButtonClick;

  

void _button_Click(object sender, EventArgs e)

{

    if (ButtonClick != null)

        ButtonClick(sender, e);

}

That’s it for the base control, which by itself won’t do much, so there is no *.wicc file necessary at this point.

Now I need to create a derived control that will set the base control’s button text and width accordingly and handle the ButtonClick event to actually perform some work when the user clicks the button. A simple example of this is shown in the next snippet.

public partial class MyButton : WitButton

{

    public MyButton()

    {

        InitializeComponent();

        this.ButtonText = "Do Something";

        this.ButtonWidth = 150;

        this.ButtonClick += new ButtonClickHandler(MyButton_ButtonClick);

    }

 

    void MyButton_ButtonClick(object sender, EventArgs args)

    {

        MessageBox.Show("Button was clicked");

    }

}

With the code in place I create a *.wicc file named MyCustomWitButton and deploy it along with the binaries for my custom control and the base control to Environment.SpecialFolder.CommonApplicationData\Microsoft\Team Foundation\Work Item Tracking\Custom Controls\10.0\ (there are multiple folders which are probed to locate custom WIT controls as explained here). Now I can add the derived button to my Bug work item type definition (no field name or label is required for the button control).

After saving the work item type definition I can now create a new Bug within the team project and I should get the following result.

Finally I can get to the original problem I was trying to solve, which was using a button from the work item form to launch a custom UI to create an associated Code Review work item and shelveset. I created a WPF application and launch it on the ButtonClick event. I am also leveraging the protected _workitem and _serviceProvider members from the base control to access the associated Bug work item and the TFS work item DocumentService respectively. The results are shown below.

I’ve created a project on CodePlex where you can download the source for the base control and a sample derived control.

Windows Server AppFabric Cache – Referencing the Correct Assemblies

James Schaffer — Sat, 28 Jan 2012 14:03:00 GMT

I was recently putting together a distributed application cache proof of concept for a customer that leveraged the Windows Server AppFabric Cache. In order to take advantage of this functionality, my project needed to reference the following assemblies:

Microsoft.ApplicationServer.Caching.Client
Microsoft.ApplicationServer.Caching.Core

Normally this would be easy enough. Assuming these are system level assemblies I’d just reference them from the GAC - and sure enough I was able to find them there. Unfortunately, that was a mistake. It turns out that I also had the Windows Azure SDK installed on my development machine. Windows Azure also supports the AppFabric Cache, but with a different version of these same named assemblies which are installed in the GAC. So when I ran my code and attempted to create my DataCacheFactory, I ended up with the following exception stack:

{"'The invocation of the constructor on type 'SampleCache.MainWindow' that matches the specified binding constraints threw an exception.' Line number '3' and line position '9'."}

{"The type initializer for 'Microsoft.ApplicationServer.Caching.DataCacheFactoryConfiguration' threw an exception."}

{"[A]Microsoft.ApplicationServer.Caching.DataCacheClientSection cannot be cast to [B]Microsoft.ApplicationServer.Caching.DataCacheClientSection. Type A originates from 'Microsoft.ApplicationServer.Caching.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' in the context 'Default' at location 'C:\\Windows\\assembly\\GAC_MSIL\\Microsoft.ApplicationServer.Caching.Core\\1.0.0.0__31bf3856ad364e35\\Microsoft.ApplicationServer.Caching.Core.dll'. Type B originates from 'Microsoft.ApplicationServer.Caching.Core, Version=101.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' in the context 'Default' at location 'C:\\Users\\jschaffe\\Documents\\Visual Studio 2010\\Projects\\AppFabric\\Caching\\SampleCache\\SampleCache\\bin\\Debug\\Microsoft.ApplicationServer.Caching.Core.dll'."}

The final exception in the stack indicates the problem.

{"[A]Microsoft.ApplicationServer.Caching.DataCacheClientSection cannot be cast to [B]Microsoft.ApplicationServer.Caching.DataCacheClientSection. Type A originates from 'Microsoft.ApplicationServer.Caching.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' in the context 'Default' at location 'C:\\Windows\\assembly\\GAC_MSIL\\Microsoft.ApplicationServer.Caching.Core\\1.0.0.0__31bf3856ad364e35\\Microsoft.ApplicationServer.Caching.Core.dll'. Type B originates from 'Microsoft.ApplicationServer.Caching.Core, Version=101.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' in the context 'Default' at location 'C:\\Users\\jschaffe\\Documents\\Visual Studio 2010\\Projects\\AppFabric\\Caching\\SampleCache\\SampleCache\\bin\\Debug\\Microsoft.ApplicationServer.Caching.Core.dll'."}

Notice the difference in the Version numbers. One is 1.0.0.0 (Windows Server AppFabric Cache) while the other is 101.0.0.0 (Windows Azure AppFabric Cache). The incompatibility derives from the combination of the configuration section in my app.config (shown below) that I need in order to utilize the Windows Server AppFabric Cache and my reference to the Windows Azure AppFabric Cache assemblies that I referenced earlier.

             type="Microsoft.ApplicationServer.Caching.DataCacheClientSection,
                   Microsoft.ApplicationServer.Caching.Core,
                   Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
             allowLocation="true"
             allowDefinition="Everywhere"/>

So the root problem is that I’m trying to assign an instance of the DataCacheClientSection from the Windows Azure AppFabric Cache assembly to an instance of the same type from the Windows Server AppFabric Cache assembly.

To correct the problem I need to reference the proper version of the assemblies. Depending on whether I’m developing for 32-bit or 64-bit, I reference the assemblies from the following directories:

32-bit systems - .\Windows\System32\AppFabric directory
64-bit systems - On 64-bit operating systems, the AppFabric directory will not be directly visible. To work around this problem, replace the System32 directory name with the name SysNative. This results in navigating to the C:\Windows\SysNative\AppFabric directory in this step

Once the references are updated, the application runs without error.

Copying a TFS Build Definition

James Schaffer — Tue, 06 Sep 2011 16:52:00 GMT

I found myself in a situation recently where I needed the ability to copy a build definition in TFS on a fairly consistent basis. While this is a feature that has been requested before, unfortunately it hasn’t yet made it into the product. So I thought I would see if I could create a Visual Studio extension that would provide this functionality in reasonably short order.

I started off researching how I might use the TFS API to perform the copy. Of course, I couldn’t find much about how to create the copy, other than the various posts asking about or requesting this functionality. What I did find though was a blog post by Jakob Ehn on creating a build definition programmatically, which served as the basis for how I would perform the copy.

You start by getting a reference to the build server via a call to the GetService method on the TfsTeamProjectCollection instance as shown in the code snippet below. Once we have the build server reference we can then load the build definition that we’re making a copy of. The key to copying the build definition is making sure that you pick up all the original build attributes. That means iterating over all of the workspace mappings and process parameters, among the other build definition settings, as shown. Once we’re done creating the copy, simply call Save() on the new build definition to commit the changes to TFS.

private void CopyBuildDefinition(string teamProject, string buildDefinitionName)

{

    // Get a reference to the build service

    IBuildServer buildServer = (IBuildServer)_tfsServer.GetService(typeof(IBuildServer));

  

    // Load the build definition to be copied

    var buildDefinitionToCopy = buildServer.GetBuildDefinition(teamProject, buildDefinitionName);

    if (buildDefinitionToCopy != null)

    {

        // Copy General Info

        var newBuildDefinition = buildServer.CreateBuildDefinition(teamProject);

        newBuildDefinition.Name = GetNewBuildName(buildServer, teamProject, buildDefinitionName);

        newBuildDefinition.Description = buildDefinitionToCopy.Description;

  

        // Copy Triggers

        newBuildDefinition.ContinuousIntegrationType = buildDefinitionToCopy.ContinuousIntegrationType;

        newBuildDefinition.ContinuousIntegrationQuietPeriod = buildDefinitionToCopy.ContinuousIntegrationQuietPeriod;

        newBuildDefinition.Schedules.AddRange(buildDefinitionToCopy.Schedules);

  

        // Copy Workspace mappings

        foreach (IWorkspaceMapping mapping in buildDefinitionToCopy.Workspace.Mappings)

        {

            newBuildDefinition.Workspace.AddMapping(mapping.ServerItem, mapping.LocalItem, mapping.MappingType, mapping.Depth);

        }

  

        // Copy Build defaults

        newBuildDefinition.BuildController = buildDefinitionToCopy.BuildController;

        newBuildDefinition.DefaultDropLocation = buildDefinitionToCopy.DefaultDropLocation;

  

        // Copy Process parameters

        newBuildDefinition.Process = buildDefinitionToCopy.Process;

        var processParams = WorkflowHelpers.DeserializeProcessParameters(buildDefinitionToCopy.ProcessParameters);

        var copyProcessParams = WorkflowHelpers.DeserializeProcessParameters(newBuildDefinition.ProcessParameters);

        foreach (KeyValuePair<string, object> entry in processParams)

        {

            copyProcessParams.Add(entry.Key.ToString(), entry.Value);

        }

        newBuildDefinition.ProcessParameters = WorkflowHelpers.SerializeProcessParameters(copyProcessParams);

  

        // Copy Retention policies

        newBuildDefinition.RetentionPolicyList.Clear();

        newBuildDefinition.RetentionPolicyList.AddRange(buildDefinitionToCopy.RetentionPolicyList);

  

        // Save copy

        newBuildDefinition.Save();

    }

}

One of the tricks of creating the copy is coming up with a meaningful name for the new build definition. You’ll see in the code snippet above at line 12 a call to GetNewBuildName(). I decided to take an approach similar to how Visual Studio creates copies of files within a project. That is, I look at the name of the build definition being copied and create the new build definition with a name of “Copy (n) of buildDefinitionName”. The implementation of this approach is shown in the following code snippet.

private string GetNewBuildName(IBuildServer buildServer, string teamProject, string buildDefinitionName)

{

    string newBuildName = DEFAULT_PREFIX + buildDefinitionName;

  

    IBuildDefinitionSpec buildDefinitionSpec = buildServer.CreateBuildDefinitionSpec(teamProject);

    buildDefinitionSpec.Name = "Copy*of " + buildDefinitionName;

    IBuildDefinitionQueryResult results = buildServer.QueryBuildDefinitions(buildDefinitionSpec);

  

    if (results.Definitions.Length >= 1)

    {

        var buildNames = from buildDef in results.Definitions

                         orderby buildDef.Name

                         select buildDef.Name;

  

        if (buildNames.Contains(newBuildName))

        {

            for (int inx = 2; inx < 50; inx++)

            {

                newBuildName = String.Format("Copy ({0}) of {1}", inx, buildDefinitionName);

                if ( !buildNames.Contains( newBuildName ) )

                    break;

            }

        }

    }

  

    return newBuildName;

}

That’s all there is to it. The completed Visual Studio extension is available for install from the Extension Manager in Visual Studio (search for "copy build" in the online gallery) or you can download it directly from the Visual Studio Gallery.

Task Parallelism in .NET 4.0 (a practical example)

James Schaffer — Tue, 31 May 2011 18:38:00 GMT

I recently needed to develop some code that would read diagnostic information from a group of servers for a production application. This included reading a count of event log entries, reading performance counter values and also performing database queries to retrieve exception log information for the application. The idea was to provide a high level snapshot of the overall health of the application so at a glance support personnel could see if any issues were arising with the application (yes, I know, some home grown health monitoring).

In order to make the data retrieval efficient I wanted to take as many of the readings in parallel as possible . Prior to .NET 4.0 I would have looked at using the ThreadPool for this functionality and queueing separate user work items for each request. With .NET 4.0 however we now have use of the Task Parallel Library (TPL) which allows for more efficient use of system resources and also provides better programmatic control than is typically available when working directly with the thread pool.

In my particular scenario I have a group of servers that each have one or more of the above readings (event log count, performance counter or database query) that need to be retrieved. The result of each reading returns a similar output (numeric in this case – either integer or double). Since I want to execute these tasks in a concurrent manner, that’s where the TPL and the new Task class come into play. The Task class allows me to easily execute an asynchronous operation and return a result.

In my case I effectively want the retrieval of each data reading to be executed as a separate Task. I can also have each task return a result by instantiating a Task (see How to: Return a Value from a Task for more details). I want each Task to return the value for the reading, along with the server name and reading name (this is used to group/correlate the readings after all tasks have executed, which I’ll explain shortly). The output of each task is therefore defined by the DataResult class shown below.

/// 

/// Class used to return results from the executing thread (task)

/// 

class DataResult

{

    public string ServerName { get; set; }

    public string MeasureName { get; set; }

    public double MeasureValue { get; set; }

}

Since I know the number of tasks I need to execute based on my inputs (the number of servers and the number of readings) I simply create a array of tasks of type DataResult. I then iterate through the readings and servers, executing the appropriate method for each Task based on the type of reading being obtained.

// Create a separate task/thread for each measurement to be taken

Task[] tasks = new Task[measureList.Count() * serverList.Count()];

int inx = 0;

  

// Retrieve the data

foreach (DataModel.Measure measure in measureList)

{

    DataReading reading = new DataReading();

    reading.DisplayName = measure.DisplayName;

    reading.ServerValues = new Dictionary<string, ServerValue>();

    data.Readings.Add(reading);

  

    foreach (DataModel.Server server in serverList)

    {

        ServerValue serverData = new ServerValue();

        serverData.ServerName = server.HostName;

        serverData.ServerType = server.ServerType.Type;

        serverData.ServerId = server.Id;

        reading.ServerValues.Add(serverData.ServerName, serverData);

  

        MeasureInfo measureInfo = new MeasureInfo(env, server, measure);

        switch (measure.Type)

        {

            case (int)MeasureTypes.PerfCounter:

                tasks[inx] = new Task(GetPerfCounterValue, measureInfo);

                break;

            case (int)MeasureTypes.EventLog:

                tasks[inx] = new Task(GetLogEntries, measureInfo);

                break;

            case (int)MeasureTypes.DBErrors:

                tasks[inx] = new Task(GetDbErrors, measureInfo);

                break;

        }

        tasks[inx].Start();

        inx++;

    }

}

Of primary concern above is the looping construct and the switch statement that instantiates each Task instance with the appropriate method target depending on the type of reading. The other code is primarily concerned with passing the appropriate input to the target method and setting things up for the correlation. The target methods for each type of reading take the measureInfo as input, containing information on the data to be retrieved, and return an instance of the DataResult class. The methods for both the event log and performance counter operations are shown below.

private DataResult GetLogEntries(object data)

{

    MeasureInfo measureInfo = data as MeasureInfo;

    DataResult result = new DataResult()

    {

        MeasureName = measureInfo.Measure.DisplayName,

        ServerName = GetServerName(measureInfo),

        MeasureValue = -1

    };

    DateTime startTime = DateTime.Now;

  

    string dateTimeFilter = _queryTimeConstraint.ToString("yyyyMMddHHmmss.000000+000");

    measureInfo.Measure.Data = string.Format(measureInfo.Measure.Data, dateTimeFilter);

  

    ManagementObjectSearcher mos = new ManagementObjectSearcher(String.Format(@"\\{0}\root\cimv2", measureInfo.Server.HostName), measureInfo.Measure.Data);

  

    result.MeasureValue = mos.Get().Count;

  

    return result;

}

  

  

private DataResult GetPerfCounterValue(object data)

{

    MeasureInfo measureInfo = data as MeasureInfo;

    DataResult result = new DataResult()

    {

        MeasureName = measureInfo.Measure.DisplayName,

        ServerName = GetServerName(measureInfo),

        MeasureValue = -1

    };

  

    string[] perfInfo = measureInfo.Measure.Data.Split(';');

    PerformanceCounter perfCounter = new System.Diagnostics.PerformanceCounter();

    perfCounter.CategoryName = perfInfo[0];

    perfCounter.CounterName = perfInfo[1];

    if (perfInfo.Length > 2)

    {

        perfCounter.InstanceName = perfInfo[2];

    }

    perfCounter.MachineName = measureInfo.Server.HostName;

  

    result.MeasureValue = perfCounter.NextValue();

  

    return result;

}

The returned DataResult instance ends up in the task’s Result property. Since I need to do some correlation once all the tasks have finished executing, I can simply do a Task.WaitAll on the array of tasks (NOTE: Accessing the Result property on the task instance will also block the calling thread until the task finishes). Once they’ve finished I can then loop through the tasks and perform my correlation using the Result property as shown.

// Wait for all tasks to complete and then copy the result to the appropriate reading

Task.WaitAll(tasks);

foreach (Task task in tasks)

{

    DataReading result = data.Readings.Find(delegate(DataReading reading)

    {

        return reading.DisplayName == task.Result.MeasureName;

    });

  

    if (result != null)

    {

        ServerValue serverValue = result.ServerValues[task.Result.ServerName];

        serverValue.Value = task.Result.MeasureValue;

    }

}

That’s it. Multi-threaded functionality added to my app with only a few lines of code and much greater programmatic control by using Tasks, especially the ability to return a complex data type as the result of the execution of each task. This example just scratches the surface of the TPL and using it for Task Parallelism. For additional topics please see Parallel Programming in the .NET Framework.

A UI Wrapper for TFS Rollback Using a Visual Studio Package

James Schaffer — Sun, 24 Apr 2011 18:24:00 GMT

I’ve been using Team Foundation Server since the initial release of TFS 2005. TFS provides a great set of tools that make the process of Application Lifecycle Management much easier. However, one piece of functionality that was initially non-existent and still cumbersome to use at best is the process of rolling back a changeset in TFS version control.

Rollback functionality was initially provided via a separate install of the Team Foundation Power Tools. With the release of TFS 2010, rollback functionality is now available out of the box as an operation of the tf.exe command line tool. In both cases though the functionality is performed via the command line and requires that you enter a version control path, changeset number and possibly a local file path (in the case of TFS 2008) as arguments. If you’ve had to perform more than a couple of rollbacks using this approach, you know it is very clumsy and obviously prone to error.

Wouldn’t it be nice if we had a user interface for performing rollbacks that was integrated directly with the Visual Studio IDE? The UI would allow you to easily browse TFS for the version control path and changeset, thereby making the entire process a little more straightforward. Well, that’s what I’ve attempted to do with the result of this post. I wanted to build something that integrated directly into Visual Studio 2010, so the natural result was to create an extension for Visual Studio via a Visual Studio Package provided with the Visual Studio 2010 SDK.

Before we delve into the extension, let me start by saying that my objective is not to re-write the rollback functionality provided by the command line utilities. The folks in the product group have provided a tool that does that job quite adequately and I’m certain is not trivial in nature to implement. My goal is simply to provide a UI wrapper around the rollback functionality and make things a little more user friendly in the process.

Now let’s get into the details of the extension. The output of any Visual Studio Package project is a VSIX file which you can run to install the package and make it available in Visual Studio 2010 (NOTE: If Visual Studio 2010 is running during the install you’ll need to restart it to see the changes). Installation of the TFS Rollback VSIX will add a new option to the Tools menu as shown.

Executing the TFS Rollback option from the Tools menu will display the primary dialog window for the rollback operation as shown in the following screen shot.

As you can see, the UI is pretty straight forward. Before you can browse for a version control path and changeset, you must first you provide a URL for your TFS server and click the Connect button. Once you are connected to the TFS Server, the status bar will indicate the URL of the server you are currently connected to. At this point you can now browse for the Server Path and the corresponding changeset that you want to rollback as shown below.

While tf.exe will allow you to specify multiple changesets for rollback only a single changeset is currently supported by the extension.

You’ll also note from the main dialog that a workspace name must be provided to perform the rollback. Specifying a temporary workspace is more of a legacy requirement for working with TFS 2008 where you needed to download the entire source tree for the selected Server Path in order to perform the rollback. While this is no longer required with TFS 2010, the process of using a temporary workspace mapping still seems like the right approach, so the same method is applied. The temporary workspace name is mapped to the local path that you specify and then the source files are downloaded to this temporary workspace in order to perform the rollback. Then once you indicate that the rollback is complete (e.g. you’ve checked in the corresponding changes) the temporary workspace and corresponding source files are removed from your local machine.

So once you’ve provided all the necessary inputs to perform the rollback, simply click the Submit button to kick off the rollback. This will make all the necessary calls via TFS’s VersionControlServer class in order to set up the workspace and create the mapping (by the way, this is the same class that is used for browsing the source control tree and for querying for the changeset). Once the workspace and the associated mapping are established, the Process class is used to execute the command line utility as shown below.

private int PerformRollback()

{

    int exitCode = 0;

  

    Process tfProcess = new Process();

    tfProcess.StartInfo.UseShellExecute = false;

    tfProcess.StartInfo.WorkingDirectory = _localPath;

    tfProcess.StartInfo.FileName = CommandPath;

    tfProcess.StartInfo.Arguments = String.Format("rollback /changeset:{0}~{0} \"{1}\" {2}",

                                                  _changeSet,

                                                  _serverPath,

                                                  (_recursive == true) ? "/recursive" : string.Empty);

    tfProcess.Start();

    tfProcess.WaitForExit();

  

    exitCode = tfProcess.ExitCode;

  

    return exitCode;

}

As mentioned above, since the rollback is creating pending changes in the temporary workspace, you need to indicate when the operation is complete so that the package knows when to perform its cleanup tasks (e.g. removing the temporary workspace and files). So once the Process instance for the rollback operation completes, you’ll see the following dialog indicating that further action is required on your part to complete the rollback. At this point you should either check in the pending changes from the rollback operation or undo those changes if you decide the changes should not be committed.

If you elect not to check in the changes you can choose to undo the pending changes manually. Otherwise, when the extension attempts to remove the workspace it will check for any pending changes. If any pending changes are found it will prompt you as to whether or not you want to delete the temporary workspace (thereby undoing the changes). If you elect not to delete the temporary workspace in this scenario then your pending changes will be preserved locally.

I won’t go into all the details around writing the VS Package. The package is responsible for creating the new menu command that gets added to the Tools menu. The event handler for the menu command is then responsible for launching the main dialog which is implemented as a WPF window. The main dialog and the browsing dialogs then make the necessary calls through the TFS version control API to browse the version control folders, etc. There is a detailed walkthrough on MSDN that discusses creating a menu command using the VSPackage template.

One interesting item of note with respect to the implementation is maintaining the user’s settings. First of all, I anticipate that the end user will re-use the same values for the TFS URL, the local path used for the temporary workspace and the temporary workspace name. The extension will also look for tf.exe in the default installation path (C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE) and if not found will prompt the user for the path to the executable. Rather than have the user re-enter the values every time they launch the extension, you can use the ShellSettingsManager to create a collection of user settings that can be persisted. The retrieval of these settings is also performed in the event handler for the menu command as shown. The user’s settings are saved in the Closing event handler for the rollback window.

WritableSettingsStore userSettingsStore = null;

TfsRollback.MainWindow rollbackWindow;

  

private void MenuItemCallback(object sender, EventArgs e)

{

    SettingsManager settingsManager = new ShellSettingsManager(this);

    userSettingsStore = settingsManager.GetWritableSettingsStore(SettingsScope.UserSettings);

  

    rollbackWindow = new TfsRollback.MainWindow();

  

    // Get any saved settings

    if (userSettingsStore.CollectionExists(SettingsName))

    {

        if (userSettingsStore.PropertyExists(SettingsName, TfsUrlPropertyName))

            rollbackWindow.TfsUrl = userSettingsStore.GetString(SettingsName, TfsUrlPropertyName);

        if (userSettingsStore.PropertyExists(SettingsName, WorkspacePropertyName))

            rollbackWindow.WorkspaceName = userSettingsStore.GetString(SettingsName, WorkspacePropertyName);

        if (userSettingsStore.PropertyExists(SettingsName, LocalPathPropertyName))

            rollbackWindow.LocalPath = userSettingsStore.GetString(SettingsName, LocalPathPropertyName);

        if (userSettingsStore.PropertyExists(SettingsName, CommandPathPropertyName))

            rollbackWindow.CommandPath = userSettingsStore.GetString(SettingsName, CommandPathPropertyName);

    }

  

    // Show the rollback dialog

    rollbackWindow.Closing += new System.ComponentModel.CancelEventHandler(rollbackWindow_Closing);

    rollbackWindow.Show();

}

  

void rollbackWindow_Closing(object sender, System.ComponentModel.CancelEventArgs e)

{

    // Save any settings

    if (userSettingsStore.CollectionExists(SettingsName) == false)

        userSettingsStore.CreateCollection(SettingsName);

    if (!String.IsNullOrEmpty(rollbackWindow.TfsUrl))

        userSettingsStore.SetString(SettingsName, TfsUrlPropertyName, rollbackWindow.TfsUrl);

    if (!String.IsNullOrEmpty(rollbackWindow.WorkspaceName))

        userSettingsStore.SetString(SettingsName, WorkspacePropertyName, rollbackWindow.WorkspaceName);

    if (!String.IsNullOrEmpty(rollbackWindow.LocalPath))

        userSettingsStore.SetString(SettingsName, LocalPathPropertyName, rollbackWindow.LocalPath);

    if (!String.IsNullOrEmpty(rollbackWindow.CommandPath))

        userSettingsStore.SetString(SettingsName, CommandPathPropertyName, rollbackWindow.CommandPath);

}

One additional feature that I might look to add in a subsequent release would be providing connectivity to TFS 2008. I’ve run into scenarios where customers have upgraded to Visual Studio 2010, but their TFS installation is still running on 2008. I’d expect those situations won’t last much longer, but if you have interest in the extension supporting this scenario let me know.

You can install the extension by downloading it from the Visual Studio Gallery or by installing it from Extension Manager in Visual Studio.

Creating a Custom Base Page for Windows Phone 7

James Schaffer — Thu, 03 Mar 2011 17:36:00 GMT

When I first starting creating applications for Windows Phone 7, I noticed there was certain functionality that I was duplicating across my pages. Just like I do with ASP.Net applications, my immediate thought was to create a custom base page, derived from PhoneApplicationPage, that all my pages would then inherit from. Being fairly new to Windows Phone 7 development, and Silverlight development in general, it wasn’t readily apparent to me how to do this, but it turns out to be fairly straightforward.

To begin with I’ll obviously need a new base class similar to that shown below.

public class BasePage : PhoneApplicationPage

{

    // BasePage implementation goes here...

}

With the BasePage class in place, we can then derive our individual pages from this class, similar to the following code for MainPage:

public partial class MainPage : BasePage

{

    // Constructor

    public MainPage()

    {

        InitializeComponent();

    }

}

In order to make this work, we also need to update the corresponding XAML file to reference the new base class. This requires that we import our local namespace as well. Line 9 in the next code snippet shows the namespace reference while lines 1 and 19 show the open/close tag used to reference the new BasePage class.



    x:Class="Wp7CustomBasePage.Views.MainPage"

    xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"

    xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"

    xmlns:phone="clr-namespace:Microsoft.Phone.Controls;assembly=Microsoft.Phone"

    xmlns:shell="clr-namespace:Microsoft.Phone.Shell;assembly=Microsoft.Phone"

    xmlns:d="https://schemas.microsoft.com/expression/blend/2008"

    xmlns:mc="https://schemas.openxmlformats.org/markup-compatibility/2006"

    xmlns:local="clr-namespace:Wp7CustomBasePage.Views"

    mc:Ignorable="d" d:DesignWidth="480" d:DesignHeight="768"

    FontFamily="{StaticResource PhoneFontFamilyNormal}"

    FontSize="{StaticResource PhoneFontSizeNormal}"

    Foreground="{StaticResource PhoneForegroundBrush}"

    SupportedOrientations="Portrait" Orientation="Portrait"

    shell:SystemTray.IsVisible="True">

  

    

  



That’s effectively all there is to it.

So what kind of functionality would you want in your base page? I find that I typically add functionality related to navigation, messaging and state management. When I refer to messaging I’m referring to the concept of sending notifications from the ViewModel back to the View. This of course assumes that you are using MVVM in your applications. Messaging isn’t directly supported in Silverlight for Windows Phone so I use the MVVM Light Toolkit for this purpose. If you’re new to MVVM John Papa has a post that provides a good overview.

So here’s the base page after some of this functionality has been added.

public class BasePage : PhoneApplicationPage

{

    // Override OnNavigatedTo to register for messages from view model

    protected override void OnNavigatedTo(System.Windows.Navigation.NavigationEventArgs e)

    {

        base.OnNavigatedTo(e);

        Messenger.Default.Register<string>(this, this.HandleMessage);

    }

  

    // Override OnNavigatedFrom to unregister for messages from view model

    protected override void OnNavigatedFrom(System.Windows.Navigation.NavigationEventArgs e)

    {

        base.OnNavigatedFrom(e);

        Messenger.Default.Unregister(this);

    }

  

    // Correctly cast derived Application class for accessing public variables

    public Wp7CustomBasePage.App MyApp

    {

        get { return (Wp7CustomBasePage.App)App.Current; }

    }

  

    // Handler to display messages sent from ViewModel

    private void HandleMessage(string message)

    {

        MessageBox.Show(message, "CAPTION", MessageBoxButton.OK);

    }

  

    // Navigate to a specific view

    protected void NavigateToView(string viewName)

    {

        NavigationService.Navigate(new Uri(String.Format("/Views/{0}.xaml", viewName), UriKind.Relative));

    }

}

With respect to the messaging discussion above, you’ll notice this is handled in the OnNavigatedTo and OnNavigatedFrom overrides in BasePage. In OnNavigatedTo the page registers to receive messages from the ViewModel and passes a common handler for processing the message. In this case, the handler displays a MessageBox. Similarly, every time the user navigates away from the page it unregisters in theOnNavigatedFrom method. Unregistering as you navigate away from the page avoids the problem of getting multiple messages if you had multiple pages instantiated that were simultaneously registered. Now when any of my ViewModels send a message using code similar to the following:

   1: Messenger.Default.Send<string>("Work Done in Page 1 View Model.");

Any of my pages will automatically display a message box showing the message.

The final sample code is included below. (Requires the Windows Phone Developer Tools and MVVM Light Toolkit)

Wp7CustomBasePage.zip

JavaScript Lint Check-In Policy for TFS

James Schaffer — Tue, 22 Feb 2011 16:58:00 GMT

Most web applications contain custom Javascript files to perform any number of tasks within the browser in order to provide an improved experience for the end user. Of course, our Javascript source files are just as prone to syntax errors as the code we write in C# of VB.Net. There are various tools, such as JSLint and JavaScript Lint, that allow for syntax checking of JavaScript. However, it might also be beneficial to have this syntax checking functionality incorporated into Team Foundation Server in order to ensure that our JavaScript syntax is correct before it can be checked in. As such, this post discusses the creation of a custom TFS check-in policy that leverages JavaScript Lint to validate any Javascript source files that were added or modified as part of a pending changeset.

I won't go into the specifics on the creation of custom check-in policies for TFS as there is plenty of documentation on MSDN and elsewhere that covers the topic in detail. I will however cover the code for a couple of interesting aspects of the solution, the first of which is the need to specify the path to the JavaScript Lint executable. In order for the check-in policy to perform its work, it must have the JavaScript Lint executable specified as part of its configuration when it is installed. This is handled through an override to the Edit method of the policy. The override displays a custom Windows Form that allows you to browse to the appropriate path of the JavaScript Lint executable and then saves that value via a public property of the policy. This is shown in the following code snippet.

[Serializable]
public class CheckForJavascriptChangesPolicy : PolicyBase
{
        public string JsLintPath;

        public override bool Edit(IPolicyEditArgs policyEditArgs)
        {
            GetPath frm = new GetPath();
            frm.StartPosition = FormStartPosition.CenterParent;
            if (!String.IsNullOrEmpty(JsLintPath))
                frm.SelectedPath = JsLintPath;
            if (frm.ShowDialog(policyEditArgs.Parent) == DialogResult.OK)
            {
                if (!String.IsNullOrEmpty(frm.SelectedPath))
                {
                    JsLintPath = frm.SelectedPath;
                    return true;
                }
            }
 
            return false;
        }

        ......
}

Since the derived policy class is marked as Serializable the value of the JsLintPath property will be persisted and available when the policy is evaluated during check-in.

The other interesting piece of the custom policy is of course found in the override of the Evaluate method as shown below.

public override PolicyFailure[] Evaluate()
{
  bool jsLintFound = false;
  StringCollection policyFailureMessages = new StringCollection();
 
  PendingChange[] changes = PendingCheckin.PendingChanges.CheckedPendingChanges;
  foreach (PendingChange pendingChange in changes)
  {
    if ((pendingChange.ChangeType.HasFlag(ChangeType.Add) || 
          pendingChange.ChangeType.HasFlag(ChangeType.Edit)) &&
          pendingChange.FileName.EndsWith(".js"))
    {
      if (jsLintFound || System.IO.File.Exists(JsLintPath))
      {
        jsLintFound = true;
        Process jslProcess = new Process();
        jslProcess.StartInfo.FileName = JsLintPath;
        jslProcess.StartInfo.WindowStyle = ProcessWindowStyle.Hidden;
        jslProcess.StartInfo.Arguments = String.Format("-process \"{0}\"",
                                                  pendingChange.LocalItem);
        jslProcess.Start();
        jslProcess.WaitForExit();
        if (jslProcess.ExitCode != 0)
        {
          policyFailureMessages.Add(String.Format(
              "Javascript Lint check failed for {0}", 
              pendingChange.LocalItem));
        }
      }
      else
      {
        policyFailureMessages.Add("Javascript Lint executable wasn't found.");
        break;
      }
    }
  }
 
  if (policyFailureMessages.Count > 0)
  {
    List<PolicyFailure> policyFailures = new List<PolicyFailure>();
 
    foreach (string message in policyFailureMessages)
    {
      policyFailures.Add(new PolicyFailure(message, this));
    }
 
    return policyFailures.ToArray();
  }
  else
    return new PolicyFailure[0];
}

Here the code effectively enumerates each item in the changeset, looking for additions or modifications with an extension of *.js. If any are found, the JavaScript Lint command line is spun up as a separate process and run against the file. Javascript Lint will emit a return code value other than 0 if any syntax errors are found. If that is the case, then a new entry is added to the PolicyFailure array indicating that the check-in should not proceed. This results in output to the Pending Changes window in the Policy Warnings pane similar to the following:

I've created a Visual Studio 2010 extension that installs the custom policy if you are interested in trying it out. Of course you'll also need to download the JavaScript Lint executable. In order to install the policy just perform the following:

Download and extract the *.vsix file from the provided zip.
Install the *.vsix by double clicking the file.
1. NOTE: If Visual Studio is open when you perform the install you may need to restart Visual Studio before you can continue with the next step.
From Team Explorer, right click the project where you want to enable the policy and select Team Project Settings->Source Control... from the context menu.
From the Source Control Settings dialog select the Check-in Policy tab, click the Add... button, select the Check for Javascript Changes Policy and click OK.
Upon initially enabling the policy, supply the local path to the Javascript Lint executable (jsl.exe).

JavascriptLintCheckinPolicy.vsix.zip