Office12\mso.dll

I have noticed that as of updates I ran in March 2009, my sysyems with Office 2000, Office XP, and Office 2003 each have Program Files\Common Files\Microsoft Shared\OFFICE12\mso.dll.

In addition, each has a corresponding Program Files\Common Files\Microsoft Shared\OFFICE11\mso.dll, at least for Office XP and Office 2003, Office 2000 has a different file for the Office 9 library.

I also noticed when you are in the, say, Excel 2003 Visual Basic editor, the list of references includes the Office11\mso.dll and not the Office12\mso.dll.

However, if I am in VB 6, the list of references includes the Office12\mso.dll and not the Office11\mso.dll. Of course, I can still brute force browse to the Office11\mso.dll and include it as reference.

So, MSFT is intentionally making Office12\mso.dll the default Office library when going thru, say, VB 6, but in Office itself.

Where is this documented?
It must have something to do with facilitating back/forth with Office 2007.

My concern is that other folkes indicate that not all systems seem to have Office12\mso.dll. And, using Google, I've briefly perused postings that indicated that using the Office12\mso.dll may cause issues, so it seems safer to use the native Office11.dll.

As an experiment, I did the following:

I compiled 2 versions of a test program on my Office 2003 system.

In one, I used the Office12\mso.dsl. In the other, I used the Office11\mso.dll.

I then copied the projects for each to my Office 2007 system.

I opened each project using VB 6. In both cases, the Office 2007 Office12 mso.dll was substituted

I then compiled both projects using VB 6 in the Office 2007 system, and moved them back to the Office 2003 system. They both ran.

I guess that MSFT's goal is to permit such back and forth, as long as you do not use features present in Office 2007 that are not in the earlier versions of interest. This makes sense.

But the puzzle remains as to why some folkes have the Office12 mso.dll and others do not.

One possibility is that one might have to have a compiler, such as VB 6 or, some other language, and not just Office.

But one person with VS .NET, as I recall, states that he does not have Office12\mso.dll, so MSFT may not want this used as a COM object in .NET. However, om my VS .NET 2003 system, I see both Office11\mso.dll and Office12\mso.dll listed as available COM objects to reference. Indeed, Office10\mso.dll is also listed even tho it is not installed, rather the Office10\mso.dll is installled in Office XP on another drive on my multiboot system.

If you just write VBA code within Office, the Office12 mso.dll is not listed as a reference.

However, if you compile with, say, VB 6, the Office 12 mso is listed, but the Office 11 mso.dll is NOT listed, tho you can browse and brute force reference the Office 11 version. I ASSuME that the Office 12 mso could also be referenced from within VBA, but I would not try it.

Click to expand...

So what's the story on the Office12\mso.dll in pre-Office 2007 systems?
Why does not everyone having installed the latest updates have Office12\mso.dll?