Is there an mso.dll in Office 2003 that is for Office 20077

[Howard Kaikow]

I am currently coding a VB 6 DLL and a VB 6 EXE, each uses Excel 2003.

Both projects require the use of the Office 11 object library, which results
in a reference to the mso.d11 for Office 11, version 11.0.8221.0.

However, certain constants are not defined unless I include the MSO.dll for
what is called the Office 12 object library, version 12.0.6320.5000.

The file is Program Files\Common Files\Microsoft Shared\OFFICE12\mso.dll.
Office 2007 has never been on the computer being used.

Where did that file come from?
From an update to Office 2003?

Neither version is listed at http://support.microsoft.com/dllhelp/.

 

[Peter T]

Hi Howard,

If the reference is set to the Office-11 mso.dll do *not* use any named
constants that are new in Office-12. Simply define your own say at module
level, you can use the same names, or use the intrinsic values.

Public Const msoThemeDark1 As Long = &H1

I can't imagine how \OFFICE12\mso.dll ever got onto the computer if Office
2007 has never been installed.

Regards,
Peter T

 

[Howard Kaikow]

Hi Howard,

If the reference is set to the Office-11 mso.dll do *not* use any named
constants that are new in Office-12. Simply define your own say at module
level, you can use the same names, or use the intrinsic values.

I'm not.

This is old code.

I'll have to try the code in, say, Excel 2002.

I can't imagine how \OFFICE12\mso.dll ever got onto the computer if Office
2007 has never been installed.

The date on the Office 12 mso.dll file is 7 August 2008.
The directory was created on 7 March 2009, as I recall, that's when I
installed Office 2003 SP3.
Some MSFT update must have put it there.

The date on the Office 11 mso.dll file is 27 May 2008.

I'm guessing that MSFT pulled some stuff out of the Office 11 file and
included it in the Office 12 file.

Perhaps, a condition for running the code is that the user have SP3?
It would sure be nice if MSFT updated their DLL Help Database.

 

[Peter T]

I have yet to install SP3 for my Office 2003 so I don't know if the 2007
mso.dll version gets installed, seems very odd though. However, regardless
as to how it's got on to your system I wouldn't add a reference to it if you
want your app to be compatible with all 2003 users. For use with 2007 define
your own constants.

Regards,
Peter T

 

[Howard Kaikow]

I'm going to perform a test with a .xls that, as I recall, works with Excel
2002.

I ASSuME that will use the Office 10 library.

When I open that workbook in Office 2003, it will be interesting to see
whether there's an error, or whether Office 2003 will replace the reference
to Office 10 with the references to Office 11 and Office 12.

 

[Howard Kaikow]

It seems that the mso.dll labeled for Office 12 is NOT available via VBA in
Excel 2003, but only via automation, say, from VB6.

 

[Howard Kaikow]

The date on the Office 12 mso.dll file is 7 August 2008.
The directory was created on 7 March 2009, as I recall, that's when I
installed Office 2003 SP3.
Some MSFT update must have put it there.

The date on the Office 11 mso.dll file is 27 May 2008.

I'm guessing that MSFT pulled some stuff out of the Office 11 file and
included it in the Office 12 file.

Perhaps, a condition for running the code is that the user have SP3?
It would sure be nice if MSFT updated their DLL Help Database.

I just tried with a system that has Office Xp.
Same issue, there is an Office12 directory that was create don 8-9 March
2009, it contains an mso.dll.

Ditto for Office 2000 system.

So, MSFT intentionally made tese changes.
I ASSuME that prohects will port correctly whe using Office 97.

Of course, you do not see the office 12 library listed from within an office
app, only when automating from, say, VB 6.
Surely (silly me!) this was "docunted" somewhere.

I wonder if they did the same for Office 97?

 

[Howard Kaikow]

My previous post should have been the following.
-----------------------------
I just tried with a system that has Office Xp.
Same issue, there is an Office12 directory that was created on 8-9 March
2009, it contains an mso.dll.

Ditto for Office 2000 system.

So, MSFT intentionally made these changes.
I ASSuME that projects will port correctly when using Office 2007.

Of course, you do not see the office 12 library listed from within an office
app, only when automating from, say, VB 6.
Surely (silly me!) this was "documented" somewhere.

I wonder if they did the same for Office 97

 

[SvenC]

Hi Howard.

I just tried with a system that has Office Xp.
Same issue, there is an Office12 directory that was created on 8-9 March
2009, it contains an mso.dll.

