CDOEXM - Error adding assembly

  • Thread starter Thread starter Rob Edwards
  • Start date Start date
R

Rob Edwards

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.
 
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?
 
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
 
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 CDOEXM.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
 
Willy,

Not really. Even though I have Exchange Server 2003 SP1 installed (just the
tools on one machine, and the full application on another), no new code was
introduced to the C:\Program Files\Microsoft.NET\Primary Interop Assemblies
path as expected. The article seems to refer to a PIA that was to be
included in SP1, but didn't somehow make it. If there is an optional
install, or a file that needs to be copied, I haven't found it yet.

Victor Lindsey
 
To all:

Today, I tried this on still another machine (VS2003 on Win2003 with
Exchange2003 SP1 Mgmt Tools). For some reason, there is no problem here.
The IDE generates the required Interop assemblies without error or conflict
(the deployment project identifies the output as an ADODB 2.5 interface).
So far, all machines in check out as MDAC 2.8 RTM machines with Microsoft's
ComCheck utility. And I can find no difference in what little registry
entry comparisons I've done. So there you have it..it works on some
machine, and not others.

Hope this helps.

Victor Lindsey
 
Just fixed the problem

Copy CDOEX.DLL off your exchange server to the workstation that has exchange management and .Net Development on it "C:\Program Files\Common Files\Microsoft Shared\CDO\"

Register the DLL
Command Line: 'REGSVR32 "C:\Program Files\Common Files\Microsoft Shared\CDO\CDOEX.DLL"'

Add reference in .Net for CDOEX.DLL

Now add reference for CDOEXM.DLL

You may need to remove all references first and then re-add them in this order
"C:\Program Files\Exchsrvr\bin\CDO.DLL"
"C:\Program Files\Common Files\Microsoft Shared\CDO\CDOEX.DLL"
"C:\Program Files\Exchsrvr\bin\CDOEXM.DLL"

Or Clear the "Interop.*.dll" files out of the following folders
"C:\Documents and Settings\UserName\My Documents\Visual Studio Projects\ProjectName\obj"
and
"C:\Documents and Settings\UserName\My Documents\Visual Studio Projects\ProjectName\bin"
And then Remove and re-add the CDO References.

I suspect it works for a few of you that have .Net Dev on a full exchange server because CDOEX.DLL exists on that machine

I hope this information helps everyone

What a costly error 12 Hours of development time lost to a stupid fault

Kevin
Dev / Net Admin
New Zealan

User submitted from AEWNET (http://www.aewnet.com/)
 
Just fixed the problem

Copy CDOEX.DLL off your exchange server to the workstation that has exchange management and .Net Development on it "C:\Program Files\Common Files\Microsoft Shared\CDO\"

Register the DLL
Command Line: 'REGSVR32 "C:\Program Files\Common Files\Microsoft Shared\CDO\CDOEX.DLL"'

Add reference in .Net for CDOEX.DLL

Now add reference for CDOEXM.DLL

You may need to remove all references first and then re-add them in this order
"C:\Program Files\Exchsrvr\bin\CDO.DLL"
"C:\Program Files\Common Files\Microsoft Shared\CDO\CDOEX.DLL"
"C:\Program Files\Exchsrvr\bin\CDOEXM.DLL"

Or Clear the "Interop.*.dll" files out of the following folders
"C:\Documents and Settings\UserName\My Documents\Visual Studio Projects\ProjectName\obj"
and
"C:\Documents and Settings\UserName\My Documents\Visual Studio Projects\ProjectName\bin"
And then Remove and re-add the CDO References.

I suspect it works for a few of you that have .Net Dev on a full exchange server because CDOEX.DLL exists on that machine

I hope this information helps everyone

What a costly error 12 Hours of development time lost to a stupid fault

Kevin
Dev / Net Admin
New Zealan

User submitted from AEWNET (http://www.aewnet.com/)
 
Back
Top