Why does Office10 mso.dll file get installed on an Office11 system?

[Howard Kaikow]

On my J drive, I have a Win 2000 system that has Office 2003 installed, and
has never had an earlier version of Office installed. I find that the list
of available COM references in VS .NET 2003 includes references for both the
Office 10 object library and the Office 11 object library.

The reference for Office 10 is to G:\Program Files\Common Files\Microsoft
Shared\Office10, which is in an OS on the G drive in this multiboot system.

However, I also note that the system on the J drive has both J:\Program
Files\Common Files\Microsoft Shared\Office10 and
J:\Program Files\Common Files\Microsoft Shared\Office11, each of which has a
different mso.dll.

Looking at the Registry, I see typelib entries for

Microsoft Office 10.0 Object Library in G:\Program Files\Common
Files\Microsoft Shared\Office10\mso.dll
Microsoft Office 11.0 Object Library in J:\Program Files\Common
Files\Microsoft Shared\Office11\mso.dll

My questions include:

1. How did a reference to a never installed version of an Office object
library get included in the registry?
2. What is the purpose of the, apparently, spurious J:\Program Files\Common
Files\Microsoft Shared\Office10?

 

[Eric Lawrence [MSFT]]

It's possible that some component of Office didn't get rev'd and that's why
you see it. Also, you'll find that MSO gets installed by some nonintuitive
apps-- for instance, at least one version of Visual Studio installs MSO. I
don't know which version it uses, but I'd bet that VSNET uses MSO10.

--
Thanks,

Eric Lawrence
Program Manager
Assistance and Worldwide Services

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Eric Lawrence [MSFT]]

It's possible that some component of Office didn't get rev'd and that's why
you see it. Also, you'll find that MSO gets installed by some nonintuitive
apps-- for instance, at least one version of Visual Studio installs MSO. I
don't know which version it uses, but I'd bet that VSNET uses MSO10.

--
Thanks,

Eric Lawrence
Program Manager
Assistance and Worldwide Services

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Eric Lawrence [MSFT]]

It's possible that some component of Office didn't get rev'd and that's why
you see it. Also, you'll find that MSO gets installed by some nonintuitive
apps-- for instance, at least one version of Visual Studio installs MSO. I
don't know which version it uses, but I'd bet that VSNET uses MSO10.

--
Thanks,

Eric Lawrence
Program Manager
Assistance and Worldwide Services

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Eric Lawrence [MSFT]]

It's possible that some component of Office didn't get rev'd and that's why
you see it. Also, you'll find that MSO gets installed by some nonintuitive
apps-- for instance, at least one version of Visual Studio installs MSO. I
don't know which version it uses, but I'd bet that VSNET uses MSO10.

--
Thanks,

Eric Lawrence
Program Manager
Assistance and Worldwide Services

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Howard Kaikow]

It's possible that some component of Office didn't get rev'd and that's why
you see it.

There was nothing to rev. Office 2003 is the only version of Office that was
ever installed under the OS on J. A clean Win 2000 install last year.

Also, you'll find that MSO gets installed by some nonintuitive
apps-- for instance, at least one version of Visual Studio installs MSO. I
don't know which version it uses, but I'd bet that VSNET uses MSO10.

VS .NET uses whatever Word is installed (see experiment below).

There are two suspects:

1. The Stillimage program has registered "Microsoft Office Word" as the
winword.exe for Office 2003 on the J drive, AND it has registered "Microsoft
Word" as the winword.exe for Office 2002 on the G drive. I've changed the
latter to also point to the winword.exe on the J drive for Office 2003.

2. I've got VB.NET 2002 projects that were created in the OS on the G drive.
Some/many refer to the Office 10 library on G. Maybe VS .NET 2003 (installed
in the OS on J) took it upon itself to register a COM to the Office mso.dll
on the G drive?

In any case, a few hours ago, I performed the following experiment.

a. I created a Word macro using the sample code for the SolutionID property
of the SmartDocument object. This object is new for Office 2003. Code worked
as expected.

b. I then created a VB .NET 2003 project using that code. I automated Word,
including a reference to the Office 11 library on the J drive. Code worked
as expected.

c. I then made a copy of the VB. NET 2003 project, removed the reference to
the Office 11 library and added a reference to the Office 10 library on the
G drive. When I tried to run, as expected, I got build errors because the
Office 10 library knows nothing about the new object in the Office 11
library.

However, I told the build to continue despite the error and the code
executed correctly because the code creates a Word object, which defaulted
to Office 2003, even tho I had the wrong library (intentionally) referenced.
This worked because I have Option Strict Off.

 