Ditto for Office 2000 system.

So, MSFT intentionally made these changes.
I ASSuME that projects will port correctly when using Office 2007.

I doubt that strongly. Just checked an WinXP SP3 with Office 2003 all
fully patched from microsoft update.
No Office12 folder and hence no mso.dll.

There must be some other component you installed which cause this.
Maybe some add on which tries to install some office modules or
the PIAs? Maybe the OpenXML or PDF converters?

Of course, you do not see the office 12 library listed from within an
office
app, only when automating from, say, VB 6.
Surely (silly me!) this was "documented" somewhere.

VBA in Office will default to its own type library of the correct version.
Seems a resonible default to me.

 

[Peter T]

I doubt that strongly. Just checked an WinXP SP3 with Office 2003 all
fully patched from microsoft update.
No Office12 folder and hence no mso.dll.

There must be some other component you installed which cause this.
Maybe some add on which tries to install some office modules or
the PIAs? Maybe the OpenXML or PDF converters?

That's what I would have assumed but without the similar updates I can't
confirm either way.

VBA in Office will default to its own type library of the correct version.
Seems a resonible default to me.

Not necessarily. Where a reference has been set to a newer version but used
in a system with an older version various problems can occur, in VBA even if
no attempt is made to call something that doesn't exist in the older
version.

With VB6, curiously, things can sometimes work where the app has been
compiled against a newer reference but run with an older reference,
providing no attempt is made to call something that does not exist in the
older version. That said, I would only want to compile with the oldest
version that the app will ever be used with.

Regards,
Peter T

 

[Howard Kaikow]

I doubt that strongly. Just checked an WinXP SP3 with Office 2003 all
fully patched from microsoft update.
No Office12 folder and hence no mso.dll.

There must be some other component you installed which cause this.
Maybe some add on which tries to install some office modules or
the PIAs? Maybe the OpenXML or PDF converters?

Well, not only is the Office12 mso.dll present in my Office 2000, Office XP
and Office 2003 systems, the Office 11 and Office 10 mso.dll files no longer
contain references to constants related to the CommandBars object, at least
forthose constants I am using. Those are now in the Office 12 mso.dll. I
have not checked in Office 9, but the Office 2000 system is different im
that it has no Office9 directory, but it does have an Office 12 directory
with an mso.dll file,

Such a change would only be made by MSFT.

A ha!
I just noticed that the Office 2003 system has an J:\Documents and
Settings\Howard Kaikow\Application Data\OfficeUpdate12 directory. The
directory is dated in March 2009, when I ran the updates. It has the install
files for what likely created Office12.

Ditto for the Office 2000 and Office XP systems.

 

[Howard Kaikow]

Thus far, I have only noticed a problem for mso* constants related to the
CommandBars object.

It may be that MSFT decided to separate those into an Office12/mso.dll to
facilitate moving back/forth with Office 2007.

 

[SvenC]

Hi Howard,

Well, not only is the Office12 mso.dll present in my Office 2000, Office
XP
and Office 2003 systems, the Office 11 and Office 10 mso.dll files

What are the version numbers of those mso.dlls?

no longer
contain references to constants related to the CommandBars object, at
least
forthose constants I am using. Those are now in the Office 12 mso.dll. I
have not checked in Office 9, but the Office 2000 system is different im

Which constants? Please give some concrete examples. The only thing which
makes sense to me would be that you used constants new to Office 12 and
thought they should have been there in earlier versions of Office as well.

Such a change would only be made by MSFT.

I pretty much doubt that MS would create dependencies between
Office versions.

A ha!
I just noticed that the Office 2003 system has an J:\Documents and
Settings\Howard Kaikow\Application Data\OfficeUpdate12 directory. The
directory is dated in March 2009, when I ran the updates. It has the
install
files for what likely created Office12.

Typically Microsoft put its files in a Microsoft subdirectory, so having an
OfficeUpdate12 directory directly in Application Data looks strange.

What kind of update service do you use?
Microsofts online update service or an offline WSUS?

BUT: back to your original question:

I am currently coding a VB 6 DLL and a VB 6 EXE, each uses Excel 2003.
Both projects require the use of the Office 11 object library, which
results
in a reference to the mso.d11 for Office 11, version 11.0.8221.0.
However, certain constants are not defined unless I include the MSO.dll
for
what is called the Office 12 object library, version 12.0.6320.5000.

