Weird behaviour of the msxml .dll's

All of a sudden some of our clients experience the ActiveX component can't create object error when the program tries to instantiate a MSXML2.DOMDocument. We are talking about a VB6 app here that is written on a computer that sets a ref开发者_开发百科erence to msxml2.dll and no other xml-dll. When we issue a deployment we deploy msxml2.dll msxml2a.dll and msxml2r.dll every time and have never had any issues.

Not this time! It is as if the windows environment itself has changed and rejects the unregistering/reregistering process. Whatever I do I am unable to get the client computer to succesfully instantiate the MSXML2.DOMDocument. To make things even more strange: When I rename/unregister/delete all msxml2* files from the system32 folder, clients that do not experience the problem keep functioning, so they do not seem to need the .dll's! Usually this clients will have a mix of msxml3, 4 and 6 installed. I searched the hard drive and there are no other copies of msxml2 lurking around.

Can someone please help to get a start of a grip on this baffling problem?

EDIT: just a simple set doc=new MSXML2.DOMDocument is enough to cause the error.

---

Lots of libraries are system-managed now. Dumping things into System32 only gets you so far, since the "real" libraries live in the SxS Cache.

This is one reason why you want to use an approved deployment technique for them, and for MSXML this gets a little complicated unless you simply use the prescribed MSI packages (or those wrapped in an EXE) from Microsoft. MSXML 4 was also available in MSM and CAB formats for each update, which had more to do with the "SxS install" that was only supported for MSXML 4 (dropped as a bad idea in MSXML 6).

The good news is that all supported OSs except Server 2003 already include MSXML 6, so target that and you're home free with no deployment requirement:

MSXML6 is now in-band, MSI setup headaches should now (almost) be gone..

MSXML 3 is available on most Windows versions going back further, and can be deployed back to at least Win98: Microsoft XML Parser (MSXML) 3.0

Installation and component registration and servicing hasn't worked as you might think it does for a long time now. It is much safer to package your applications as MSI packages rather than using legacy scripted setup tools. Don't try to deploy bits and pieces of complex packages like MDAC and MSXML.

Which specific MSXML version are you doing early binding to? Keep in mind that if you use MSXML 4 this is sub-version specific (not all interfaces were binary compatible from service pack to service pack).

---

It is a good idea to always use version dependent ProgIDs instead of version independent ones. For example, I would suggest you to use Msxml2.DOMDocument.6.0 instead. Please refer to Using the right version of MSXML in Internet Explorer for more information.