There are two really powerful ways to harvest the output from the build in to Wix.

Heat extensions that are native with the Wix Install or John Robbins Paraffin. The advantage with using Heat is that with some clients there is a lot of controls with utilising software from the interweb, and Heat is available from the same location as Wix.

The Wix installation is available from here, remember that you will need v3.5 to use with Visual Studio 2010. (Yes it is still listed as Beta, however it works very well!)

Once you have installed Wix and and the project aggregator, the steps to use Heat to harvest the project output are as follows:

So the project.wxs looks like

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
  <Product Id="*" Name="SetupDemo" Language="1033" Version="1.0.0.0" Manufacturer="SetupDemo" UpgradeCode="78282ed7-9280-497b-affa-da3fce3f4f47">
    <Package InstallerVersion="200" Compressed="yes" Id ="*" />

    <Media Id="1" Cabinet="Demo1.cab" EmbedCab="yes" />

    <Directory Id="TARGETDIR" Name="SourceDir">
      <Directory Id="ProgramFilesFolder">
        <Directory Id="INSTALLLOCATION" Name="SetupDemo">
          <Directory Id="AppRootDir" Name="Demo"/>
          <Directory Id="AppSymbolDir" Name="Demo" />

        </Directory>
      </Directory>
    </Directory>

    <Feature Id="ProductFeature" Title="SetupDemo" Level="1">
       <ComponentGroupRef Id="Project" />

      <!-- Note: The following ComponentGroupRef is required to pull in generated authoring from project references. -->
      <ComponentGroupRef Id="Product.Generated" />
    </Feature>
  </Product>
</Wix>

And the associated (Demo.wxs) looks like

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
    <Fragment>
    <DirectoryRef Id="AppRootDir">
      <Directory Id="ComponentDir" ComponentGuidGenerationSeed="DBA8384E-CE1B-41af-B573-4203FB8A6A3B">
        <Directory Id="Demo.Binaries" />
      </Directory>
    </DirectoryRef>
    <DirectoryRef Id="AppSymbolDir">
      <Directory Id="SymbolsDir" ComponentGuidGenerationSeed="35A3DCB8-4F85-4e3f-AC83-C51B78C04B94">
        <Directory Id="Demo.Symbols" />
      </Directory>
    </DirectoryRef>
    <ComponentGroup Id="Project">
      <ComponentGroupRef Id="Demo.Binaries"/>
      <ComponentGroupRef Id="Demo.Symbols"/>
    </ComponentGroup>
    </Fragment>
</Wix>

Somebody asked me a simple question the other day: “how do I export all of my work items at once”. I suspected they were looking to perform a backup, but it sounded like they might want to import into another system or just archive them in some readable way. I suggested Microsoft Excel, but it can only fetch work items from one team project at a time. So repetition, using a Macro or a human, would be required.

Here’s an alternative we came up with …

1. Downloaded and installed Team Foundation Power Tools.

2. Picked one of the Team Projects, added a query, and removed the Team Project = @Project clause, so that it was completely empty:

3. Changed the Column Options, added the columns we wanted to export. For testing, we selected ID, Team Project, Work Item Type, and Title.

4. Ran the query and verified that it pulled the right work items and fields we wanted.

5. Saved the query (My query) and named it AllProjectWorkItems.

6. Dropped to the command prompt and executed the following commands:

    cd c:\Program Files\Microsoft Team Foundation Server 2008 Power Tools

    tfpt query "Calculator\My Queries\AllProjectWorkItems" /Server:vsts /format:xml > c:\AllWorkItems.xml

7. This command generated an XML file containing all of the fields from all work items from all projects. This satisfied their requirement.

At this point you can update the query adding more columns, until you have the superset of what you need for the export of all types from all projects. With a little finesse, the XML document could be migrated into Excel or another software application.

Out of the box, Microsoft has a Work Items check-in policy which requires you to select at least one work item when checking in your code in TFS 2008. If you install the Team Foundation Server Power Tools, you’ll get the Work Item Query check-in policy. This is nice because it allows you to specify a team query to which the work item associated with a check-in must belong. The example I give is that the team may want to spend the next couple of days on a “bug bash”, so you could use this policy to point to the “Active Bugs” query, etc.

What’s missing is a policy that enforces you selecting exactly one work item during check-in. I believe this is crucial for maximum traceability: one changeset to one work item. This is a good habit to adopt as it increases the maintainability of the code, offering better get, branch, build, and merge options. Another way to put it: chatty check-ins (many, throughout the day) are preferred to chunky check-ins (one big one at 5pm).

If only Microsoft had added a configuration page to either of the above policies, I wouldn’t have had to build this policy.

Follow the P&P How-To guidance using the attached project to implement this policy.

Attachments: SingleWorkItemPolicy.zip (19kb)

I was at a client site last month where they have TFS2008SP1 installed and running on Windows Server 2008 SP1. Everything was working fine. We created several team projects. No problems.

I come back three weeks later and it wouldn’t create a team project. I kept getting the “Project Creation Wizard encountered a problem while uploading documents to the Windows SharePoint Services server” error. According to the client, they hadn’t touched anything. So, I started with Ben Day’s blog post on the subject, but his fix didn’t work for me. I then checked all the service accounts, permissions, farm administrator group, database status, etc. – all the standard things, but no help.

Come to find out none of the SharePoint collection/sites would come up, let alone allow me to create new ones. The Admin site worked, but every other site gave the “Cannot complete this action. Please try again” wonderfully helpful error message.

Windows event logs and SharePoint event logs were useless, but I did find a KB article talking about setting impersonation explicitly from code, so I decided to check the Authentication settings on the Default Web Site and sure enough it was Disabled. I changed it to Enabled, ran IISRESET for good measure, and voila!

I watch House enough to know that “everybody lies”. It’s a basic Houseism. That was the case here. The “we didn’t touch anything” statement turned out to be false.

Windows Update dropped the SP2 update at my doorstep yesterday.

Since I’m always nervous about patching a server running Team Foundation Server, I checked with the VSTS product group.

Brian Harry indicated that installing SP2 on a TFS box will be just fine.

Happiness.

I'm pleased to announce that the Team Foundation Adapters project is up and running on CodePlex. The project description is as follows:

Team Foundation Adapters make it easier to do proper unit testing of applications that utilize the Team Foundation Server API, by providing a simple mechanism for mocking the commonly used sealed classes in the API, which cannot otherwise be mocked.

This is not vaporware folks. There's a working implementation, complete with sample unit tests. The project does not cover the entire Team Foundation API just yet. But it establishes a clearly defined baseline that will grow as needed.

Please have a look at the project and let me know what you think of this approach. If you like it, be sure to tell your friends about it. 

Many thanks to Jeff Bramwell, William Bartholomew, Martin Woodward and Mitch Denny for joining up as contributors. If you're interested in contributing as well, please let me know.