At 04:16 PM 7/19/2006, Eddie Lascu wrote (in part)
>[snip] The distributable ".dll" file is all I have.
You also have the header files and the .LIB file. You said you had to change
the header files "to get them to compile". What kind of changes did you make?
The compiler uses the header files to figure out if you're calling things
correctly in your source code, but the linker uses the .LIB file to figure out
how to make calls to the DLL. Particularly if Peter is right that VS doesn't
work well with old LIB files, you may want to use the ideas here
<http://support.microsoft.com/?id=131313>http://support.microsoft.com/?id=131313
to try to get a VS2005-supported .LIB file from the .DLL and/or header files.
>Looking closer at the error generated:
>
>error LNK2028: unresolved token (0A00000C) "int __cdecl ObjectCreate(char
>*,char,char *,int *)" (?ObjectCreate@@[EMAIL PROTECTED]) referenced in function
>"public: bool __clrcall WrapClass::Class1::SomeMethod(void)"
>([EMAIL PROTECTED]@WrapClass@@$$FQ$AAM_NXZ)
>
>I can see that the ObjectCreatemethod (implemented in the native .dll) has a
>"__cdecl" calling convention whereas my VS2005 method
>WrapClass::Class1::SomeMethod has it as "__clrcall". Since the CLR Support
>is set to "/clr" (there is no way to set it to anything else) I believe it
>overwrites the calling convention selected.
I think you're mis-stating (or mis-interpreting) what the message means. It
says that it can't find (meaning that it can't link to) any implementation of a
method named ObjectCreate with the definition specified. It's identifying your
code's SomeMethod as the place where it sees the need to find a matching call
to ObjectCreate. The fact that your method is annotated with __clrcall is just
part of its description of the problem method (like the fact that it's a public
method returning bool).
The message is saying that your code's call to ObjectCreate will be made with
__cdecl -- but the linker can't find that method, possibly because the method
in the DLL isn't a cdecl method.
There are a lot of possible ways this could get out of synch. For example,
ObjectCreate could be a stdcall function, but a new MC++ default (or your
changes to the header file) resulted in your code indicating that cdecl should
be used.
What's the declaration of ObjectCreate in the header file? (Did you change it
from what you had before?)
>I'll keep digging. All the Internet resources I read so far don't talk about
>linking the actual native ".dll" into your Managed C++ Project.
Remember that the Windows API consists entirely of "actual native .dll" files.
The difference is that the header files and .LIB files you get that describe
the Windows API actually match what's in the DLLs, and that seems not to be the
case with what you've got.
>Thanks,
>Eddie
>
>-----Original Message-----
>From: Peter Ritchie
>Sent: Wednesday, July 19, 2006 3:56 PM
>To: [email protected]
>Subject: Re: [ADVANCED-DOTNET] Linking an unmanaged C++ .dll in a VS.NET 2005
>Managed C++ Class Library
>
>
>Is this a Visual Studio 2005 generated LIB file?
>
>Visual Studio is notoriously bad for supporting LIB files generated with a
>different Visual Studio version, especially LIBs for DLLs.
J. Merrill / Analytical Software Corp
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
