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

  • Thread starter Thread starter MB
  • Start date Start date
M

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.)
 
MB said:
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"?
Click to expand...

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?
 
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
 
MB said:
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.
Click to expand...

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:
Click to expand...

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
 
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
 
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
 
Back
Top