[newbie] C++ with managed extensions

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,

I created a C++ DLL in .net 1.1 that makes use of some .net features (so
called 'mixed' or hybrid DLL, as it contains both .net and 'old' C++ code).
The project worked and compiled fine with VS2003 - but now I had to upgrade
the whole lot to VS2005: Compiling and linking works still fine (with
/clr:OldSyntax), but suddenly other DLLs that should call functions in this
mixed DLL complain on linking (LNK2019: unresolved external symbol)....any
ideas why??

Thanks ,

Peter
 
Peter said:
Hi,

I created a C++ DLL in .net 1.1 that makes use of some .net features
(so called 'mixed' or hybrid DLL, as it contains both .net and 'old'
C++ code). The project worked and compiled fine with VS2003 - but now
I had to upgrade the whole lot to VS2005: Compiling and linking works
still fine (with /clr:OldSyntax), but suddenly other DLLs that should
call functions in this mixed DLL complain on linking (LNK2019:
unresolved external symbol)....any ideas why??
Click to expand...

If you give some examples of functions that are coming up undefined, it
would help.

One thought: /Zc:wchar_t is on by default in VC 2005, off by default in VC
2003, so if you're exposing functions that deal in wide-character (Unicode)
strings, you might see this problem. If that's the case, either re-compile
your DLL with /Zc:wchar_t- or rebuild the other DLLs with VC 2005 as well.

-cd
 
Thanks for replying!

The functions that are coming up undefined are my own functions (CString
TestFunc(CString param)).

-Peter
 
Peter said:
Thanks for replying!

The functions that are coming up undefined are my own functions
(CString TestFunc(CString param)).
Click to expand...

Is it a Unicode build? What are the other DLLs built with?

As a general rule, you can't pass MFC/ATL/STL objects between program
modules unless they're compiled with the same version of the same compiler.
There are undefined internals that change from version to version breaking
binary compatiblity.

If you need a version independent interface to a DLL, you have to stick to
plain old C (not C++) interfaces.

-cd
 
All DLLs are compiled with VC8 - all of them are compiled with the 'multi
byte' option.

The strange thing is, that I can link to the DLL if it's compiled/linked
with VS2003 - but breaks with VS2005. I've checked if the DLL exports the
correct functions - it does. So I'd guess, that the problem lies within the
lib file...


-Peter
 
Back
Top