[Howard Kaikow]

It's possible that some component of Office didn't get rev'd and that's why
you see it.

There was nothing to rev. Office 2003 is the only version of Office that was
ever installed under the OS on J. A clean Win 2000 install last year.

Also, you'll find that MSO gets installed by some nonintuitive
apps-- for instance, at least one version of Visual Studio installs MSO. I
don't know which version it uses, but I'd bet that VSNET uses MSO10.

VS .NET uses whatever Word is installed (see experiment below).

There are two suspects:

1. The Stillimage program has registered "Microsoft Office Word" as the
winword.exe for Office 2003 on the J drive, AND it has registered "Microsoft
Word" as the winword.exe for Office 2002 on the G drive. I've changed the
latter to also point to the winword.exe on the J drive for Office 2003.

2. I've got VB.NET 2002 projects that were created in the OS on the G drive.
Some/many refer to the Office 10 library on G. Maybe VS .NET 2003 (installed
in the OS on J) took it upon itself to register a COM to the Office mso.dll
on the G drive?

In any case, a few hours ago, I performed the following experiment.

a. I created a Word macro using the sample code for the SolutionID property
of the SmartDocument object. This object is new for Office 2003. Code worked
as expected.

b. I then created a VB .NET 2003 project using that code. I automated Word,
including a reference to the Office 11 library on the J drive. Code worked
as expected.

c. I then made a copy of the VB. NET 2003 project, removed the reference to
the Office 11 library and added a reference to the Office 10 library on the
G drive. When I tried to run, as expected, I got build errors because the
Office 10 library knows nothing about the new object in the Office 11
library.

However, I told the build to continue despite the error and the code
executed correctly because the code creates a Word object, which defaulted
to Office 2003, even tho I had the wrong library (intentionally) referenced.
This worked because I have Option Strict Off.

 

[Howard Kaikow]

It's possible that some component of Office didn't get rev'd and that's why
you see it.

There was nothing to rev. Office 2003 is the only version of Office that was
ever installed under the OS on J. A clean Win 2000 install last year.

Also, you'll find that MSO gets installed by some nonintuitive
apps-- for instance, at least one version of Visual Studio installs MSO. I
don't know which version it uses, but I'd bet that VSNET uses MSO10.

VS .NET uses whatever Word is installed (see experiment below).

There are two suspects:

1. The Stillimage program has registered "Microsoft Office Word" as the
winword.exe for Office 2003 on the J drive, AND it has registered "Microsoft
Word" as the winword.exe for Office 2002 on the G drive. I've changed the
latter to also point to the winword.exe on the J drive for Office 2003.

2. I've got VB.NET 2002 projects that were created in the OS on the G drive.
Some/many refer to the Office 10 library on G. Maybe VS .NET 2003 (installed
in the OS on J) took it upon itself to register a COM to the Office mso.dll
on the G drive?

In any case, a few hours ago, I performed the following experiment.

a. I created a Word macro using the sample code for the SolutionID property
of the SmartDocument object. This object is new for Office 2003. Code worked
as expected.

b. I then created a VB .NET 2003 project using that code. I automated Word,
including a reference to the Office 11 library on the J drive. Code worked
as expected.

c. I then made a copy of the VB. NET 2003 project, removed the reference to
the Office 11 library and added a reference to the Office 10 library on the
G drive. When I tried to run, as expected, I got build errors because the
Office 10 library knows nothing about the new object in the Office 11
library.

However, I told the build to continue despite the error and the code
executed correctly because the code creates a Word object, which defaulted
to Office 2003, even tho I had the wrong library (intentionally) referenced.
This worked because I have Option Strict Off.

 

[Howard Kaikow]

It's possible that some component of Office didn't get rev'd and that's why
you see it.

There was nothing to rev. Office 2003 is the only version of Office that was
ever installed under the OS on J. A clean Win 2000 install last year.

Also, you'll find that MSO gets installed by some nonintuitive
apps-- for instance, at least one version of Visual Studio installs MSO. I
don't know which version it uses, but I'd bet that VSNET uses MSO10.

VS .NET uses whatever Word is installed (see experiment below).

There are two suspects:

1. The Stillimage program has registered "Microsoft Office Word" as the
winword.exe for Office 2003 on the J drive, AND it has registered "Microsoft
Word" as the winword.exe for Office 2002 on the G drive. I've changed the
latter to also point to the winword.exe on the J drive for Office 2003.

2. I've got VB.NET 2002 projects that were created in the OS on the G drive.
Some/many refer to the Office 10 library on G. Maybe VS .NET 2003 (installed
in the OS on J) took it upon itself to register a COM to the Office mso.dll
on the G drive?

In any case, a few hours ago, I performed the following experiment.

a. I created a Word macro using the sample code for the SolutionID property
of the SmartDocument object. This object is new for Office 2003. Code worked
as expected.

b. I then created a VB .NET 2003 project using that code. I automated Word,
including a reference to the Office 11 library on the J drive. Code worked
as expected.

c. I then made a copy of the VB. NET 2003 project, removed the reference to
the Office 11 library and added a reference to the Office 10 library on the
G drive. When I tried to run, as expected, I got build errors because the
Office 10 library knows nothing about the new object in the Office 11
library.

However, I told the build to continue despite the error and the code
executed correctly because the code creates a Word object, which defaulted
to Office 2003, even tho I had the wrong library (intentionally) referenced.
This worked because I have Option Strict Off.

 

[Eric Lawrence [MSFT]]

There was nothing to rev. Office 2003 is the only version of Office that
was

ever installed under the OS on J. A clean Win 2000 install last year.

Actually, I meant on our side of the fence. Some Office 10 components
didn't really get rev'ed for Office 11 (e.g. some applet help files) and
it's remotely possible that some of the code pointed to the old MSO. Not
especially likely, I agree.

VS .NET uses whatever Word is installed (see experiment below).

I think we might be talking about different things. Regardless of Office
automation, Visual Studio itself uses a version of MSO to render its
toolbars or some such thing. Since MSOs are not interchangeable, it seems
unlikely that it could itself call into ~both~ MSO11 and MSO10.

--
Thanks,

Eric Lawrence
Program Manager
Assistance and Worldwide Services

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Eric Lawrence [MSFT]]

There was nothing to rev. Office 2003 is the only version of Office that
was

ever installed under the OS on J. A clean Win 2000 install last year.

Actually, I meant on our side of the fence. Some Office 10 components
didn't really get rev'ed for Office 11 (e.g. some applet help files) and
it's remotely possible that some of the code pointed to the old MSO. Not
especially likely, I agree.

VS .NET uses whatever Word is installed (see experiment below).

I think we might be talking about different things. Regardless of Office
automation, Visual Studio itself uses a version of MSO to render its
toolbars or some such thing. Since MSOs are not interchangeable, it seems
unlikely that it could itself call into ~both~ MSO11 and MSO10.

--
Thanks,

Eric Lawrence
Program Manager
Assistance and Worldwide Services

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Eric Lawrence [MSFT]]

There was nothing to rev. Office 2003 is the only version of Office that
was

ever installed under the OS on J. A clean Win 2000 install last year.

Actually, I meant on our side of the fence. Some Office 10 components
didn't really get rev'ed for Office 11 (e.g. some applet help files) and
it's remotely possible that some of the code pointed to the old MSO. Not
especially likely, I agree.

VS .NET uses whatever Word is installed (see experiment below).

I think we might be talking about different things. Regardless of Office
automation, Visual Studio itself uses a version of MSO to render its
toolbars or some such thing. Since MSOs are not interchangeable, it seems
unlikely that it could itself call into ~both~ MSO11 and MSO10.

--
Thanks,

Eric Lawrence
Program Manager
Assistance and Worldwide Services

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Eric Lawrence [MSFT]]

There was nothing to rev. Office 2003 is the only version of Office that
was

ever installed under the OS on J. A clean Win 2000 install last year.

Actually, I meant on our side of the fence. Some Office 10 components
didn't really get rev'ed for Office 11 (e.g. some applet help files) and
it's remotely possible that some of the code pointed to the old MSO. Not
especially likely, I agree.

VS .NET uses whatever Word is installed (see experiment below).

I think we might be talking about different things. Regardless of Office
automation, Visual Studio itself uses a version of MSO to render its
toolbars or some such thing. Since MSOs are not interchangeable, it seems
unlikely that it could itself call into ~both~ MSO11 and MSO10.

--
Thanks,

Eric Lawrence
Program Manager
Assistance and Worldwide Services

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Howard Kaikow]

Actually, I meant on our side of the fence. Some Office 10 components

didn't really get rev'ed for Office 11 (e.g. some applet help files) and
it's remotely possible that some of the code pointed to the old MSO. Not
especially likely, I agree.

Lemmee clarify.

Even if VS .NET 2003, or some other software, did install the J:\Program
Files\Common Files\Microsoft Shared\Office10 directory, my points include:

1. That directory is NOT being referenced in the Registry for the OS
installed on J.
2. G:\Program Files\Common Files\Microsoft Shared\Office10 is being
referenced in the registry for the OS installed on J. This makes no sense,
no how.
3. And, the G:\Program Files\Common Files\Microsoft Shared\Office10 is more
up to date as the Office XP updates were applied.
J:\Program Files\Common Files\Microsoft Shared\Office10 is not updated when
I apply Office XP updattes because Office XP is not installed in the OS on
J.

And there is no explanaation of why Stillimage, in the OS on J, would have
ever registered the winword.exe installed under the OS on G. It would seem
that the Win 2000 installation, or Stillimage itself, goes on a fishing trip
looking for particular files. If so, that's a crock.

I think we might be talking about different things. Regardless of Office
automation, Visual Studio itself uses a version of MSO to render its
toolbars or some such thing.

Are you saying that on a system that has no installed Office, an
installation of VS .NET would still install some version of mso.dll?
Even if so, that does not explain why the Office 10 mso.dll installed in the
OS on the G drive was registered instead of the orphan Office 10 mso.dll
that is located on the J drive.

Since MSOs are not interchangeable, it seems
unlikely that it could itself call into ~both~ MSO11 and MSO10.

I'm not talking about VB .NET itself, I'm talking about the explicit
reference to the COM object.

The only way to resolve this may be to find someone having a similar dual
boot system with.

Office XP in one OS and, on another drive, in another OS, Office 2003 and VS
..NET 2003.
---------------
As I was writing this response, I just noticed another piece of, perhaps,
useful info:

1. The WinNT directory on drive J is dated 8/20/2003 10:00, so I guess that
is when I did the clean install of Win 2000 on J.

2. J:\Program Files\Common Files\Microsoft Shared\Office11 is dated
10/24/2003 14:31, which is when I installed Office 2003.

3. J:\Program Files\Common Files\Microsoft Shared\Office10 is dated
8/21/2003 19:14..

4. I installed VS .NET 2003 on K to save space on the J drive. K:\Program
Files\Microsoft Visual Studio .NET 2003 is dated 8/21/2003 19:09, so I
expect that J:\Program Files\Common Files\Microsoft Shared\Office10 was
created during the install of VS .NET 2003. This solves part of the mystery.

However, it does not explain why the COM object reference points to
G:\Program Files\Common Files\Microsoft Shared\Office10 instead of
J:\Program Files\Common Files\Microsoft Shared\Office10.

There is the implication that something searched ALL the drives and
determined that G:\Program Files\Common Files\Microsoft Shared\Office10 was
more up to date than J:\Program Files\Common Files\Microsoft
Shared\Office10. I sure hope not, but that's what it looks like.

I'm wondering what will happen if there is ever an update to VS .NET 2003
that needs to update the files in J:\Program Files\Common Files\Microsoft
Shared\Office10. Will it instead/also update the files in G:\Program
Files\Common Files\Microsoft Shared\Office10? I sure hope not as that might
break the Office XP installation in the OS on G.

 

[Howard Kaikow]

Actually, I meant on our side of the fence. Some Office 10 components

didn't really get rev'ed for Office 11 (e.g. some applet help files) and
it's remotely possible that some of the code pointed to the old MSO. Not
especially likely, I agree.

Lemmee clarify.

Even if VS .NET 2003, or some other software, did install the J:\Program
Files\Common Files\Microsoft Shared\Office10 directory, my points include:

1. That directory is NOT being referenced in the Registry for the OS
installed on J.
2. G:\Program Files\Common Files\Microsoft Shared\Office10 is being
referenced in the registry for the OS installed on J. This makes no sense,
no how.
3. And, the G:\Program Files\Common Files\Microsoft Shared\Office10 is more
up to date as the Office XP updates were applied.
J:\Program Files\Common Files\Microsoft Shared\Office10 is not updated when
I apply Office XP updattes because Office XP is not installed in the OS on
J.

And there is no explanaation of why Stillimage, in the OS on J, would have
ever registered the winword.exe installed under the OS on G. It would seem
that the Win 2000 installation, or Stillimage itself, goes on a fishing trip
looking for particular files. If so, that's a crock.

I think we might be talking about different things. Regardless of Office
automation, Visual Studio itself uses a version of MSO to render its
toolbars or some such thing.

Are you saying that on a system that has no installed Office, an
installation of VS .NET would still install some version of mso.dll?
Even if so, that does not explain why the Office 10 mso.dll installed in the
OS on the G drive was registered instead of the orphan Office 10 mso.dll
that is located on the J drive.

Since MSOs are not interchangeable, it seems
unlikely that it could itself call into ~both~ MSO11 and MSO10.

I'm not talking about VB .NET itself, I'm talking about the explicit
reference to the COM object.

The only way to resolve this may be to find someone having a similar dual
boot system with.

Office XP in one OS and, on another drive, in another OS, Office 2003 and VS
..NET 2003.
---------------
As I was writing this response, I just noticed another piece of, perhaps,
useful info:

1. The WinNT directory on drive J is dated 8/20/2003 10:00, so I guess that
is when I did the clean install of Win 2000 on J.

2. J:\Program Files\Common Files\Microsoft Shared\Office11 is dated
10/24/2003 14:31, which is when I installed Office 2003.

3. J:\Program Files\Common Files\Microsoft Shared\Office10 is dated
8/21/2003 19:14..

4. I installed VS .NET 2003 on K to save space on the J drive. K:\Program
Files\Microsoft Visual Studio .NET 2003 is dated 8/21/2003 19:09, so I
expect that J:\Program Files\Common Files\Microsoft Shared\Office10 was
created during the install of VS .NET 2003. This solves part of the mystery.

However, it does not explain why the COM object reference points to
G:\Program Files\Common Files\Microsoft Shared\Office10 instead of
J:\Program Files\Common Files\Microsoft Shared\Office10.

There is the implication that something searched ALL the drives and
determined that G:\Program Files\Common Files\Microsoft Shared\Office10 was
more up to date than J:\Program Files\Common Files\Microsoft
Shared\Office10. I sure hope not, but that's what it looks like.

I'm wondering what will happen if there is ever an update to VS .NET 2003
that needs to update the files in J:\Program Files\Common Files\Microsoft
Shared\Office10. Will it instead/also update the files in G:\Program
Files\Common Files\Microsoft Shared\Office10? I sure hope not as that might
break the Office XP installation in the OS on G.

 

[Howard Kaikow]

Actually, I meant on our side of the fence. Some Office 10 components

didn't really get rev'ed for Office 11 (e.g. some applet help files) and
it's remotely possible that some of the code pointed to the old MSO. Not
especially likely, I agree.

Lemmee clarify.

Even if VS .NET 2003, or some other software, did install the J:\Program
Files\Common Files\Microsoft Shared\Office10 directory, my points include:

1. That directory is NOT being referenced in the Registry for the OS
installed on J.
2. G:\Program Files\Common Files\Microsoft Shared\Office10 is being
referenced in the registry for the OS installed on J. This makes no sense,
no how.
3. And, the G:\Program Files\Common Files\Microsoft Shared\Office10 is more
up to date as the Office XP updates were applied.
J:\Program Files\Common Files\Microsoft Shared\Office10 is not updated when
I apply Office XP updattes because Office XP is not installed in the OS on
J.

And there is no explanaation of why Stillimage, in the OS on J, would have
ever registered the winword.exe installed under the OS on G. It would seem
that the Win 2000 installation, or Stillimage itself, goes on a fishing trip
looking for particular files. If so, that's a crock.

I think we might be talking about different things. Regardless of Office
automation, Visual Studio itself uses a version of MSO to render its
toolbars or some such thing.

Are you saying that on a system that has no installed Office, an
installation of VS .NET would still install some version of mso.dll?
Even if so, that does not explain why the Office 10 mso.dll installed in the
OS on the G drive was registered instead of the orphan Office 10 mso.dll
that is located on the J drive.

Since MSOs are not interchangeable, it seems
unlikely that it could itself call into ~both~ MSO11 and MSO10.

I'm not talking about VB .NET itself, I'm talking about the explicit
reference to the COM object.

The only way to resolve this may be to find someone having a similar dual
boot system with.

Office XP in one OS and, on another drive, in another OS, Office 2003 and VS
..NET 2003.
---------------
As I was writing this response, I just noticed another piece of, perhaps,
useful info:

1. The WinNT directory on drive J is dated 8/20/2003 10:00, so I guess that
is when I did the clean install of Win 2000 on J.

2. J:\Program Files\Common Files\Microsoft Shared\Office11 is dated
10/24/2003 14:31, which is when I installed Office 2003.

3. J:\Program Files\Common Files\Microsoft Shared\Office10 is dated
8/21/2003 19:14..

