Unresolved external character error in exe but not in dll

Question

I have a library (dll) that provides a class along with its constructors, which are supposed to be used in other modules (exe and dll). I can create an instance of this class from other library modules, but not exe modules. I get a linker error - "LNK2019 error: unresolved external character" during linking. I am confused why the binding succeeds when used in other library projects and not in an exe project. Can someone help me with this?

the following class declaration:

class __declspec(dllimport) MyException { public: MyException(unsigned int _line, const char *_file, const char *_function, MyExceptionType _type, const wchar_t* _message = 0, ...); }; 

That’s the whole error: LNK2019 error: unresolved external character "__declspec (DllImport) public: __cdecl MyException :: MyException (unsigned integer value, char anti *, char anti *, enumeration MyException :: MyExceptionType, unsigned short anti * *, ... ) "(_imp ?? 0MyException @@ QAA @ IPBD0W4MyExceptionType @ 0 @PBGZZ) link to the public function: __thiscall MyClassUsesMyException :: MyClassUsesMyException (class SomeClass *, Int)" (?? 0MyClassUsesMyException @@ Qomezlass @ ZomeClass )

MyClassUsesMyException is thrown in 'MyApp.cpp'.

Thanks, Rakesh.

Answer 1

Update: wchar_t Not always native

After a fairly lengthy exchange of information and some additional information from the OP, the problem matters:

 class __declspec(dllimport) MyException { public: MyException(unsigned int _line, const char *_file, const char *_function, MyExceptionType _type, const wchar_t* _message = 0, // <<== note wchar_t type ...); }; 

Visual C ++ can be configured to treat wchar_t as a native type or not. Unless considered as a native type, unsigned short is the specified macro substitution for wchar_t . Linker complained that the above function was unsolvable, but what really caught my attention was at the tail of the undefined character:

 ,unsigned short const *,...) 

Pay attention to unsigned short . This reminded me that the compiler used non-native wchar_t when compiling the EXE. I thought it was possible that the DLL might have been compiled with wchar_t configured as native, thereby introducing a different signature and thus not matching the reference time.

If you are surprised that this was a problem, imagine how surprised Rahkesh and I = P

---

Original answer

This class should be in the same general header with the preprocessor logic to determine the correct status of the import / export declaration. For instance:

Mydll.h

 #ifndef MYDLL_H #define MYDLL_H // setup an import/export macro based on whether the // DLL implementing this class is being compiled or // a client of the DLL is using it. Only the MyDLL.DLL // project should define MYDLL_EXPORTS. What it is // defined as is not relevant. *That* it is defined *is*. #ifdef MYDLL_EXPORTS #define MYDLL_API __declspec(dllexport) #else #define MYDLL_API __declspec(dllimport) #endif class MYDLL_API MyException { // your class definition here... }; #endif 

Then, in your DLL project that implements the exception (and only in this project), add MYDLL_EXPORTS to the list of preprocessors in your project configuration.