error LNK2019

[en.navarro]

Im having several problems with the error LNK2019.

I ve a class that derives from another:

//controller.h

#include MessagesNotifier_Client

class Controller : public MessagesNotifier_Client
{
public:

Controller();
~Controller();

void TempVerification(int a, int b);

};

//controller.cpp

Controller::Controller(){}
Controller::~Controller(){}

void Controller::TempVerification(int a, int b)
{
if ( abs(a - b) 23 ){
NotifyWarningMessage("warning"); //ERROR LNK2019

}

NotifyWarningMessage is a method defined in MessagesNotifier_Client.

Im using Visual Studio .net 2003. and I have a Solution with 2
projects. The controller class is in
the project A, and the MessagesNotifier_Client in project B:

===Solution "BigTest" (2 projects)
== - A
|
------ Controller.h
------ Controller.cpp
== - B
|
------ MessagesNotifier_Client.cpp
------ MessagesNotifier_Client.h

Any ideas where is the problem, or how I should configure VisualStudio?

Thanks for your support.

[Nickolay.Shustov]

Well...
In your example, project A uses the header(s) from project B.
This way project A makes the _declarations_ of project B objects
available for compilation.
But when linker tries to create the final output for the project A, it
looks for the _definitions_ of (method body, implementation, object
code) of the objects have been used (the final code executes the method
body, right?).
The source code for declarations usually reside in header (H, HPP)
files. For definitions - in CPP files.
(The commonly accepted approach is that the definition is put in header
only if the method is inline).
Everything's fine with the definitions of the objects from project A,
because the CPP files from this project were just compiled and linker
is aware of it. It automatically picks up the _object_ files were
produced from CPP files.
But the CPP files from project B were not the part of the project A
compilation process. Linker knows nothing about these ones and as a
result it cannot find the implementation of methods used from project
B.

If you do not want to include cpp files from project B into project A
(which is natural), you should "inform" the linker where to look for
the definitions which are not the results of project A compilation.

Possible solutions:
1. If project B produces statically linked library (.LIB file), the
..LIB filename with path should be put into the "Additional libraries"
linker parameters.
2. If project B produces dynamically linked library (.DLL file), it
also should produce the corresponding .LIB file which the consumers of
project B should link (the DLL dynamic loading - at run-time - is
possible too, but I skip this topic here for simplicity). See (1) for
what to do with that LIB.
3. If project B produces an executable (.EXE), the possible approach
would be to link an object file (.OBJ) which is produced by compiler as
a result of compilation. The name for this .OBJ file is usually the
same as for CPP file been compiled. Try to look up for it in output or
temporay folders of project B. Handle it the same way as you'd do in
(1).

I would recommend to look into the C++ standard, into compilation
process descripion in general and specifically to the description of
the "separated compilation" idea for more details.

Regards,
NSH