Working with XDocument and Namespaces

I really like working with the new LINQ support for XML files. However, every time I work with a document that has namespaces, I stumble. For some reason, I just can’t remember all the details required to be able to use XPath expressions when you have namespaces defined in an XML file. A blog post, therefore, seems like a good idea.

Default Namespace

A common case is where an XML file has a default namespace defined at the very top. For example,

<Project ToolsVersion="3.5" DefaultTargets="Build" 
    xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <RootNamespace>Test</RootNamespace>
    <AssemblyName>Test</AssemblyName>
    <OutputType>Library</OutputType>
  </PropertyGroup>
  ...

I wanted to retrieve the RootNamespace element, which without the default namespace can be done with code like this:

return doc.Root.XPathSelectElement("PropertyGroup/RootNamespace").Value

But when you have a default namespace, you’ll get an exception because the XPathSelectElement method returns null. Instead, you have to use a namespace manager like this:

XmlNamespaceManager namespaces = new XmlNamespaceManager(new NameTable());
XNamespace ns = _doc.Root.GetDefaultNamespace();
namespaces.AddNamespace("ns", ns.NamespaceName);
return doc.Root.XPathSelectElement("ns:PropertyGroup/ns:RootNamespace", namespaces).Value; 

The trick, as you can see, is to give a name (“ns” in this example) to the default namespace, and then explicitly refer to that name in your XPath expression.

This blog has moved

This blog is now located at http://blogs.socha.com/. You will be automatically redirected in 30 seconds, or you may click here. For feed subscribers, please update your feed subscriptions to http://blogs.socha.com/feeds/posts/default.

Upgrading Team Foundation Server 2008 Reports to 2010, Part III

This is likely to be my final post on upgrading reports for Team Foundation Server 2010, and reflects one last change we made to the cube schema from the Release Candidate to the final version. This last change was to improve the performance of cube processing, and in particular, processing the Test Result dimension. We were able to significantly improve performance by removing the Area and Iteration Hierarchy attributes from the Test Result dimension.

So if you have any reports that use these hierarchies in the Test Result dimension, you’ll need to update your reports.

Sunder Raman has provided a higher-level overview of this change:
http://blogs.msdn.com/sunder/archive/2010/03/03/team-foundation-server-2010-cube-schema-changes-in-rtm.aspx

Area Hierarchy

You’ll want to use the Area Hierarchy from the Test Case dimension. The idea is that the test case defines the area that is being tested, so this is the appropriate test result to use. Your other option would be to use the Area Hierarchy from the Test Plan dimension. However, we don’t recommend this because test plans can and often do cover multiple areas.

One side effect of this change is that you’ll now see the area for some test results listed as Unknown. This means they don’t have any area, which will be the case when you publish unit test results that aren’t connected to a Test Case. Previously these test results appeared in the root area path for your Team Project, so it’s a minor change. But now you can at least tell which test results were explicitly connected to an area as a result of being run via a Test Case.

Iteration Hierarchy

You’ll want to use the Iteration Hierarchy from the Test Plan dimension. Test Plans are usually tied to a specific iteration. In Agile development, each new iteration introduces new functionality, and therefore a new test plan is required. Test Cases, on the other hand, don’t really live in any one iteration, so it wouldn’t make sense to use the iteration from the test case.