Breaking changes in MSXML6

| 8 Comments | 1 TrackBack

Just released Microsoft Core XML Services (MSXML) 6.0 introduces some security-related breaking changes in XML and XSLT processing, but MSXML6 SDK documentation isn't released yet (expected next week) and can be found nowhere on the net, so you might have a hard time wondering why basic things stop working after upgrading to MSXML6. Here is a bit of information that might be helpful.

MSXML6 is aligned with .NET 2.0 with regard to "secure by default" principle. That means that both MSXML6 and .NET 2.0 by default prohibit DTD (even internal subset) in XML documents, document() function and embedded scripts (ms:script) in XSLT stylesheets. Here is how you can enable processing these things if your XML or XSLT comes from a trusted source.

To allow processing DTD you set "ProhibitDTD" secondary property to false before loading XML:

var xmlDoc = new ActiveXObject("Msxml2.DOMDocument.6.0");
xmlDoc.async = false;
xmlDoc.validateOnParse = false;            
xmlDoc.setProperty("ProhibitDTD", false);           

To enable document() function and embedded scripts in XSLT stylesheets you set "AllowDocumentFunction" and "AllowXsltScript" secondary properties to true, no matter before or after loading stylesheet, but before running a transformation:

var xslDoc = new ActiveXObject("Msxml2.DOMDocument.6.0");
xslDoc.async = false;
xslDoc.validateOnParse = false;            
xslDoc.setProperty("ProhibitDTD", false);           
xslDoc.setProperty("AllowDocumentFunction", true);
xslDoc.setProperty("AllowXsltScript", true);      

Hope that helps. And keep an eye on MSDN XML Developer Center for MSXML6 SDK with complete documentation to be released soon.

Related Blog Posts

1 TrackBack

TrackBack URL:


one other thing,

to get xsl:import and xsl:includes to work properly, must set "resolveExternals" to true.

Thanks a lot for confirming that KB815112 still applies.

Kristofer, I've been told that KB815112 still applies, even with MSXML6.

I see. Ok, I'll check out what's the status of the issue.

Oleg, thanks for the info. I would much rather not use MSXML from .NET, but we have a legacy COM component that uses it (and returns MSXML instances) which we need to call from .NET.

Kristofer, I don't think something has changed. Anyway, with .NET 2.0 and XslCompiledTransform what would be a reason to use MSXML in .NET applications?

Would you happen to know if MSXML6 solves the issue of calling MSXML from .NET as described in KB815112?



Great information. This is one of those things that could take days to figure out on your own.

As always, I apprecation the knowledge sharing.

Leave a comment