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

[Marcus Heege]

"MB" <ba*****@yahoo. com> wrote in message
news:11******** *************@z 34g2000cwc.goog legroups.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.dl l report?

[MB]

I'm using VS2003, Here are the dumps of the release and debug dlls. The
only diff I see is in the "strongNameSign atureDirectory" . 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\CO RE\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 StrongNameSigna ture Directory
0 [ 0] RVA [size] of CodeManagerTabl e Directory
2E3EC [ B70] RVA [size] of VTableFixups Directory
0 [ 0] RVA [size] of ExportAddressTa bleJumps
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\CO RE\Math\MathLib \Release\mathli b.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 StrongNameSigna ture Directory
0 [ 0] RVA [size] of CodeManagerTabl e Directory
26580 [ AF0] RVA [size] of VTableFixups Directory
0 [ 0] RVA [size] of ExportAddressTa bleJumps
Directory
Summary

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

[Marcus Heege]

"MB" <ba*****@yahoo. com> wrote in message
news:11******** **************@ u72g2000cwu.goo glegroups.com.. .

I'm using VS2003, Here are the dumps of the release and debug dlls. The
only diff I see is in the "strongNameSign atureDirectory" . 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 strongNameSigna tureDirectory.

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

[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

[Marcus Heege]

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.goo glegroups.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

[MB]

You're a genius. Thank you very much.

Tell your boss to give you a raise ;-)

Mitch

[MB]

You're a genius. Thank you very much.

Tell your boss to give you a raise ;-)

Mitch