Rob Caron pointed me out to an article on FTP Online by William Wen entitled "Enable IntelliSense in Your Documents" (you need to register to read the second part of the article - it's definitely worth it). In his article, William describes how you can use xsi:schemaLocation to get the XML Editor to automatically download your schema. Using his technique, I got IntelliSense to work on my process template files (although I am still searching for a technique to load them in locally).

Here are the steps I took to enable IntelliSense in my process template file (ProcessTemplate.xml):

1. Open ProcessTemplate.xml in Visual Studio 2005
2. Click on XML > Create Schema
3. Edit the newly generated ProcessTemplate.xsd schema file
4. In the xs:schema node, add the following:

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.w3.org/1999/XSL/Transform http://www.fooserver.com/ProcessTemplate.xsd"

5. Save the file and upload it to a web server (in this example, I use a fictional server name fooserver.com). For example: http://www.fooserver.com/ProcessTemplate.xsd 

6.Change the ProcessTemplate node in ProcessTemplate.xml to indicate the following:

<ProcessTemplate xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.w3.org/1999/XSL/Transform http://www.fooserver.com/ProcessTemplate.xsd">

Now whenever you load in ProcessTemplate.xml in Visual Studio 2005, you'll get IntelliSense. Not the most elegant way of enabling IntelliSense, but it works. The search continues...

A couple of days ago, Rob Caron posted about how to author Work Item Types with IntelliSense in Visual Studio. You can download the process template schema files from the following link: http://msdn2.microsoft.com/en-us/library/ms194967.aspx

Typically, all you need to do is add all the .xsd files into the C:Program FilesMicrosoft Visual Studio 8XmlSchemas directory. For some reason, I haven't been able to get IntelliSense to work with the process template xml files. For example:

The only options that are coming up include:

!--
![CDATA[
?

To troubleshoot the issue, I took a look at Aaron Stebner's blog post on how to configure the Visual Studio 2005 IDE to use custom XSD files for IntelliSense. I still can't get it working, and I suspect the issue is related to the schema namespaces. I found a way to temporarily get around the issue. Follow these steps:

If anyone has additional insight, or has encountered similar problems, feel free to post. If I work out a fix, I'll post it right away.

Since I haven't posted in a while, I decided to post a triple header. One of my clients encountered the following error while trying to implement Continuous Integration (CI). Even when he tried to manually launch a build using the same Team Project, the problem persisted:

I've been watching a lot of CSI recently - so I've decided to pull a Gil Grissom and "find the evidence".

The problem is that the project tries to access a resource that is no longer accessible. Team Foundation Server uses the Classification Service to track items such as work items.

The first thing I verified was that the build functionality worked on other Team Projects. The answer was yes - and eliminated the possibility that the root of the problem was the service itself. I then knew that the problem was localized at the Team Project level.   

The next question I asked was "What would make a resource and security object disappear?". Deleting it of course - however, the project was there in plain sight on the server and from experience, I knew that you couldn't have two Team Projects with the same name on the same server.

On a hunch, I asked the client if they had deleted the Team Project. To my surprise, they answered yes. Case solved.

They deleted the Team Project and somehow recreated it with the same name. The problem is, once you delete a Team Project, it isn't really deleted. There are portions of the project (including version control code and work items) that are perpetually stored in the Team Foundation Data Warehouse (for auditing purposes and as a design feature). When the client managed to recreate the project, they still had links to "phantom" objects.

Unfortunately, for all intents and purposes, the client's Team Project is corrupted. The client created a new Team Project and everything worked out fine.

A lot of the people I've met in the past year have requested code that demonstrates how to display work items on a webpage. I've created an ASP.NET 2.0 sample from my upcoming book Professional Team Foundation Server which I will share with you today. 

There are a couple of really interesting elements to this code - first of all, it has no code behind. The sample was built completely using declarative code. The second thing you will notice is that it doesn't contain any hooks using the Work Item Tracking Object Model. There are a couple of reasons for this: first of all, the WIT OM approach can be quite slow, especially if you are pulling in a lot of work item data. I opted to directly query the relational table [TfsWorkItemTracking].[dbo].[WorkItemsLatest].There are also a lot of security settings that need to be put into place in order to allow the Work Item Tracking OM to access a Web page. Since we are using SQL queries, we don't have to worry about the restrictions. FYI, the WIT OM Web configuration setttings are documented on Naren Datha's blog: http://blogs.msdn.com/narend/archive/2006/07/29/682032.aspx

To install the application, simply create an ASP.NET 2.0 Web page, add the GridView code into your Web form, edit your Web.config file and add the connection string (don't forget to change the TFSRTM server name to your own server name). This is a basic example but gives you a hint of the power of the technique - why limit it to work items? You can potentially display any data stored in the Team Foundation Data Warehouse easily and quickly. Here is a screenshot of the end result: