This article discusses and explains how COM (Component
Object Model) determines which version of an Office application is loaded when
you use Office Automation.
When a COM server is first installed or registered, it adds
entries to the registry that correspond with the server's programmatic
identifier (PROGID) and class identifier (CLSID). These registry settings allow
COM to retrieve information about a server, such as where the server is
installed, and enables you to automate the server. To illustrate, Excel 2000
has the Excel.Application version-independent PROGID and the
{00024500-0000-0000-C000-000000000046} CLSID. COM related registry entries for
Excel 2000 include the following:
HKEY_CLASSES_ROOT\Excel.Application\CLSID
Default Value: {00024500-0000-0000-C000-000000000046}
HKEY_CLASSES_ROOT\CLSID\{00024500-0000-0000-C000-000000000046}\LocalServer32
Default Value: C:\PROGRA~1\MICROS~1\Office\EXCEL.EXE /automation
By following the registry keys from the PROGID to the CLSID, COM
can learn where the Excel executable file is installed and start it for
Automation.
When you have multiple versions of Office installed and
you use Automation to one of the Office servers, the version that loads is
governed by these settings in the registry. For the most part, the rule is that
the last version that was installed is the version that loads with Automation;
however, Word exhibits behavior that differs from the other Office
applications. The different behaviors for each of the Office Automation servers
are described in the following sections.
Access, Excel, and PowerPoint versions 97, 2000, 2002, 2003, and 2007 Access, Excel, and PowerPoint modify these registry
keys during Office setup. When you automate one of these applications, the
version that is loaded is the version that was last installed.
Word 97 Word 97 modifies these registry keys during Office
setup. When you automate Word, if either Word 2000 or Word 2002 are installed,
Word 97 loads only if it was the last version installed.
Word 2000, 2002, 2003, and 2007 Word 2000, 2002, 2003 and 2007 modify these registry keys
during Office setup and each time Word starts. When you automate Word, the
version that is loaded is the version that was last started by the user or the
version that was last installed.
Additional Notes A common perception for Office Automation when you have
multiple versions of Office installed on a system is that you can dictate which
version loads by using a specific version-dependent PROGID (for example, that
"Excel.Application.9" loads Excel 2000, "Excel.Application.10" loads Excel 2002
and "Excel.Application.11" loads Office Excel 2003). However, this is not correct.
Excel 2000 and later versions of Excel share the same CLSID, so the version that loads with
these PROGIDs depends solely on which version was last installed.
For
testing purposes, developers can force a specific version of an Office
application to register by using the
/regserver switch on the command line. For example, to force an Excel
version to register without running setup, you can use a command line that
resembles the following:
"c:\program files\microsoft office\office\excel.exe" /regserver
Although you can implement this switch for testing and
development purposes, it is not recommended that you rely on this switch in
production scenarios.
For additional information about running multiple Office versions, or
side-by-side Office installations, click the following article number to view the article in the Microsoft Knowledge Base:
290576Â
(http://kbalertz.com/Feedback.aspx?kbNumber=290576/
)
OFFXP: Running Multiple Versions
of Microsoft Office