If you want to use MSXML2 v. 3.0 then reference msxml3.dll instead of msxml6.dll and you should be fine.


Microsoft cleaned up the chaos they ran into on "Windows XP era" OSs. A decision about version independent ProgIds meant they had to go to a private assembly in order for v. 4.0 to co-exist with v. 3.0 on a machine. They should have tried the model used for ADO version compatibility but they either didn't know about it or maybe there were reasons why that wasn't practical. Instead they took another path.


I believe your attempts to get around the situation you found yourself in raised an immune response in Windows. You can't just copy system files around between OSs.

Most likely you have dumped an incorrect DLL into some private location and then force-registered it via regsvr32.exe or selecting it by file path in the VB6 IDE's References dialog. System file locations and COM registrations are protected.

If you had dumped the foreign file into System32 Windows would replace the file with the proper one, if elsewhere it should be left alone. If you had changed the registry entries for the library Windows will correct them to point to the restored system file.

Once Windows has repaired itself a run of VB6 on a Project with faulty entries will be corrected to reflect the actual location of the system library.