0

Background: VBA code for my working vba project (UserForm) resides in a single Excel file based on xml files (so a MSXML6.dll reference "Microsoft XML, v6.0" is necessary) for a restricted number of users in a network.

Until now all participants (as well as myself) use Office 2010 / Windows 7 which will be updated next year to Windows 8. One dislocated participant, however, got an exceptional update now, thus the library reference would have to show to C:\Windows\SysWOW64\msxml6.dll.

Task: Referring to Joao Pinho's comment MSXML2.DOMDocument60 crashes Excel I am aware, that - for a 64 bit version - I would have to code directly on the mentioned participant's computer in order to "remove the reference to Microsoft XML, v6, perform Browse within the VBE and point to the msxml6 in SysWOW64 and then select that, ensure that when selected it then says C:\Windows\SysWOW64\msxml6.dll."

Essential hint: For some reasons I have to change and maintain code regularly within one single excel file combining reference to the common MSXML6-version (now under System32) as well as the 64-bit version (under SysWOW64) and have no administrating permissions.

Questions:

  1. How can I do that without pitfalls?

  2. Are there essential differences between msxml6 versions or are they compatible?

    Note: The msxml6.dll files differ by version numbers: 6.30.7601.18980 up to 6.30.15063.0, which I couldn't find on any MS site (cf. https://support.microsoft.com/en-us/help/269238/list-of-microsoft-xml-parser-msxml-versions)

  3. Would it be possible to use a sysvow64 reference with the existing version of msxml6.dll?

  4. Would it be possible to use a sysvow64 reference with the higher version of msxml6.dll under my recent version of Excel/Windows? (Can I just copy the dll?)

Thanks in advance for a workable solution

Martijn Pieters
  • 1,048,767
  • 296
  • 4,058
  • 3,343
T.M.
  • 9,436
  • 3
  • 33
  • 57
  • 2
    You should look at using late-binding to MSXML to avoid the bit-wise issue when deploying across different client machines. E.g. `Dim obj As Object: Set obj = CreateObject("MSXML.DomDocument")` – Robin Mackenzie May 16 '17 at 09:13
  • @Robin, I'd prefer to find a solution with early binding, thanks though :-) – T.M. May 16 '17 at 09:18
  • 1
    Suspect you may need to maintain two versions of your file in that case. If someone opens the file on the wrong OS then you can use compiler constants to alert them to use the correct file: https://msdn.microsoft.com/en-us/library/office/gg264614.aspx – Robin Mackenzie May 16 '17 at 09:30
  • @Robin, the question is how to do that under the existing OS (see questions 3 or 4) because at the Moment I have no other version. – T.M. May 16 '17 at 09:37
  • Just to make the comment of @Robin-Mackenzie more precise :-) A MSXML6.dll reference to "Microsoft XML, v6.0" via late binding has to include the versioning GUID in CreateObject, i.e. "Msxml2.DOMDocument.6.0". "Msxml2.DOMDocument" without version suffix refers to "Microsoft XML, v3.0". **Example Late Binding MSXML6.dll** Dim oXDoc As Object Set oXDoc = CreateObject("Msxml2.DOMDocument.6.0") **Example Early Binding** Dim oXDoc As MSXML2.DOMDocument60 Set oxDoc = New MSXML2.DOMDocument60 – T.M. Aug 12 '17 at 17:59

0 Answers0