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

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

MB - 18 Apr 2006 14:50 GMT

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.)

Reply to this Message

Marcus Heege - 18 Apr 2006 15:48 GMT

>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#
[quoted text clipped - 12 lines]
> 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?

Reply to this Message

MB - 18 Apr 2006 19:14 GMT

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

Reply to this Message

Marcus Heege - 19 Apr 2006 11:14 GMT

> 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

Reply to this Message

MB - 19 Apr 2006 15:29 GMT

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

Reply to this Message

Marcus Heege - 19 Apr 2006 18:41 GMT

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

> 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
[quoted text clipped - 5 lines]
>
> Mitch

Reply to this Message

MB - 19 Apr 2006 19:56 GMT

You're a genius. Thank you very much.

Tell your boss to give you a raise ;-)

Mitch

Reply to this Message

MB - 19 Apr 2006 20:12 GMT

You're a genius. Thank you very much.

Tell your boss to give you a raise ;-)

Mitch

Reply to this Message

Rate this thread:

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

Free Magazines