How about installing a clean Windows with a clean Office 2003 and apply
only their current service packs. Are there still CommandBar related
constants
missing? If yes, which - they might be new to Office 2007 and would have
no meaning in older versions.

 

[Peter T]

Well, not only is the Office12 mso.dll present in my Office 2000, Office
XP
and Office 2003 systems, the Office 11 and Office 10 mso.dll files no
longer
contain references to constants related to the CommandBars object, at
least
forthose constants I am using. Those are now in the Office 12 mso.dll. I
have not checked in Office 9, but the Office 2000 system is different im
that it has no Office9 directory, but it does have an Office 12 directory
with an mso.dll file,

Surely not. As you have VB6 you'll presumably have tlbinf32.dll and should
be able to run this

Sub ListConstants()
' requires tlbinf32.dll is registered on the system
Dim a As Long, i As Long
Dim sFile As String
Dim TLIApp As Object 'TLI.TLIApplication
Dim XLInfo As Object 'TLI.TypeLibInfo
Dim c As Object 'ConstantInfo
Dim m As Object 'Members

'Set TLIApp = New TLI.TLIApplication ' early binding
Set TLIApp = CreateObject("TLI.TLIApplication") ' late binding

' << change sFile to suit >>
'sFile = Application.Path & "\Excel.exe"
'sFile = ThisWorkbook.VBProject.References("OFFICE").FullPath ' "VBA"
etc
sFile = "C:\Program Files\Common Files\Microsoft
Shared\OFFICE12\MSO.DLL"

On Error Resume Next
Set XLInfo = TLIApp.TypeLibInfoFromFile(sFile)
On Error GoTo 0
If XLInfo Is Nothing Then
MsgBox "file not found or registered" & vbCr & sFile
Exit Sub
End If

Columns("A").Clear
For Each c In XLInfo.Constants
a = a + 1
Cells(a, 1) = c.Name
Set m = c.Members
For i = 1 To m.Count
a = a + 1
Cells(a, 2) = m(i).Name
Cells(a, 3) = m(i).Value
Cells(a, 4) = "H " & Hex(CLng(m(i).Value))
Next
Next
Columns("A").EntireColumn.AutoFit
End Sub

Regards,
Peter T

 

[Howard Kaikow]

What are the version numbers of those mso.dlls?

For Office 2003: Office11\mso.dll is 11.0.8221.0, Office12\mso.dll is
12.0.6320.5000.
For Office XP: Office10\mso.dll is 10.0.6845.0, Office12\mso.dll is same as
above.
For Office 2000: Office12\mso.dll is same as above. No other mso.dll in
Office 2000.

Which constants? Please give some concrete examples. The only thing which
makes sense to me would be that you used constants new to Office 12 and
thought they should have been there in earlier versions of Office as well.

I've already stated that this is with old code, no new constants.

I've posted an example below.
When compiling wit VB 6, ONLY the Office12\mso.dll is listed.
However, I can browse and add a reference to Office11\mso.dll.
Either mso.dll does the job.

Somewhere MSFT mut have documented (silly me, asking for documentation) this
change.

I pretty much doubt that MS would create dependencies between
Office versions.

There would be no other reson for creating such a library.
Having anf Office 12 mod.dll likely facilitates Office 2007 importing
critters from earlier versions.

Typically Microsoft put its files in a Microsoft subdirectory, so having an
OfficeUpdate12 directory directly in Application Data looks strange.

These are MSFT files.

What kind of update service do you use?
Microsofts online update service or an offline WSUS?

MSFT update.
..

How about installing a clean Windows with a clean Office 2003 and apply
only their current service packs. Are there still CommandBar related
constants
missing? If yes, which - they might be new to Office 2007 and would have
no meaning in older versions.

No reason to do that.
This update is clearly from MSFT and, if needed, I can brute force to the
old Office11 mso.dll.

The puzzle is why some others are not seeing this update.

In another forum, I have found folkes that do have the Office12 critter.

No point in discussing furthe.
Somebody here likely has contacts at MSFT who can explain what's going on.

