c++ one solution two projects (exe & dll) linking error

Question

I have one Visual Studio solution which consists of two win32 projects: 1) application (.exe) 2) functions wrapper (.dll).

The solution is in prototyping stage so all classes/functionality are implemented under (.exe) project - dirty but quick and easy for debugging/testing.

I've started to write a DLL wrapper to "play" with functionality in MSExcel/VBA and faced linking error

error LNK2019: unresolved external symbol "public: __thiscall Date::Date(int,int,int)" (??0Date@@QAE@HHH@Z) referenced in function addNumbers

DLL header file:

#ifdef LIBRARYWRAP_EXPORTS
#define LIBRARYWRAP_API __declspec(dllexport)
#else
#define LIBRARYWRAP_API __declspec(dllimport)
#endif

LIBRARYWRAP_API int _stdcall addNumbers(int a, int b);

DLL source file:

#include "..\applicationProject\Date.h"

class Date;
LIBRARYWRAP_API int _stdcall addNumbers(int a, int b){
   Date dummyDate(12,1,2014); // <- Linker error LNK2019.
   return (a+b);
}

Class Date and constructor Date::Date(int,int,int) are defined in application project(.exe) within Date.h , Date.cpp .

What I've tried to do already:

1. for librarywrap project added new reference. Project -> Properties -> Common -> Add New Reference . Selected "applicationProject".

2. added additional include directories: $(SolutionDir)\\applicationProject

Two questions:

First, Is that legal/achievable what I'm trying to do? DLL links to application project, whereas usually it should be other way round - application links to DLL. Hypothetically if i have two application projects (.exe) & (.exe) will it be possible to link one to another?

Second, If answer for first question is positive what should I add/change to make it work?

Thanks very much!

Nicholas

Answer 1

Technically, it is possible to make a DLL to call all needed functions from another modules (even from .exe ones - LoadLibrary can do this), but it would be a great pain: you will have to export all needed methods explicitly in the .EXE (just like you export DLL functions) and import them into your DLL. So the answer to the first question is yes, but if the DLL wants to use a lot of entry points from the EXE then probably it is not the best option.

I'd suggest a different approach: having a common code base for both .exe (application) and .dll projects. Then you will be able to test your code by running the application, and to use the functionality from other apps through the DLL (the DLL will contain all the necessary code itself).