Article ID: 244167 - View products that this article applies to.
This article was previously published under Q244167
When you develop projects that automate Office applications, you may choose to reference an Office type library to perform early binding, or to provide information about the members of the particular object model. These members include the properties, events, and methods that are supported by that version of Office, and the parameters that are needed to call those functions at run time. The actual implementation of members may differ from version to version as the Office object model is changed to support new functionality.
This article discusses the general implications of building Automation clients that work with more than one version of Office and explains the differences that binding can make in these situations.
Office applications that are tested and compiled with earlier versions of a type library continue to work, unchanged, when end users of your product upgrade their Office installations to a more recent version. In this way Office provides backward compatibility.
However, applications that are tested and compiled with the type libraries of more recent versions of the Office application may not work with earlier versions of Office. Office type libraries are not binary compatible and, with each new Office version, may be modified to include new functions and interfaces. Functionality is implemented among the members of the new version that is not included in the earlier version. New methods are added to the end of the list of functions for any particular object interface, so that the previous members are located in the correct place with respect to the beginning of the interface and can be reached by existing Automation code. Because earlier versions of Office do not know about these new members, they fail if you try to access them.
If you do need to use functionality in a newer version of Office, but you are developing a project that must work on systems that contain more than one version, you should use late binding to make the call. When you use late binding, you instruct your application to use IDispatch for a particular object's interface. GetIDsOfNames is used to locate the dispID of the specific member method you want to use, and Invoke is used to make the Automation call.
To summarize, if you are developing an Automation client that you intend to work with multiple versions of an Office application, you should:
For example, if you have an existing Microsoft Visual Basic project that was compiled on a computer with Microsoft Word 97, that project runs correctly against Word 97, Word 2000, Word 2002, Microsoft Office Word 2003, and Microsoft Office Word 2007. If you later install Word 2000, then the next time you open the Visual Basic project, the project reference auto-updates to the Word 2000 Object Library. If you then recompile the project using the Word 2000 library, the code may no longer work with Word 97. To correct this problem, clear the reference to the new library and explicitly browse for and select the older type library. Alternatively, you can use late binding so that this auto-update issue does not apply. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:
(https://support.microsoft.com/kb/242375/ )PRB: Office 97 Automation Client Fails After Re-compilation with Office 2000 or Office XP Type Library
For additional information about working with multiple versions of Office, see the following article in the Microsoft Knowledge Base:
245115For more information about early and late binding when using Automation, see the "CreateObject Function" topic in the Visual Basic Help Index.
(https://support.microsoft.com/kb/245115/ )INFO: Using Early Binding and Late Binding in Automation
(c) Microsoft Corporation 2001, All Rights Reserved. Contributions by Chris Jensen, Microsoft Corporation.
Article ID: 244167 - Last Review: April 17, 2007 - Revision: 7.1