PRB: Automation of Office Using #import Can Fail if Multiple Versions of Office Are Installed (301321)



The information in this article applies to:

  • Microsoft Office XP Developer
  • Microsoft Office 2000 Developer
  • Microsoft Office 97 Developer Edition

This article was previously published under Q301321

SYMPTOMS

A developer who uses the #import directive in Microsoft Visual C++ to perform automation to an Office product may encounter errors when the following occurs:
  1. A Visual C++ (VC) application uses the #import directive to automate a version of Office (such as Office 97) that is installed on a computer.
  2. A later version of Office (such as Office 2000), or another application that uses a later version of Visual Basic for Applications (such as Visio 2000) is installed, without uninstalling the previous version.
  3. The VC application attempts to automate the older version of Office. Errors begin to occur in the VC application. Warnings may include the following error messages:
    Invalid argument
    -or-
    Method not found

CAUSE

By default, the Visual C++ #import directive uses early-bound interfaces to perform automation. In order for this process to be successful from an out-of-process application, the interfaces must be marshaled across the process boundary by the operating system. The operating system uses the type library of the target application to determine how to marshal the interfaces.

When more than one version of Office is installed on a computer, multiple versions of the type library are installed and registered. When it searches for marshalling information, the operating system uses the highest version of the type library that it can find. The marshalling information that it finds may contain new properties and methods, and may not always be compatible with the older version of the application. This is most often seen with secondary components, such as the Microsoft Office Common Components (MSO) and the Visual Basic for Applications Extensibility library (VBAEXT).

RESOLUTION

To work around this issue, late-bound interfaces (that is, interfaces that communicate through IDispatch) should be used to automate Office if multiple versions may be present. Because the IDispatch interface does not change with different versions of Office, the marshalling information that is found by the operating system for this interface is always correct.

The Microsoft Foundation Classes (MFC) ClassWizard provides an easy way to generate wrapper classes that use IDispatch to automate Office applications. You can also use the IDispatch interface directly, although this is somewhat more difficult than using MFC's wrapper classes.

STATUS

This behavior is by design.

REFERENCES

For additional information on automation of Office if more than one version is installed, click the article numbers below to view the articles in the Microsoft Knowledge Base:

244167 INFO: Writing Automation Clients for Multiple Office Versions

247579 INFO: Use DISPID Binding to Automate Office Applications Whenever Possible

For more information on automation of Office from MFC or by using IDispatch directly, see the following Knowledge Base articles:

178749 HOWTO: Create Automation Project Using MFC and a Type Library

216686 HOWTO: Automate Excel From C++ Without Using MFC or #import


Modification Type:MajorLast Reviewed:12/12/2003
Keywords:kbAutomation kbnofix kbprb KB301321