470,848 Members | 1,653 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,848 developers. It's quick & easy.

Managed C++ dll in a C# app. Can't add the Debug version.

MB
I had a C++ dll that I used for C++ applications. I added a managed C++
class to this library and started to use the managed C++ class in my C#
application.

This works OK only if I build the C++ dll in release mode. If I try to
build the C++ dll in Debug mode, I am unable to add the dll as a
reference to my C# project. I get an error message that:

"This is not a valid assembly or COM component".

It's strange that this same technique works if I build a release
version.

Can anyone explain why this is happening? Could it be related to the
fact that I did not start out the C++ project as a ".Net class
library"?

Thanks,

Mitch

(sorry for the cross post, but when I started reading this group, it
seemed more appropriate.)

Apr 18 '06 #1
7 3837
"MB" <ba*****@yahoo.com> wrote in message
news:11*********************@z34g2000cwc.googlegro ups.com...
I had a C++ dll that I used for C++ applications. I added a managed C++
class to this library and started to use the managed C++ class in my C#
application.

This works OK only if I build the C++ dll in release mode. If I try to
build the C++ dll in Debug mode, I am unable to add the dll as a
reference to my C# project. I get an error message that:

"This is not a valid assembly or COM component".

It's strange that this same technique works if I build a release
version.

Can anyone explain why this is happening? Could it be related to the
fact that I did not start out the C++ project as a ".Net class
library"?


What VS.NET version are you using?
Are you sure you have set the /clr switch for the release and the debug
version?
What does dumpbin /clrheader YourDebugLib.dll report?
Apr 18 '06 #2
MB
I'm using VS2003, Here are the dumps of the release and debug dlls. The
only diff I see is in the "strongNameSignatureDirectory". I am using a
strong name for the dll.

I also looked at the diffs in the command line. The debug version has
two extra switches
/GS and /Zc:wchar_t. Thanks for any clues:

Mitch

*** debug version **** this one gives the error
Dump of file C:\VDevTrunk\CORE\Math\MathLib\Debug\mathlib.dll

File Type: DLL

clr Header:

48 cb
2.00 runtime version
1D388 [ 11018] RVA [size] of MetaData Directory
0 flags
0 entry point token
0 [ 0] RVA [size] of Resources Directory
0 [ 0] RVA [size] of StrongNameSignature Directory
0 [ 0] RVA [size] of CodeManagerTable Directory
2E3EC [ B70] RVA [size] of VTableFixups Directory
0 [ 0] RVA [size] of ExportAddressTableJumps
Directory
Summary

1000 .CRT
6000 .data
1C000 .rdata
1000 .reloc
1000 .rsrc
16000 .text

*** release version **** this one gives the error
Dump of file C:\VDevTrunk\CORE\Math\MathLib\Release\mathlib.dll

File Type: DLL

clr Header:

48 cb
2.00 runtime version
13FE0 [ 125A0] RVA [size] of MetaData Directory
8 flags
0 entry point token
0 [ 0] RVA [size] of Resources Directory
13F60 [ 80] RVA [size] of StrongNameSignature Directory
0 [ 0] RVA [size] of CodeManagerTable Directory
26580 [ AF0] RVA [size] of VTableFixups Directory
0 [ 0] RVA [size] of ExportAddressTableJumps
Directory
Summary

1000 .CRT
6000 .data
19000 .rdata
1000 .reloc
1000 .rsrc
11000 .text

Apr 18 '06 #3

"MB" <ba*****@yahoo.com> wrote in message
news:11**********************@u72g2000cwu.googlegr oups.com...
I'm using VS2003, Here are the dumps of the release and debug dlls. The
only diff I see is in the "strongNameSignatureDirectory". I am using a
strong name for the dll.
That is indeed strange. I have made a test with VS2003, a Win32 project
compiled with /clr and signed with [assembly: AssemblyKeyFile(...)]; and
both, the debug and the release build have a strongNameSignatureDirectory.

Please inspect both manifests with ILDASM to see if a publickeytoken exists
in both assemblies.
You can also use sn.exe's /Tp option to dump the public key. What does
sn -Tp return for both assemblies?
I also looked at the diffs in the command line. The debug version has
two extra switches
/GS and /Zc:wchar_t. Thanks for any clues:


Different /GS switches make sense to me, diffenen /Zc switches look like a
mis-setting but that should not be related to your porblem.

Marcus
Apr 19 '06 #4
MB
Checking the manifest using ildasm shows that the debug version is a
..module and not a .assembly. So, where do you tell VS that a dll is a
..Net assembly? And where could this be differentiated based on Debug or
Release?

I really appreciate your help on this. You obviously know what your
doing.

Mitch

Apr 19 '06 #5
According to your explanations, it seems that you have the following debug
setting:
Linker / Advanced / Turn Off Assembly Generation = Yes (/NOASSEMBLY)
and the following release setting:
Linker / Advanced / Turn Off Assembly Generation = No

Set the debug setting to no, too and the problem should be fixed

Marcus Heege

"MB" <ba*****@yahoo.com> wrote in message
news:11**********************@i40g2000cwc.googlegr oups.com...
Checking the manifest using ildasm shows that the debug version is a
.module and not a .assembly. So, where do you tell VS that a dll is a
.Net assembly? And where could this be differentiated based on Debug or
Release?

I really appreciate your help on this. You obviously know what your
doing.

Mitch

Apr 19 '06 #6
MB
You're a genius. Thank you very much.

Tell your boss to give you a raise ;-)

Mitch

Apr 19 '06 #7
MB
You're a genius. Thank you very much.

Tell your boss to give you a raise ;-)

Mitch

Apr 19 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

5 posts views Thread by Gerhard Menzl | last post: by
4 posts views Thread by =?Utf-8?B?dmlwZXJ4MTk2Nw==?= | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.