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
"Eric Tsai" <Eric
Ts**@discussions.microsoft.com> wrote in message
news:45**********************************@microsof t.com...
I ran into the same situation last week.
I 've tried C# and VB.NET on Windows 2003 Standard Edition + all hot fixes
+
Exchange 2003 Management Tools, and Exchange Server 2003 on a seperate
computer.
I could successfully add reference to CDOEXM at July and August,
so maybe it's a problem of Windows hot fixes?
I've tried to install Exchange 2003 Service Pack 1 on both computer but
still the same.
When I try to add reference of any version (2.5, 2.6, 2.7) of ADODB first,
it will failed and have the message:
Warning: The dependency 'Interop.ADODB, Version=2.7.0.0, Culture=neutral'
in
project 'MyProjectName' cannot be copied to the run directory because it
would overwrite the reference 'Interop.ADODB,
Version=TheVersionOfAdodbIAddManually, Culture=neutral'.
Some libraries are using different version of ADODB?
"Rob Edwards" wrote:
When trying to add the Microsoft CDO for Exchange Management Library (aka
CDOEXM.dll) I receive the following message:
"A reference to 'Microsoft CDO for Exchange Management Library' could not
be added. Converting the type library to a .Net assembly failed. A
depended 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."
The ADODB library has already been added.
I have tried removing the assemblies and restarting Visual Studio. I've
uninstalled and reinstalled Exchange 2003 management tools. I've even
scrolled to the DLL directly and added it manually.
I even built a new box... installed XP (with SP2) from scratch.
Installed Visual Studio. Installed the Exchange 2003 Management Tools.
When I try to add the CDOEXM component... I get the same message.
Can somebody lead me in the right direction?
Thanks
