Sorry, I missed the part about the other version being 6.0. Most library vendors supply a LIB (or LIB/DLL combo, depending) for each version of Visual Studio because Visual Studio just can't support LIBs from different versions (well, a LIB for DLL, maybe; but, it's better to just regenerate the LIB from the DLL with the latest librarian).
Take a LIB compiled for VC6.0 it's going to want to pull data and code into it's data and code segments for the CRT from one of several versions of msvcrt.dll. When you compile an application for VC80, it's going to pull data and code into it's data and code segments from msvcur.dll or msvcm80.dll, depending on your compiler switches. If you try and compile an application pulling in a LIB expecting code and data from MSVCRT.dll and the application is expecting code and data in MSVCUR/MSVCM80.dll you're going to get collisions. Add to the fact that most of the CRT was re-written or a complete set of "safe" functions were added, or that much work was done with MFC templates in VC80, you increase the liklihood that something is going to conflict. Specific to the warning you posted, "SomeMethod" is in the LIB? On Wed, 19 Jul 2006 16:16:12 -0400, Eddie Lascu <[EMAIL PROTECTED]> wrote: >No Peter, it was not generated with VS2005. Like I said, I believe it was >generated with VC++ 6.0 (I have also received same sample projects and they >appeared to be developed in VC++ 6.0). I don't have the code to recompile >it. The distributable ".dll" file is all I have. > >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'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. > >Thanks, >Eddie > > >-----Original Message----- >From: Discussion of advanced .NET topics. >[mailto:[EMAIL PROTECTED] Behalf Of 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. > >On Wed, 19 Jul 2006 14:54:29 -0400, Eddie Lascu <[EMAIL PROTECTED]> >wrote: > >>Hello Experts, >> >>I have this third party .dll that was developed in Visual C++ 6.0. I have >>the ".lib" file and also some header files to include in my project. I am >>trying to wrap it into a Managed C++ Class Library developed in Visual >>Studio.NET 2005. I picked Managed C++ because I read the interoperation is >>easier from C++ than C# or VB.NET. >>Anyway, I am getting linkage errors for virtually every call into the >>library (LNK2028 paired with LNK2019). I have linked the ".lib" file and >>made sure the ".dll" file is found in the local folder, but I still get >>these linkage errors. >>This library is quite old and I had to make some changes in the header >files >>to make them compile. I read about the myriad of compilation/linkage >>directives and I am at loss with them. >> >>Are there any web recourses to guide me through all the steps that need to >>be followed to get this to compile and link? =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
