Using the right version of MSXML in Internet Explorer

Using the right version of MSXML in Internet Explorer

Rate This
  • Comments 46

I’ve been working closely with the IE team leading up to the release of IE7 and looking at the use of XML in the browser.  During this investigation one thing has become immediately obvious – there is a lot of confusion around the versioning story for MSXML and how to instantiate the “right” MSXML object in the browser.  Here’s a quick snippet of code that I’ve seen all too often out on the web:


What NOT to do... 


if (Web.Application.get_type() == Web.ApplicationType.InternetExplorer) {

        var progIDs = [ 'Msxml2.DOMDocument.6.0', 'Msxml2.DOMDocument.5.0', 'Msxml2.DOMDocument.4.0', 'Msxml2.DOMDocument.3.0', 'Msxml2.DOMDocument' ]; // MSXML5.0, MSXML4.0 and Msxml2.DOMDocument all have issues - be careful when using.  Details below.


        for (var i = 0; i < progIDs.length; i++) {

            try {

                var xmlDOM = new ActiveXObject(progIDs[i]);

                return xmlDOM;


            catch (ex) {




        return null;



The code iterates through the "progIDs" array and instantiates the highest version MSXML DOM that is available on the machine and returns it to the caller (see below for details on which versions ship where).  This has at least a few implications:

  • Compatibility – We do our best to maintain compatibility across versions of MSXML, however earlier versions of MSXML like MSXML 3 and MSXML 4 were implemented during the “wild west” of the XML emergence and we’ve learned a lot since then.  In addition, MSXML5 for Microsoft Office Applications was targeted specifically at Office scenarios.  Sometimes we do need to make design or implementation changes that affect behavior across MSXML versions.  By iterating through the versions of MSXML you open your app up to more potential risk of “finding” one of the differences unexpectedly. 
  • Robustness - We can't fix every bug in every version so we've targeted MSXML6 (our newest) and MSXML3 (our most broadly deployed) versions of MSXML where we'll make the biggest investments.
  • Test cost – The more versions of MSXML your application potentially depends on means more versions to test your application with before you can ship it to your customers. 

My goal for this post is to give a quick history of MSXML lifecycle and versions, provide details with an example on implementing best practices with MSXML on the web, and talk about a couple key things to watch out for.


If you want the full story please read on, but if you’re short on time and want the quick scoop here it is in 4 bullets: 

  • Use MSXML 6.0 - it is “in the box” on Vista and available for download on Win2k, XP, and 2003.  It has the best security, performance, reliability, and W3C conformance
  • MSXML 3.0 is our preferred “fallback” - It is installed on every OS from a fully patched Win2k SP4 installation on up, so it requires “zero-deployment” and is serviced regularly with the OS
  • MSXML 4.0 was released to the web about 5 years ago, but at this point has been superseded by MSXML 6.0 and is only intended to support legacy applications
  • MSXML 5.0 for Microsoft Office Applications is purpose-built for Office applications and isn’t intended for broad deployment.  Internet Explorer 7 actually has the MSXML5 components "off-by-default" in the Internet zone so your customers will get a goldbar for each MSXML5 control on a page if your code tries to instantiate it.  The best recommendation is to avoid MSXML5 in your web apps (only machines with Office 2003 or higher will have it, anyway.).

MSXML Lifecycle & History 


OK, the full story requires a little bit more context – so let’s cover the different versions of MSXML, where they ship, and what the long term strategy is. 


Over the long run, the goal is to have our customers move their applications to MSXML6.  In terms of deployment, we want to ship our technology "in-the-box" with the operating system so that page authors and app developers can take advantage of it with zero deployment.  However, our customers have told us they want symmetrical XML APIs on all supported OS platforms, so we still need a way to get the newest XML technologies to our downlevel OSes (Win2k, Win XP, and Win 2k3).  


MSXML6 will be part of the Vista operating system when it releases, but requires a redistributable package to be installed downlevel.  We’d like to get MSXML6 “inlined” in the next service pack of each of the downlevel OSes, but we need a strong business case to do so.  So in the short and medium term we will continue to ship a redistributable package for MSXML6 that can be installed on downlevel operating systems.  We'll try to get a post up on the benefits of moving to MSXML6 sometime soon.


As much as we'd love everyone to be on MSXML6 today, we realize the migration can take some time.  So we're continuing to invest in MSXML3 to support existing applications and applications that have zero deployment requirements.  MSXML3 doesn't have all the improvements in MSXML6, but developers should consider it a robust and stable platform for MSXML applications.  MSXML3 is already part of the operating system on a fully patched Win2k SP4 installation and higher so in general no deployment to the client is required.  Going forward, MSXML3 updates will come out in each of the OS service packs.  MSXML3 SP7 is the last update to MSXML3 that should ship in redistributable form and in the future no redistributable package should be necessary for our partners and customers to use MSXML3 functionality.


MSXML4 was a predecessor to MSXML6 but hasn't ever shipped in the operating system.  MSXML6 is a significant step forward in terms of reliability, security, W3C and System.Xml compatibility, and it also has support for native 64-bit environments.  Right now we are investing much more heavily in MSXML6 and MSXML3 and we're encouraging our customers to move to 6 when possible and 3 when necessary.


Finally, anyone using MSXML5 who isn’t writing applications specifically targeted at Microsoft Office 2003 or Microsoft Office 2007 should migrate to MSXML6.


The details


Once you pick a version of MSXML to use, how do you do it effectively?  MSXML ships side-by-side with version dependent ProgIDs.  That means two things:

  • Versions are isolated – For example, if you’ve already got MSXML3 (msxml3.dll) on your machine and you install MSXML6 (msxml6.dll) it will lay down side-by-side in System32 and will have no effect on any application that uses MSXML3
  • ProgIDs are locked to their version - If you want your app to take advantage of your new MSXML6 installation you need to instantiate your MSXML objects using the MSXML 6.0 ProgIDs.

var xmlDOM = new ActiveXObject('Msxml2.DOMDocument.3.0') //uses MSXML 3.0

var xmlDOM = new ActiveXObject('Msxml2.DOMDocument.6.0') //uses MSXML 6.0

One related note - service packs of a particular version of MSXML are not side by side and will upgrade that version of MSXML to the service pack version.  For example, if your computer is running MSXML3 SP5 and you install MSXML3 SP7, all applications that use MSXML3 will automatically be upgraded to run on 3 SP7.


Ideally, customers should standardize on MSXML6, but as mentioned above legacy applications or zero-deployment requirements may block full migration to MSXML6 in the short run.  In this case there are two tensions that need to be balanced – functionality and test costs.  This essentially leads to two options:

  • Try MSXML6 and fallback to MSXML3 – MSXML6 has some improvements that aren’t in MSXML3 such as support for XSD schema, and improved stability, performance, and security.  So your app may try out MSXML6 if it is on the box and then “fallback” gracefully.  Just remember to test your app with MSXML6 and with MSXML3 so you aren’t surprised when you release your application.  Here’s a quick example:

if (Web.Application.get_type() == Web.ApplicationType.InternetExplorer) {

        var progIDs = [ 'Msxml2.DOMDocument.6.0',                                                   'Msxml2.DOMDocument.3.0'];


        for (var i = 0; i < progIDs.length; i++) {

            try {

                var xmlDOM = new ActiveXObject(progIDs[i]);

                return xmlDOM;


            catch (ex) {




        return null;


  • Standardize on MSXML3 with an eye towards MSXML6 in the future – This limits functionality somewhat to what is in MSXML3 but also keeps down test costs.  I’ll try to post something in the future about writing MSXML3 apps that should upgrade more easily to MSXML6 (and beyond).

A couple things to watch out for

  • MSXML6 has security sensitive features “off-by-default” while MSXML3 has some security-sensitive features “on-by-default” to avoid problems with backwards compatibility.  Check out the SDK for more details. 
  • Use of XSD schema - MSXML3 does not have support for Xml Schema (XSD 1.0) so applications that depend on XSD will need to use MSXML6 directly.  There are a few changes from MSXML4 and MSXML5 in the XSD implementation in MSXML6 to be more conformant with the W3C specification and more compatible with System.Xml in .Net 2.0 so some apps may need to do a little work during upgrade.  See the SDK for more details.
  • Default Query Language - When you are querying the DOM with SelectNodes or SelectSingleNode the default selection language in MSXML6 is XPath while the default selection language in MSXML3 is XSLPatterns.  To switch MSXML3 to the standard XPath 1.0 query language set the second-level DOM property Selection Language like this - xmlDoc.setProperty("SelectionLanguage", "XPath"); see our SDK for more details.
  • Version Independent ProgIDs – There’s a lot of confusion around the “version-independent” ProgID for MSXML.  The version-independent ProgID is always bound to MSXML 3 (a lot of people think it picks up the latest MSXML that is on the box).  This means the version independent ProgID and the “3.0” ProgIDs will return the same object.  For example both statements in the following code will return an MSXML 3 DOMDocument:

var xmlDOM = new ActiveXObject('Msxml2.DOMDocument.3.0')


var xmlDOM = new ActiveXObject('Msxml2.DOMDocument')

  • Older ProgIDs - Stay away from ProgIDs that end in suffixes lower than “3.0”.  In particular some older operating systems have MSXML 2.6 on them, however these ProgIDs are “kill-bitted” in the recent MS06-061 Security patch
  • MSXML2 vs. Microsoft namespace – I’ve also seen a lot of code that instantiates the “Microsoft.XMLHTTP” ActiveX object rather than the MSXML2.XMLHTTP.3.0 or MSXML2.XMLHTTP.6.0 if you’re using 6.0.  The “Microsoft” namespace is actually older and is only implemented in MSXML3 for legacy support.  It’s unfortunate we used the “better” name on the older version, but stick to the “msxml2” namespace when instantiating objects.

As always, I'd love to get some feedback from people so if you have questions, comments, or random thoughts you'd like to share please comment here or mail me directly (email link above).


Adam Wiener

Lead Program Manager

Data Programmability/XML Technologies

  • pwb, using the 'Msxml2.XMLHTTP.3.0' ProgID will give you support on Win2k SP4 and up and IE 6 or IE 7.  

    IE7 also have support for 'native' XMLHTTPRequest that can be used without instantiating ActiveX objects.  Check out this post from the folks in IE for good cross-browser support -

    (Just one note that the example in the IE page uses an older ProgID in the ActiveX case - you should use 'Msxml2.XMLHTTP.3.0')

  • I authored pages that runs well on MSXML 3 and 4. They die miserably in 6. The key area is, my XSL xsl:incude other XSLs, and it seems it fails in 6. Is there any place I can find documentations and resources to tackle these problems?

  • PS. I've read

    and my code already reads

       doc.setProperty("NewParser", true ); // 4.0 only

       doc.setProperty("AllowXsltScript", true);

       doc.setProperty("AllowDocumentFunction", true);

       doc.resolveExternals = true;

    but I keep getting errors like

    Named template 'entities' does not exist in the stylesheet.

    (my main xsl has a xsl:inlude to an entites.xsl)

  • Adam Wiener has a blog post that explains the often confusing issue of which version of the MSXML parser...

  • Our AJAX application was trying to instantiate msxml2.xmlhttp.5.0, then falling back to msxml2.xmlhttp.3.0. After installing the MS06-061 Security patch we were no longer able to read the responseText of our XHR objects using xmlhttp.5.0 when the http status was 400.

    This forced us to change to either msxml2.xmlhttp.6.0 or msxml2.xmlhttp.3.0 objects (for future releases), but breaks all of our existing MS Office customers with the security patch installed.

    The existing, functioning file @ Program Files/Common Files/Microsoft Shared/OFFICE11/msxml5.dll was replaced with version 5.10.2930.0.

    Has anyone else had problems with this?

  • What about IE5.0 and Win9x?

    The list at makes it even more confusing to me. From that it seems IE5.0x does not even support MSXML2 out of the box?

  • Hi Michael, I'm not sure why you would be expecting a response body in the 400 case ("bad request" per   Does it contain error information?  If you send us a little repro of your code we can take a quick look - use the email link at the top of the page to get in touch with us directly.  If you can also give us your client / server OS and what web server you're running against that would be great.

    Best Regards,

    Adam Wiener

    Lead Program Manager

    XML Technologies / Data Programmability

  • Hi Erik, in general Win9x is no longer in support - see for details.  

    In terms of what IE will support and what ships in the box with IE are two different things.  For example IE6 ships with MSXML3 (an old version) but will support MSXML3, 4, 5, and 6 (our guidance is to use 3 or 6).  As I mentioned above our goal is to distribute MSXML through Windows so when a new IE hits your machine, scripts in web pages will already be able to take advantage of the latest and greatest MSXML available.

    As for KB 269238 I agree it's confusing - I'll work on getting that cleaned up so it reflects the information that we've got here in the blog.

    Best Regards,

    Adam Wiener

    Lead Program Manager

    XML Technologies / Data Programmability

  • Just a note to everyone - I touched based with Alex offline and we figured out the trouble with his app using MSXML6.  MSXML6 was fine - there was just one code path where the critical configuration (ResolveExternals=true) was omitted to enable stylesheet inclusion in MSXML6.  Thanks to Alex for investigating the issue to help support MSXML6!

  • I was just wondering on how to determine what version the xmlhttprequest.responsexml would be using in IE7.

    As using the code to test for v6 and v3 works, if the v6 .dll is instantated for the document, it seems that it throws an  "It is an error to mix objects from different versions of MSXML." when attempting to place a clone of a responsexml subnode into the v6 created document.

    The code works if the v3 is used in the javascript to create the document, and import nodes from the responsexml.

  • Thank you very much for this article. Most of the Ajax frameworks I saw instantiate MSXML rather incorrectly, this article brings light to this issue.

  • I am encountering the exact same as Carl above. I have MSXML 3-6 installed on my machine. MSXML 3 is set as the default in the registry. Is that why the responseXML from the native XmlHttpRequest is an MSXML 3 document? Is there any way to choose what version gets returned other than changing the registry?

    The same code that breaks in IE7 with MSXML6 works with IE6 and MSXML 4 & 5. I only downloaded MSXML6 after installing IE7.



  • While the inclusion of a native object for xmlhttp is preferred to the ActiveX method, I would like to see this being taken further with a native xmldom object too. The reason for this is to solve the problem that Carl comments on. My situation is as follows:

    My xmldom object is created via ActiveX and thus has to have a version specified while my xmlhttp request on IE7 uses the native object, because there is no way to detect the version of msxml that is being used there is a case where an xmldom object and the xmlhttp object will be created by using different versions.

    Yes, there are solutions (some may call them 'hacks') to resolve the problem, but in essence (and imo, of course) MS has shown a lack of vision when only porting xmlhttp to native.

    Until both xmldom and xmlhttp are both native, I will stick with forcing all IE versions to use ActiveX.



  • There's an entry on IEBlog that provides some suggestions as to how to best do xmlhttprequests:

    My question is...  wouldn't they be better off using Msxml2.XMLHTTP.6.0 / Msxml2.XMLHTTP instead of Microsoft.XMLHTTP?

    Also, I have a question about this:

    It suggests that Microsoft.XMLHTTP is bound MSXML 2.  It makes no mention of whether or not Msxml2.XMLHTTP is also bound to MSXML 2 (which would mean that two things would be bound to it), let alone whether or not it's bound to MSXML 1.

    If it's not bound to either, how can Msxml2 be version independent?  It's not bound to anything greater than MSXML 3, per this blog entry, and if it weren't bound to anything less than MSXML 3, either, it would seem that it is, in fact, quite "version dependent".

  • Necesito con urgencia una versión mas reciente de MSXML para poder trabajar e instalar las actualizaciones mas recientes.  gacias.  

Page 2 of 4 (46 items) 1234