Jump to content
  • Advertisement
Sign in to follow this  
matches81

[.net] Problem with linker in C++/CLI project

This topic is 4522 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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);

	int			Init(HWND inWindowHandle, bool fullScreen);
	int			Update(LONGLONG time);

	void		        ShutDown();

	int			AddStaticObject(LPCTSTR meshLoc, LPCTSTR effectLoc, LPCTSTR colorTex, float x, float y, float z);
	bool			RemoveStaticObject(int inID);

	int			AddDynamicObject(LPCTSTR meshLoc, LPCTSTR effectLoc, LPCTSTR colorTex, float x, float y, float z);
	bool			RemoveDynamicObject(int inID);
	Renderable*		GetDynamicObject(int inID);

private:

	HWND			m_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.

Share this post


Link to post
Share on other sites
Advertisement
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'S

However, 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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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 injection

Basically 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.

Share this post


Link to post
Share on other sites
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 ;)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!