The log file from the install has:
V3_2|514182|INSTALL|MSPUB_8103_INTL||2006-11-29 03:07:36|9|SUCCESS|||
V3_2|514379|INSTALL|POWERPNT_8110_INTL||2006-11-29 03:07:36|9|SUCCESS|||
V3_2|514374|INSTALL|WINWORD_8106_INTL||2006-11-29 03:07:36|9|SUCCESS|||
V3_2|514382|INSTALL|MSXML5_8107_INTL||2006-11-29 03:07:36|9|SUCCESS|||
V3_2|513905|INSTALL|GPFILT_8030_ENG||2006-11-29 03:07:36|9|SUCCESS|||
V3_2|514383|INSTALL|MSO_8107_INTL||2006-11-29 03:07:36|9|SUCCESS|||
V3_2|514366|INSTALL|EXCEL_8105_INTL||2006-11-29 03:07:36|9|SUCCESS|||
V3_2|518405|INSTALL|OUTLFLTR_8111_INTL||2006-11-29 03:07:36|9|SUCCESS|||
V3_2|518408|INSTALL|LCCWIZ_8111_ENG||2006-11-29 03:07:36|9|SUCCESS|||
V3_2|514387|INSTALL|STLIST_8104_INTL||2006-11-29 03:07:36|9|SUCCESS|||
V3_2|518780|INSTALL|OUTLOOK_8119_INTL||2007-02-09 01:32:52|9|SUCCESS|||
V3_2|518718|INSTALL|EXCEL_8117_INTL||2007-02-09 01:32:52|9|SUCCESS|||
V3_2|518720|INSTALL|OUTLFLTR_8119_INTL||2007-02-09 01:32:52|9|SUCCESS|||
V3_2|518532|INSTALL|RICHED20_8114_INTL||2007-07-22 13:50:17|9|SUCCESS|||
V3_2|519161|INSTALL|EXCEL_11.0.8142_INTL||2007-07-22 13:50:17|9|SUCCESS|||
V3_2|518939|INSTALL|MSO_11.0.8132_INTL||2007-07-22 13:50:17|9|SUCCESS|||
V3_2|518938|INSTALL|WINWORD_11.0.8134_INTL||2007-07-22 13:50:17|9|SUCCESS|||
V3_2|518937|INSTALL|POWERPNT_11.0.8134_INTL||2007-07-22
13:50:17|9|SUCCESS|||
V3_2|519339|INSTALL|OUTLFLTR_11.0.8143_INTL||2007-07-22
13:50:17|9|SUCCESS|||
V3_2|518828|INSTALL|EUROTOOL_8118_INTL||2007-07-22 13:50:17|9|SUCCESS|||
V3_2|519988|INSTALL|MAINSP3_11.0.8173_ENG||2008-06-08 08:35:51|9|SUCCESS|||
V3_2|525359|INSTALL|OUTLFLTR_11.0.8215_MANY||2008-06-08
08:35:51|9|SUCCESS|||
V3_2|525342|INSTALL|MSPUB_11.0.8212_MANY||2008-06-08 19:51:29|9|SUCCESS|||
V3_2|524657|INSTALL|EXCEL_11.0.8211_MANY||2008-06-08 19:51:29|9|SUCCESS|||
V3_2|525349|INSTALL|WINWORD_11.0.8215_MANY||2008-06-08 19:51:29|9|SUCCESS|||
V3_2|523488|INSTALL|MSO_11.0.8202_MANY||2008-06-08 19:51:29|9|SUCCESS|||
V3_2|524858|INSTALL|VBE6_11.0.8203_MANY||2008-06-08 19:51:29|9|SUCCESS|||
V3_2|524861|INSTALL|OUTLOOK_11.0.8206_MANY||2008-06-08 19:51:29|9|SUCCESS|||
V3_2|520996|INSTALL|OLKINTL_11.0.8201_ENG||2008-06-08 19:51:29|9|SUCCESS|||
V3_2|524860|INSTALL|WORKS632_11.0.8202_MANY||2008-08-06
05:47:00|9|SUCCESS|||
V3_2|527524|INSTALL|OUTLFLTR_11.0.8223_MANY||2008-08-06
05:47:00|9|SUCCESS|||
V3_2|527525|INSTALL|OUTLOOK_11.0.8217_MANY||2008-08-06 05:47:00|9|SUCCESS|||
V3_2|532336|INSTALL|MSO_12.0.6324.5002_MANY||2009-03-07
18:00:41|9|SUCCESS|||
V3_2|536389|INSTALL|WINWORD_11.0.8237_MANY||2009-03-07 18:00:41|9|SUCCESS|||
V3_2|531879|INSTALL|MSO_11.0.8221_MANY||2009-03-07 18:00:41|9|SUCCESS|||
V3_2|527668|INSTALL|GPFILT_11.0.8203_ENG||2009-03-07 18:00:41|9|SUCCESS|||
V3_2|530067|INSTALL|POWERPNT_11.0.8227_MANY||2009-03-07
18:00:41|9|SUCCESS|||
V3_2|531884|INSTALL|GDIPLUS_11.0.8230_MANY||2009-03-07 18:00:41|9|SUCCESS|||
V3_2|531453|INSTALL|SNAPVIEW_11.0.8229_ENG||2009-03-07 18:00:41|9|SUCCESS|||
V3_2|536366|INSTALL|MSXML5_11.0.8237_MANY||2009-03-07 18:00:41|9|SUCCESS|||
V3_2|536361|INSTALL|EXCEL_11.0.8237_MANY||2009-03-07 18:00:41|9|SUCCESS|||
V3_2|536416|INSTALL|OUTLFLTR_11.0.8246_MANY||2009-03-07
18:00:41|9|SUCCESS|||

ident.ini has:
[cabpools]
ServerCount=2
default=2
Server1=http://Office.microsoft.com/officeupdate/catalog/ident/Officemicroso
ftcom
Server2=http://download.microsoft.com/download/0/5/9/0590D3F9-106B-4A0B-8841
-C3C999C9A81A/
[v3]
ServerCount=1
default=1
Server1=http://Office.microsoft.com/officeupdate/content
[content]
ServerCount=1
default=1
server1=http://Office.microsoft.com/officeupdate/catalog

OK, here's the example.

I have to include either the Office12\mso.dll or the Office11\mso.dsl as a
reference, as well as the reference for Excel.

Option Explicit
Private Sub btnExit_Click()
appExcel.Quit
Set appExcel = Nothing
Unload Me
End Sub

Private Sub btnRunMe_Click()
Set appExcel = New Excel.Application
CreateToolbar
End Sub

and

Option Explicit
Public appExcel As Excel.Application
Private Const sToolbarName As String = "Nuts"

Public Sub CreateToolbar()
With appExcel
.Workbooks.Add
'Get rid of any existing toolbar
On Error Resume Next
.CommandBars(sToolbarName).Delete
On Error GoTo 0

'Create new toolbar
With .CommandBars.Add(Name:=sToolbarName)
With .Controls.Add(Type:=Office.msoControlButton)
.Style = Office.msoButtonCaption
.Caption = "Nuts are good for you!"
.OnAction = "ListNuts"
.ToolTipText = "Ask any squirrel!"
End With
.Position = Office.msoBarTop
.Visible = True
End With
Debug.Print .CommandBars(sToolbarName).Name
.ActiveWorkbook.Close SaveChanges:=False
End With
End Sub

Public Sub CreateToolbarNoOffice()
With appExcel
.Workbooks.Add
'Get rid of any existing toolbar
On Error Resume Next
.CommandBars(sToolbarName).Delete
On Error GoTo 0

'Create new toolbar
With .CommandBars.Add(Name:=sToolbarName)
With .Controls.Add(Type:=msoControlButton)
.Style = msoButtonCaption
.Caption = "Nuts are good for you!"
.OnAction = "ListNuts"
.ToolTipText = "Ask any squirrel!"
End With
.Position = msoBarTop
.Visible = True
End With
Debug.Print .CommandBars(sToolbarName).Name
.ActiveWorkbook.Close SaveChanges:=False
End With
End Sub

 

[Howard Kaikow]

I compiled 2 versions of the 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 prohects for each to my Office 2007 system.

I opened each project on the Office 2003 system 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.

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, thou 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.

 

[Steve Rindsberg]

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.

The Compatibility Pack may install the MSO.DLL version in question. Of
possibly one or another of the Office viewer apps (though not the PowerPoint
viewer ... I just checked that).

 

[Howard Kaikow]

The Compatibility Pack may install the MSO.DLL version in question. Of
possibly one or another of the Office viewer apps (though not the PowerPoint
viewer ... I just checked that).

I do not have the Compatibility Pack, at least I never asked for it to be
installed, not do I have any viewer on ANY of thse systems with Office 2000,
XP, or 2003.

How could I determine whether I have the Compatibility Pack?

 

[Clif McIrvin]

After I installed the Compatibility Pack on Office 2003 SP3 (XP Pro,
SP3) Excel 2007 file types are now listed at the end of the Save As
Dialog in Excel (2003)

 

[Howard Kaikow]

After I installed the Compatibility Pack on Office 2003 SP3 (XP Pro,
SP3) Excel 2007 file types are now listed at the end of the Save As
Dialog in Excel (2003)

Thanx.

Then I do not have the compatibility pack.