4. I installed VS .NET 2003 on K to save space on the J drive. K:\Program
Files\Microsoft Visual Studio .NET 2003 is dated 8/21/2003 19:09, so I
expect that J:\Program Files\Common Files\Microsoft Shared\Office10 was
created during the install of VS .NET 2003. This solves part of the mystery.

However, it does not explain why the COM object reference points to
G:\Program Files\Common Files\Microsoft Shared\Office10 instead of
J:\Program Files\Common Files\Microsoft Shared\Office10.

There is the implication that something searched ALL the drives and
determined that G:\Program Files\Common Files\Microsoft Shared\Office10 was
more up to date than J:\Program Files\Common Files\Microsoft
Shared\Office10. I sure hope not, but that's what it looks like.

I'm wondering what will happen if there is ever an update to VS .NET 2003
that needs to update the files in J:\Program Files\Common Files\Microsoft
Shared\Office10. Will it instead/also update the files in G:\Program
Files\Common Files\Microsoft Shared\Office10? I sure hope not as that might
break the Office XP installation in the OS on G.

 

[Howard Kaikow]

Actually, I meant on our side of the fence. Some Office 10 components

didn't really get rev'ed for Office 11 (e.g. some applet help files) and
it's remotely possible that some of the code pointed to the old MSO. Not
especially likely, I agree.

Lemmee clarify.

Even if VS .NET 2003, or some other software, did install the J:\Program
Files\Common Files\Microsoft Shared\Office10 directory, my points include:

1. That directory is NOT being referenced in the Registry for the OS
installed on J.
2. G:\Program Files\Common Files\Microsoft Shared\Office10 is being
referenced in the registry for the OS installed on J. This makes no sense,
no how.
3. And, the G:\Program Files\Common Files\Microsoft Shared\Office10 is more
up to date as the Office XP updates were applied.
J:\Program Files\Common Files\Microsoft Shared\Office10 is not updated when
I apply Office XP updattes because Office XP is not installed in the OS on
J.

And there is no explanaation of why Stillimage, in the OS on J, would have
ever registered the winword.exe installed under the OS on G. It would seem
that the Win 2000 installation, or Stillimage itself, goes on a fishing trip
looking for particular files. If so, that's a crock.

I think we might be talking about different things. Regardless of Office
automation, Visual Studio itself uses a version of MSO to render its
toolbars or some such thing.

Are you saying that on a system that has no installed Office, an
installation of VS .NET would still install some version of mso.dll?
Even if so, that does not explain why the Office 10 mso.dll installed in the
OS on the G drive was registered instead of the orphan Office 10 mso.dll
that is located on the J drive.

Since MSOs are not interchangeable, it seems
unlikely that it could itself call into ~both~ MSO11 and MSO10.

I'm not talking about VB .NET itself, I'm talking about the explicit
reference to the COM object.

The only way to resolve this may be to find someone having a similar dual
boot system with.

Office XP in one OS and, on another drive, in another OS, Office 2003 and VS
..NET 2003.
---------------
As I was writing this response, I just noticed another piece of, perhaps,
useful info:

1. The WinNT directory on drive J is dated 8/20/2003 10:00, so I guess that
is when I did the clean install of Win 2000 on J.

2. J:\Program Files\Common Files\Microsoft Shared\Office11 is dated
10/24/2003 14:31, which is when I installed Office 2003.

3. J:\Program Files\Common Files\Microsoft Shared\Office10 is dated
8/21/2003 19:14..

4. I installed VS .NET 2003 on K to save space on the J drive. K:\Program
Files\Microsoft Visual Studio .NET 2003 is dated 8/21/2003 19:09, so I
expect that J:\Program Files\Common Files\Microsoft Shared\Office10 was
created during the install of VS .NET 2003. This solves part of the mystery.

However, it does not explain why the COM object reference points to
G:\Program Files\Common Files\Microsoft Shared\Office10 instead of
J:\Program Files\Common Files\Microsoft Shared\Office10.

There is the implication that something searched ALL the drives and
determined that G:\Program Files\Common Files\Microsoft Shared\Office10 was
more up to date than J:\Program Files\Common Files\Microsoft
Shared\Office10. I sure hope not, but that's what it looks like.

I'm wondering what will happen if there is ever an update to VS .NET 2003
that needs to update the files in J:\Program Files\Common Files\Microsoft
Shared\Office10. Will it instead/also update the files in G:\Program
Files\Common Files\Microsoft Shared\Office10? I sure hope not as that might
break the Office XP installation in the OS on G.