Hey Eric,
I have the same issue, but perhaps better resources (machines of different
configurations) to figure out what is going on.
Problem Statement: Using Visual Studio 2003, user cannot reference Exchange
2003's CDOEXM.dll as an Interop assembly if the machine in question does not
actually have Exchange 2003 installed on it, but only the Exchange
Management Tools. (On a machine with Exchange 2003, user can add the
reference.) Attempts to do so generate the following large error message
from the TLBIMP tool used internally to create the Interop DLL wrappers:
A reference to 'Microsoft CDO for Exchange Management Library' could not be
added. Converting the type library to a .NET assembly failed. A dependent
type library 'CDO' could not be converted to a .NET assembly. A dependent
type library 'ADODB' could not be converted to a .NET assembly. Item has
already been added. Key in dictionary: "C:\Documents and Settings\User\My
Documents\Visual Studio Projects\Project1\obj\Interop.ADODB.dll" Key being
added: "C:\Documents and Settings\User\My Documents\Visual Studio
Projects\Project1\obj\Interop.ADODB.dll"
Analysis (supposition): The CDO libraries, and their dependents, create a
unique problem for Interop assembly generation. On machines with neither
Exchange 2003, or the Exchange Management Tools, the CDO COM definition is
handled by C:\Windows\system32\CDOSYS.dll. This environment lacks the
required DLL for mail-enabling users and groups and other activities unique
to the CDOEXM.dll. On machines with Exchange 2003 installed, the CDO COM
definition is handled by C:\Program Files\Exchsrvr\bin\CDOEX.dll; and
CDOEXM.dll in the same directory. On machines with only the Exchange 2003
Management Tools installed, CDOEXM.dll is installed, but has certain
incompatibilities with the CDO COM definition derived from CDOSYS.dll.
Exchange 2003's CDOEX.dll is bound to msado27.dll (ADODB 2.7) or msado28.dll
(ADODB 2.8); and uses the CDO COM defined interface for some of its work.
CDOSYS.dll is bound to msado15.dll (ADODB 2.5); CDOEX.dll is bound exactly
like that of CDOEXM.dll. For full Exchange 2003, adding a reference to
CDOEXM.dll causes the IDE to generated three Interop DLLs:
Interop.CDOEXM.dll (from CDOEXM.dll), Interop.CDO.dll (from CDOEX.dll), and
Interop.ADODB.dll (from msado27.dll or msado28.dll). Since both the CDOEXM
and CDO interfaces use the same version of ADODB, there is no conflict--only
one Interop.ADODB.dll is built and shared. However, the resulting compile
should only be installed an a machine with the full Exchange 2003
environment.
With just the Exchange 2003 Management Tools installed, adding a reference
to CDOEXM.dll causes the IDE to generated three Interop DLLs:
Interop.CDOEXM.dll (from CDOEXM.dll), Interop.CDO.dll (from CDOSYS.dll), and
Interop.ADODB.dll. Here, there is a fundamental conflict since CDOEXM is
bound to a different version of ADODB then CDO is. Within the COM world
itself, use of the generic ADODB definitions allows everyone to work
together. However, the TLBIMP.EXE utility used by Visual Studio 2003
requires more exacting version matches: the result is it attempt to build
two ADODB Interop assembly (one for each version), and dies because they
share the same namespace, namely ADODB. If someone has figured out how to
build the required Interop DLLs without error, please speak up (my attempts
at running TLBIMP directly resulted in the same conflict).
There are other "threads" in the various newsgroups that talk of
mail-enabling users and groups (the most common need for CDOEXM.dll) using
just the Active Directory interfaces only, but I have yet to see any actual
..NET code that does so. Thus, accomplishing this with .NET seems to
restrict us from writing code that works in the Management Tools-only
environment for the time being. I hope the bright boys (and girls) at
Microsoft resolve this issue so that Exchange 2003 .NET support is not so
difficult.
Resolution (as it currently stands): use of CDOEXM is restricted to Exchange
2003 Server-only environments.
Victor Lindsey