Thursday, September 25, 2008

Why we need different version of MSXML dlls installed?

While still supporting VB6 legacy system that reference to MSXML 4.0, user (and even layman like me) curious why some PCs have installed MSXML 6.0, yet still need to install MSXML 4.0 (or SP2). We thought this should have backward compatibility or new version should act as a superset of old version, as most of the Microsoft's products do.


From VB6 MSXML sample (you can get it here), if MSXML 4.0 is installed and "DllTest.dll" is registered and this app is ran, you will get:


if "DllTest.dll" is not registered on PC without MSXML 4.0 installed, you might get :

After "DllTest.dll" registration on PC without MSXML 4.0 installed, you will still get:

(you might get: "Object variable or With block variable not set" as well for some other cases)

Version-Dependent ProgIDs
Prior to version 4.0 of MSXML, there was a notion of version independent ProgIDs. This meant that you could write a script that instantiated an instance of MSXML, and when a new version of MSXML was installed on your machine, you automatically would get the new version. However, this sometimes created problems. Replacing one version of MSXML with another version of MSXML created situations where the user's program would stop working due to changes in the programming interface.

Since version 4.0 of MSXML, each version has a unique ProgID for each interface in MSXML. This means that when you are using a scripting language, you will not suddenly be using a much newer version than you were previously. This is a much better approach - specifying exactly which version you want to run against, then coding specifically for that version, and being certain that the version would not change when the user updates their machine means that MSXML applications are much more reliable.

There is a situation where you will automatically be using MSXML version 3.0. If the computer that is fully patched uses MSXML as part of a web application in Internet Explorer using the MIME viewer, you automatically will be using MSXML 3.0. If you are using MSXML via a scripting language, and if you specify a version independent ProgID (such as Msxml2.DOMDocument), then you will be using MSXML 3.0. However, if you are using MSXML via a scripting language, and if you specify a version dependent ProgID (such as MSXML2.DOMDocument.6.0), then you will be using the version of MSXML corresponds to the specified ProgID.

No comments: