Introduction

In C#, XElement and LINQ to XML are often enough for structured XML queries, but you can also run XPath against LINQ-to-XML objects when that syntax is more natural. The key detail is that XPath support comes from extension methods in System.Xml.XPath, not from XElement alone.

Using XPath with XElement

To run XPath queries, add the right namespaces:

using System;
using System.Xml.Linq;
using System.Xml.XPath;

Then you can call XPathSelectElement or XPathSelectElements:

1using System;
2using System.Xml.Linq;
3using System.Xml.XPath;
4
5var xml = XElement.Parse(@"
6<catalog>
7  <book id='bk101'>
8    <title>XML Developer's Guide</title>
9  </book>
10  <book id='bk102'>
11    <title>Midnight Rain</title>
12  </book>
13</catalog>");
14
15var title = xml.XPathSelectElement("//book[@id='bk101']/title");
16Console.WriteLine(title?.Value);

That works because the XPath extension methods operate on LINQ-to-XML objects.

The LINQ to XML Equivalent

The same query can often be expressed directly in LINQ:

1var titleLinq =
2    xml.Elements("book")
3       .FirstOrDefault(b => (string)b.Attribute("id") == "bk101")
4       ?.Element("title");
5
6Console.WriteLine(titleLinq?.Value);

LINQ can be more readable when:

• You are already writing C# query logic
• You want compile-time access to surrounding code structure
• The XML shape is fairly regular

When XPath Is a Better Fit

XPath is often better when:

• You already know the query in XPath form
• The XML navigation path is deeply hierarchical
• You need expressive node-selection syntax quickly

For example, selecting all titles:

1foreach (var node in xml.XPathSelectElements("//book/title"))
2{
3    Console.WriteLine(node.Value);
4}

That is concise and familiar if you already think in XPath.

When LINQ Is a Better Fit

LINQ to XML is often the better fit when your selection logic needs to blend naturally with normal C# conditions, projections, or object construction. In those cases, staying inside one language style can be easier to debug than mixing C# flow with XPath string expressions.

It is also easier to refactor with normal C# tooling because more of the query lives in typed code rather than in XPath string literals.

Namespaces Need Extra Care

XML namespaces are where many XPath examples break. If your XML has a namespace, you need an XmlNamespaceManager:

1using System.Xml;
2
3var xmlNs = XElement.Parse(@"
4<root xmlns='urn:books'>
5  <book>
6    <title>Namespaced Title</title>
7  </book>
8</root>");
9
10var nav = xmlNs.CreateNavigator();
11var manager = new XmlNamespaceManager(nav.NameTable);
12manager.AddNamespace("b", "urn:books");
13
14var namespacedTitle = xmlNs.XPathSelectElement("//b:book/b:title", manager);
15Console.WriteLine(namespacedTitle?.Value);

Without the namespace manager, the XPath query will usually return nothing and look mysteriously broken.

LINQ and XPath Together

You do not have to choose one approach globally. A common pattern is:

• Use LINQ to XML for general manipulation and construction
• Use XPath for specific path-heavy selection logic

That is often the most pragmatic mix in real codebases.

The important thing is to avoid forcing one style into places where the other is much clearer.

Common Pitfalls

• Forgetting to import System.Xml.XPath, so the XPath extension methods are missing.
• Using XPath without accounting for XML namespaces.
• Treating XPath and LINQ as mutually exclusive when they can coexist.
• Writing very complex XPath when a short LINQ query would be clearer in C# code.

Summary

• 'XElement can use XPath through extension methods in System.Xml.XPath.'
• Use XPathSelectElement and XPathSelectElements for XPath-based queries.
• LINQ to XML is often clearer for regular C#-centric XML traversal.
• XML namespaces must be handled explicitly in XPath queries.
• Choose the style that makes the query easiest to understand and maintain.

The best choice is usually the one that keeps the XML logic readable to the next developer. That usually pays off fastest.