   [.net] Problem with linker in C++/CLI project
  Hi there!I have a problem when linking a C++/CLI DLL that is supposed to serve as a wrapper for an unmanaged DLL of mine for the use in a C# project.While most functions don´t make any problems, two functions result in an "unresolved token" (LNK2028) and an "unresolved external" (LNK2019) error for each of them. All of this functions should reside in the same lib, which I added to the additional dependencies. Furthermore I added the folder it resides in to the "Additional library directories".One thing is common to the two function that don´t work: They both require 3 LPCTSTRs as parameters. The functionos that work don´t need any LPCTSTRs. Seems a wild guess to me but perhaps this somehow is related to the problem?Here is the source of the header of the used lib:namespace PUKE{class __declspec(dllexport) Engine{public:Engine(void);~Engine(void);intInit(HWND inWindowHandle, bool fullScreen);intUpdate(LONGLONG time);void   ShutDown();intAddStaticObject(LPCTSTR meshLoc, LPCTSTR effectLoc, LPCTSTR colorTex, float x, float y, float z);boolRemoveStaticObject(int inID);intAddDynamicObject(LPCTSTR meshLoc, LPCTSTR effectLoc, LPCTSTR colorTex, float x, float y, float z);boolRemoveDynamicObject(int inID);Renderable*GetDynamicObject(int inID);private:HWNDm_WindowHandle;GFX::Graphics*m_pGraphics;};};Both AddStaticObject(...) and AddDynamicObject(...) result in the errors described above, while the other eight functions in there are fine.I´m again quite clueless about this error, because all these functions reside in the same class in the same lib and therefore should be found without a problem.The calls to those two functions in the C++/CLI project look like this:int EngineWrapper::AddStaticObject(LPCTSTR meshLoc, LPCTSTR effectLoc, LPCTSTR colorTex, float x, float y, float z){return m_pEngine->AddStaticObject(meshLoc, effectLoc, colorTex, x,y,z);}int EngineWrapper::AddDynamicObject(LPCTSTR meshLoc, LPCTSTR effectLoc, LPCTSTR colorTex, float x, float y, float z){return m_pEngine->AddDynamicObject(meshLoc, effectLoc, colorTex, x,y,z);}m_pEngine is a PUKE::Engine*, and those two wrapper functions do essentially the same as every other function in that wrapper, that is passing the call to the wrapper over to that PUKE::Engine*.Any ideas appreciated, thx for reading.   
  Ok first you really should not be exporting the entire class it is not neccessary to do.  You should read washu's articles on dll's.DLL'SHowever, I don't think that is your problem.  You should go into the project settings and check your Character set.  By default in a project it uses UNICODE.  If that string is not defined because of unicode which I believe it is not it would cause your linker errors.  You should set your Character Set to None or the equivalent that it says.  It should solve your problem.   ;  Thank you very much! Checking the character set did the trick, as it was differing from the character set in the unmanaged DLL.That article from Washu looks pretty much like the PDF I read about C++/CLI wrappers, which I´m following right now.The header in my first post is not the one from the wrapper, it is from my unmanaged graphics engine. Frankly I don´t know how I could export less than the complete class, because I need an instance of the Engine class in the application that uses it.Could I just export selected functions of that class including constructor and destructor and still instantiate an object of that class in the application using it?   ;  Glad I could help you.When you export a class you can run into some issues.  The way you would get at the class is through a interface to the class.  In washu's articles down tward the bottom I think the second entry of his DLL's series explains it.If you are interested here is the article.  This is the way the Irrlicht team did their engine.Interface injectionBasically it works by a single external function from the interface being implemented returning a class that inherits from the interface to the interface.  Allowing you to use the interface to so call "Export the class"  It is very intuitive and works really well I implemented a variation of this example and was shocked at how well it works.;  So, basically, instead of exporting the class itself, I define an interface and export a single function that returns a new instance of a class that implements that interface, right?In doing so I can "hide" functions, constructors and destructors and member variables of the returned class from the user of that interface, I guess, which seems to be a reasonable thing to do.Perhaps I don´t understand the implications of that fully, but are there any other reasons to do this? You mentioned problems when exporting complete classes? Were you thinking of that "He who allocates it, deallocates it" problem or something like that?Thx for taking the time ;)   