Information
The topic you requested is included in another documentation set. For convenience, it's displayed below. Choose Switch to see the topic in its original location.

XmlDocument.InnerXml Property

Gets or sets the markup representing the children of the current node.

Namespace: System.Xml
Assembly: System.Xml (in system.xml.dll)

public override string InnerXml { get; set; }
/** @property */
public String get_InnerXml ()

/** @property */
public void set_InnerXml (String value)

public override function get InnerXml () : String

public override function set InnerXml (value : String)

Not applicable.

Property Value

The markup of the children of the current node.

Exception typeCondition

XmlException

The XML specified when setting this property is not well-formed.

Setting this property replaces the children of the node with the parsed contents of the given string. The parsing is done in the current namespace context.

InnerXml removes redundant namespace declarations. As a result, numerous cut and paste operations do not increase the size of your document with redundant namespace declarations. Consider the following XSL document:

<xsl:stylesheet version="1.0" 
      xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
     <xsl:template match="stock">
         ...
     </xsl:template>
    </xsl:stylesheet>

The InnerXml property on the stylesheet node returns the following string:

<xsl:template match="stock" 
      xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
     ...
    </xsl:template>

Notice the additional xmlns:xsl namespace declaration which is used to preserve the node identity. If you re-insert this inner XML string, you will get back your original document. In other words, InnerXml recognizes that the xmlns:xsl namespace declaration is redundant, given that the parent xsl:stylesheet element already has the xmlns:xsl namespace delcaration, and therefore removes it.

If you move InnerXml from a document with no default namespace to a document with a default namespace, the behavior is a little different. Consider the following XML string:

<test>
      <item>123</item>
    </test>

InnerXml returns a plain XML string with no namespace declarations:

<item>123</item>

If you then insert this string into a document that does have a default namespace, such as the following:

<test2 xmlns="urn:1">
    </test>

InnerXml parses the string in context, and the new nodes pick up the urn:1 namespace. The result looks like this:

<test2 xmlns="urn:1">
      <item>123</item>
    </test>

Now when you ask for the InnerXml you get back the following:

<item xmlns="urn:1">123</item>

If you explicitly want the inserted item to preserve the fact that it came from a document that had no namespace then you need to manually add an xmlns= "" declaration and insert the resulting string:

<item xmlns="">123</item>

The net effect of all this is as follows:

  1. Cutting and pasting InnerXml among documents that do not use namespaces is clean and simple and does not create "xmlns" redundancy in your strings.

  2. InnerXml can also be used to cut and paste between documents which have more than one namespace (that is XSL stylesheets).

  3. xmlns:xsl declarations automatically appear in your strings and disappear in your node hierarchies.

  4. In the case where you are moving InnerXml from a document that has no default namespace to a document that does have a default namespace, the new nodes will pick up the new default namespace.

If InnerXml is set with text containing entity references that are not currently defined in the document, the resulting tree will contain empty EntityReference nodes.

This property is a Microsoft extension to the Document Object Model (DOM).

Windows 98, Windows Server 2000 SP4, Windows CE, Windows Millennium Edition, Windows Mobile for Pocket PC, Windows Mobile for Smartphone, Windows Server 2003, Windows XP Media Center Edition, Windows XP Professional x64 Edition, Windows XP SP2, Windows XP Starter Edition

The Microsoft .NET Framework 3.0 is supported on Windows Vista, Microsoft Windows XP SP2, and Windows Server 2003 SP1.

.NET Framework

Supported in: 3.0, 2.0, 1.1, 1.0

.NET Compact Framework

Supported in: 2.0, 1.0

XNA Framework

Supported in: 1.0
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

Show:
© 2014 Microsoft