I’ve said it before and I’ll say it again: .NET is a ghetto. It’s my experience that once your application becomes non-trivial, there is no tried-and-true way of accomplishing a given task.
You either have to piece together what feels like desparate code in order to accomplish the most common of use cases. Case in point is using XPath to read data in XML.
Say you have this XML response:
Using C#, parsing this data should be an easy task - right? You should be able to do something like this?
But does that work in .NET C#? No.
Why? It doesn’t work because the XML response has a namespace separating the key data elements. Here the XML namespace is:
So what are your options:
You really only have two options when confronted with this challenge. The first is to use XMLNamespaceManager. I don’t care for that route as you’ll see below.
The final option is to strip the Namespaces using Regex. I prefer this route and you’ll see why.
When using XPath in .NET (via SelectNodes or SelectSingleNode) on XML with namespaces you need to:
You do so in a similar fashion as below:
This gets you the data, but it’s clumsy and has several disadvantages. First, if you don’t control the web service (which many people don’t), the namespace could change on you at anytime.
When that happens your hardcoded namespace WILL break and you will have production downtime. Second, you can’t reuse XPath that was previously valid. Finally, the namespaced XPath expression is less readable and therefore, less maintainable.
The XPath implementation in SelectNodes and SelectSingleNode should really be more flexible. Using familiar methods should not shock developers or lead to unmaintainable code. It simply shouldn’t.
Strip The Namespaces Using Regex
Regex is like violence - if it doesn’t solve your problems, you are not using enough of it. Generally, I don’t condone the use of unnecessary Regex.
This isn’t one of those scenarios. Here, Regex was not only necessary, it was downright welcomed:
Here, we remove any XML Namespace (xmlns) declaration before loading the XML. Once you do that, you can read the XML using the XPath expression you expected to use in the first place.
The pros are quick and apparent. First, your application won’t break if the owner of the web service needs to change their namespace (this could easily happen). Second, you can reuse previously developed XPath expressions without issue. Finally, the code is simply more readable - one to one - with the original XPath expression.
Really hope this helps save someone some much needed development time. Wish I had this article, it definitely would have saved me time.
Code Long & Prosper!