By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,156 Members | 1,004 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,156 IT Pros & Developers. It's quick & easy.

'Unresolved External' when calling unmanaged DLL from managed Windows Forms executable

P: n/a

I'm a newbie in Visual C++ .NET (have programmed in Borland C++
and Builder for long) and I am trying to do a very simple thing,
but I'm stuck.

I created an (unmanaged) DLL project with a sample function, and
tried to call it from a ".NET Forms" project. All I get are
"Unresolved External" errors from the Linker!

When I try to call the same functions from a "Pure Win32" or a
Console Application, everything works well!

What could be happening? I'm sure it's something very trivial
and silly, but I'm stuck!

What I've done so far:

- Created the DLL, using Visual Studio default macros
- Exported the class contained in the DLL that I want to use.
- Compiled the DLL, OK
- Created a Windows Forms project, with one button that tried to
instantiate the class defined in the DLL and call its function.

Configurations for the Windows Forms Executable Project:
General - Additional Include Directories: ..\DrawDll
General - Additional Library Directories: ..\DrawDll\Release
Input - Additional Dependencies:

I have 2 projects in the solution, each one on its own directory.

That's all that was necessary for the Console AND for the Win32
versions to work! However, on this project I'm getting:

Form1.obj : error LNK2001: unresolved external symbol "public:
__thiscall Project::CDrawDll::CDrawDll(void)"
Form1.obj : error LNK2001: unresolved external symbol "public: void
__thiscall Project::CDrawDll::MyMethod(void)"

Any clues?

Here are the files being used:

#define DRAWDLL_API __declspec(dllexport)
#define DRAWDLL_API __declspec(dllimport)

// This class is exported from the DrawDll.dll
class DRAWDLL_API CDrawDll {
void MyMethod(void);


#include "stdafx.h"
#include "DrawDll.h"
#include <stdio.h>

DWORD ul_reason_for_call,
LPVOID lpReserved
switch (ul_reason_for_call)
return TRUE;

void CDrawDll::MyMethod(void)
OutputDebugString("It Worked!");
The Project.cpp and Project.h files are just the default
"Windows Forms Application (.NET)" generated files, plus
the code to try and run the DLL:

#include <windows.h>
#include <stdio.h>
#include "DrawDll.h"

public __gc class Form1 : public System::Windows::Forms::Form


private: System::Void button1_Click(System::Object * sender,
System::EventArgs * e)

CDrawDll lala;

#include "stdafx.h"
#include "Form1.h"
#include <windows.h>

using namespace Project;

int APIENTRY _tWinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPTSTR lpCmdLine,
int nCmdShow)
System::Threading::Thread::CurrentThread->ApartmentState =
Application::Run(new Form1());
return 0;

Thanks for any help!
Nov 17 '05 #1
Share this Question
Share on Google+
3 Replies

P: n/a
These two titles in the docs might help.

"Accessing C++ Code from .NET Framework Objects"

"Platform Invocation Services"
Nov 17 '05 #2

P: n/a
Greetings! Thank you very much for some reply. I wonder if my question is
so obvious nobody cared to answer or if, theoretically, I was doing things
right and it should be working, so things are more complicated!

As said on the 2nd link,
"Platform Invocation Services"
, *An important and unique feature of Managed Extensions for C++ is that you
can use unmanaged APIs directly. Data marshaling is handled automatically.
If you do not require customized data marshaling, you do not need to use
PInvoke. *
This is what I actually want to do. I'm using Managed Extensions for C++! My
Executable project is in C++, not on C#, Visual Basic or
any other language. Should the marshaling still be necessary?

*Advantages of IJW There is no need to write DLLImport attribute
declarations for the unmanaged APIs the program uses. Just include the
header file and link with the import library.


There, I've included the header file and included the .LIB file. Isn't that
what I am really supposed to do? Am I doing something wrong?

I checked the .DLL file with depends.exe and found out the decorated name
for the function is


but the linker error mentions

"public: void __thiscall Project::CDrawDll::MyMethod(void)"

Could this @Project@ reference be the reason why it isn't resolving the
symbol? "Project" is the name I gave for the 'Windows Forms Executable"
project, that tries to use the DLL.

Thanks for any help!

Nov 17 '05 #3

P: n/a
I'm in the same boat as you. I'm just beginning to learn C++ with extension,
and the first thing I tried is to call a C++ class which is located in a
DLL. I looked high and low and found no help in how to do so. That's
probably why one of those links limits itself to directly calling functions
in a DLL. I finally came to the conclusion that it is not possible, which is
probably why the other link suggested wrapping the C++ class, which is what
I am finally now doing. As an aside, in case it is helpful, my wrapping
class only exposes managed types, e.g., Int32, IntPointer, etc. I am
handling any necessary marshalling with my own code.
Nov 17 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.