Just finished my new LINQ to XML explorer – have a try!

[SetTrend]

I am proud to announce I just finished my new LINQ to XML Explorer.

The .NET LINQ to XML Explorer tool makes it easy to browse an XML document tree created by Microsoft LINQ to XML.

With the .NET LINQ to XML Explorer tool you can now examine the result of how LINQ to XML converts XML documents into object trees without stepping through XElement, XNode and XAttribute object tree navigation methods during Visual Studio debugging sessions.

Just enter arbitrary XML content into the .NET LINQ to XML Explorer tool's text editor, or even compose an XDocument document tree in C# code, and examine what is being created by .NET LINQ to XML.

Features

.NET LINQ to XML Explorer comes with a full-fledged text editor providing the following features:

• Copy/cut/paste text
• Drag & drop text and text files
• Find/replace text (you can even use regular expression search terms)
• Optionally show white-space characters in the tree
• Multilingual (currently, only US-English and German ressources are implemented – translations welcome)

NB: The current version of the .NET LINQ to XML Explorer tool is based on .NET 9.0.

How To Download

You can download the compiled .NET LINQ to XML Explorer tool from my repository following
Actions > Initial commit. > Artifacts > XDocumentExplorer.

[SetTrend]

I created this tool because LINQ to XML casts a few surprises when parsing/serializing XML. These (harmless) quirks struck my unit tests two weeks ago, and it took a while for me to realize the reasons for my assertions to fail. So, I decided to write a visual tool that's enlightening me about what is created by LINQ to XML to keep me from writing a number of unit tests that might fail due to false assumptions.

[SetTrend]

Today, I released a new XDocumentExplorer version.

The new XDocumentExplorer version now uses my new AxDa.EnhancedXmlWriter NuGet package for serializing a LINQ to XML document tree.

I created the AxDa.EnhancedXmlWriter package because the Microsoft XmlWriter implementation fails to correctly serialize white-space preserved XML. See #112343

To switch between both XML serializers, use the XDocumentExplorer options dialog:

[chrisoverzero]

I created the AxDa.EnhancedXmlWriter package because the Microsoft XmlWriter implementation fails to correctly serialize white-space preserved XML. See #112343

You seem to be confused: xml:space is a signal of intent to the XML processor, not to whatever code is creating the XML document.

[SetTrend]

I'm not sure if I can put this right:

If the XDocument tree contains XElements with xml:space="preserve", then I'd expect the serialized result to have white-space preserved within these XElement's content and not be different from the XDocument tree content.

If, however, the XmlSerializer adds or removes white-space to content within these XElements, then I suppose it's not me who is confusing things.

The truth is on the pitch 😉

[chrisoverzero]

Unfortunately, you expect something incorrect. That’s simply not what xml:space does or is for, by specification.

A special attribute named xml:space may be attached to an element to signal an intention that in that element, white space should be preserved by applications.
[…]
The value "default" signals that applications' default white-space processing modes are acceptable for this element; the value "preserve" indicates the intent that applications preserve all the white space.

With definitions given earlier:

[Definition: A software module called an XML processor is used to read XML documents and provide access to their content and structure.] [Definition: It is assumed that an XML processor is doing its work on behalf of another module, called the application.]

A processor is a reader. The code creating an XML document doesn’t change behavior after it writes an xml:space attribute.

[SetTrend]

I believe you are confusing stages in the life cycle of a document here:

When persisting an XDocument document object tree, stored in-memory, to a stream, the Microsoft XmlWriter alters the XML content in a way that you are not able to regain the original data from the persisted storage. It's simply like this:

XDocument content  !==  XmlWriter output

Serializing and deserializing documents should be a bijective operation. This is not the case for the Microsoft XmlWriter output. It's altering the document content and, thus, rendering wrong results. That's commonly called a "bug".

Let me give a simple example, explaining a similar (hypothetical) situation:

Given the following code:

File.WriteAllText(@"C:\test.txt", "a");

If the file written by the WriteAllText method contained

b

then this would not reflect the original data. In this example, it's clear that a != b. It's even clear to see the effect right in this text line I'm just writing. As you may recognize, I used two space characters before and after the unequality operator. And these two space characters are being persisted between serialization and deserialization. The number of white-space characters is not altered within code sections. So the Markdown serializer does it right – the Microsoft XmlWriter doesn't.