Unable to see my my module in the modules list

  • Thread starter Thread starter Efi Merdler
  • Start date Start date
E

Efi Merdler

Hello,

I am using Visual studio 2005 standard edition sp1.

I've compiled a native dll in vc6 with debug information. I am
building a wrapper for the exported classes in vs2005 using IJW.

The compilation is working just fine and I am able to use the final
CLR dll in my c# application. The problem happens when I'm trying to
debug my dll. When using 'step into' I have no problem stepping into
my C++/CLI code, however when trying to step into my native code the
debugger just skips the line.

I've checked the modules list and my native dll is not written there.
I made sure to include the location of my native's PDB files, I added
the source location in the solution properties and I checked Debugger
type to mixed.

When adding a breakpoint in a native source file I get "...no symbols
have been loaded for this document"



Any idea what I'm doing wrong?



Thanks,

Efi
 
Efi said:
Hello,

I am using Visual studio 2005 standard edition sp1.

I've compiled a native dll in vc6 with debug information. I am
building a wrapper for the exported classes in vs2005 using IJW.
Click to expand...

It's not good to export classes from a DLL. It certainly can't work when
one is vc6 and one vc2005.
 
It's not good to export classes from a DLL. It certainly can't work when
one is vc6 and one vc2005.
Click to expand...

Thanks.
Why ? Do you have any pointer on the subject ?
How can I export c++ classes ?

Efi
 
Efi said:
Thanks.
Why ? Do you have any pointer on the subject ?
How can I export c++ classes ?
Click to expand...

You export accessor functions and give the user a handle to the object
instead of the object itself. The way Win32 windows work, there's
CreateWindow, DestroyWindow, SetWindowText, and so on. All of these are
operations on a window, but they are exported this way because there is an
application binary interface for C functions (actually three, cdecl,
stdcall, and fastcall), but none for C++.

Without an ABI, different compilers, compiler versions, even compiler
settings will never be compatible with each other.
 
Ben said:
You export accessor functions and give the user a handle to the object
instead of the object itself. The way Win32 windows work, there's
CreateWindow, DestroyWindow, SetWindowText, and so on. All of these
are operations on a window, but they are exported this way because
there is an application binary interface for C functions (actually
three, cdecl, stdcall, and fastcall), but none for C++.

Without an ABI, different compilers, compiler versions, even compiler
settings will never be compatible with each other.
Click to expand...

Also, these accessor functions can be either exported individually, or in a
vtable. The v-table can be created automatically by the C++ compiler if you
use pure virtual interfaces, the important thing is that no class member
variables or function bodies are in the public header file, because
different compilers would interpret them in incompatible ways.
 
Back
Top