Reference Issues With MSXML6.DLL with VB6 On Win 10 Pro/Single Language

We have a legacy app using DomDocument30 data type. It's a long way to update it to DomDocument60, so I don't want to discuss that over here.

What I do want to discuss is a strange phenomenon I have been observing on Windows 10.

Earlier we used to develop the app inside a VM having XP and everything was smooth. We decided to ditch that and move to Win 10 as the development environment, and once we made the switch, this problem has been nagging us all the time.

When I open the project in the IDE, it automatically sets a reference to the C:\Windows\SysWOW64\MSXML6.dll
If I try to compile the project right away, I get compilation errors for the DomDocument30 type used in the code.
OK, so maybe the latest MSXML6.dll does not use these types (it uses DomDocument60)

I have a copy of the MSXML6.dll saved from a production backup. I add a reference to this file. Thish being an older version, has the DomDocument30 type. Everything works fine now.

After finishing work, when I stop VB6, re-start VB6 and open the project again, it again shows reference to C:\Windows\SysWOW64\MSXML6.dll, instead of the reference I had set in its earlier run.

WHat gives?

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.