0

I have a solution which consists of a native C++ DLL and a C++/CLI wrapper. My aim is to create a wrapper in C++/CLI of the native C++ DLL.

Whenever I try to create an instance of a native C++ class within the wrapper, I am met with many linker errors (see below).

2>  .NETFramework,Version=v4.0.AssemblyAttributes.cpp
2>NFileOperation.obj : error LNK2028: unresolved token (0A000208) "public: static bool __cdecl CFileOperation::FileExists(class ATL::CStringT<wchar_t,class ATL::StrTraitATL<wchar_t,class ATL::ChTraitsCRT<wchar_t> > > const &)" (?FileExists@CFileOperation@@$$FSA_NABV?$CStringT@_WV?$StrTraitATL@_WV?$ChTraitsCRT@_W@ATL@@@ATL@@@ATL@@@Z) referenced in function "[T2M] void __clrcall `dynamic initializer for 'public: static float * tagVARIANT::* ATL::CVarTypeInfo<float *>::pmField''(void)" (__t2m@???__E?pmField@?$CVarTypeInfo@PAM@ATL@@2QQtagVARIANT@@PAMQ3@@@YMXXZ@?A0x22b777aa@@YMXXZ)
2>DeskUpdateManaged.obj : error LNK2028: unresolved token (0A00021C) "public: static bool __cdecl CFileOperation::FileExists(class ATL::CStringT<wchar_t,class ATL::StrTraitATL<wchar_t,class ATL::ChTraitsCRT<wchar_t> > > const &)" (?FileExists@CFileOperation@@$$FSA_NABV?$CStringT@_WV?$StrTraitATL@_WV?$ChTraitsCRT@_W@ATL@@@ATL@@@ATL@@@Z) referenced in function "public: bool __clrcall DeskUpdateManaged::Conversion::FileExist(class System::String ^)" (?FileExist@Conversion@DeskUpdateManaged@@$$FQ$AAM_NP$AAVString@System@@@Z)
2>DeskUpdateManaged.obj : error LNK2019: unresolved external symbol "public: static bool __cdecl CFileOperation::FileExists(class ATL::CStringT<wchar_t,class ATL::StrTraitATL<wchar_t,class ATL::ChTraitsCRT<wchar_t> > > const &)" (?FileExists@CFileOperation@@$$FSA_NABV?$CStringT@_WV?$StrTraitATL@_WV?$ChTraitsCRT@_W@ATL@@@ATL@@@ATL@@@Z) referenced in function "public: bool __clrcall DeskUpdateManaged::Conversion::FileExist(class System::String ^)" (?FileExist@Conversion@DeskUpdateManaged@@$$FQ$AAM_NP$AAVString@System@@@Z)
2>NFileOperation.obj : error LNK2001: unresolved external symbol "public: static bool __cdecl CFileOperation::FileExists(class ATL::CStringT<wchar_t,class ATL::StrTraitATL<wchar_t,class ATL::ChTraitsCRT<wchar_t> > > const &)" (?FileExists@CFileOperation@@$$FSA_NABV?$CStringT@_WV?$StrTraitATL@_WV?$ChTraitsCRT@_W@ATL@@@ATL@@@ATL@@@Z)
2>C:\Users\ABGZAMANK\Music\DeskUpdate\Dev\Source\Solution\Debug\DeskUpdateManaged.dll : fatal error LNK1120: 3 unresolved externals

Function call within the C++/CLI to the native C++ DLL:

bool NFileOperation::FileExists(CAtlString sPathName)
{
    return CFileOperation::FileExists(sPathName);
}

Is there a more adequate approach to what I am trying to achieve? Any advice relating to the issue is much appreciated.

Alex
  • 669
  • 15
  • 37
Khalid Zaman
  • 3
  • 3

1 Answers1

0

It seems that your native C++ code is using ATL/MFC. Assuming you are compiling under VS, go to the C++/CLI project's project properties->Configuration properties->General and select "Use of MFC" and "Use of ATL" to be either static library or shared dll (depending on your project type). This flag will add the necessary include paths, linking paths and libs to your project to make use of ATL/MFC types from within your project. Also, make sure that you are linking your C++/CLI project against your native C++ project to avoid linking errors from your project (easily found in the Linker segment of the project properties in General and Input).

eladidan
  • 2,634
  • 2
  • 26
  • 39
  • I tried compiling the project with the ATL and MFC as static and as dynamic libraries but they failed to compile within debug mode. The project did however compile in release mode and the linker errors still occur. Please can you explain what you mean by linking the C++/CLI project against the native C++ (I'm not sure if I have done it correctly)? – Khalid Zaman Feb 13 '13 at 15:42
  • @Khalid: Is your native C++ code and managed wrapper part of the same project? That is strongly inadvisable. You should keep them separated in different assemblies (projects). See http://stackoverflow.com/questions/4642702/wrapping-unmanaged-c-with-c-cli-a-proper-approach – eladidan Feb 13 '13 at 16:34
  • @Khalid: Also, does your native C++ dll create an export library? It definitely should, otherwise you will need to call methods using LoadLibraryEx... If it does, you need to link against the import lib in your C++/CLI wrapper project the same way Nico commented in your question. – eladidan Feb 13 '13 at 16:38
  • Sorry about the late reply. The native C++ dll and the C++/CLI wrapper are in separate projects within the same solution. The library is exported and I have referenced the folder and the lib like Nico mentioned. – Khalid Zaman Feb 15 '13 at 14:24