If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
Why does Office10 mso.dll file get installed on an Office11 system?
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? -- http://www.standards.com/; See Howard Kaikow's web site. |
#2
|
|||
|
|||
Why does Office10 mso.dll file get installed on an Office11 system?
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" wrote in message ... 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? -- http://www.standards.com/; See Howard Kaikow's web site. |
#3
|
|||
|
|||
Why does Office10 mso.dll file get installed on an Office11 system?
"Eric Lawrence [MSFT]" wrote in message
... 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. -- http://www.standards.com/; See Howard Kaikow's web site. |
#4
|
|||
|
|||
Why does Office10 mso.dll file get installed on an Office11 system?
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. Also, you'll find that MSO gets installed by some nonintuitive apps-- for instance, at least one version of Visual Studio installs MSO. 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). 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. |
#5
|
|||
|
|||
Why does Office10 mso.dll file get installed on an Office11 system?
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. |
Thread Tools | |
Display Modes | |
|
|