Exposing .lib methods through another DLL - c++

Question

I have the following setup in my solution (all C++):
Project1, compiled as static library (.lib).
Project2, compiled as DLL, includes the .lib generated in 1.
Project3, includes the DLL generated in 2.
Now I want to expose functions of project1 to project3, without directly including the .lib of project 1. I keep having linker errors.
error LNK2001: unresolved external symbol
Project 1 is set up to use dllexport and dllimport in the following way (FOO_API is in front of the classes / methods to expose as well of course):
#if defined(FOO_STATIC)
#define FOO_API
#define FOO_TEMPLATE(type) template class type
#else
#ifdef FOO_EXPORTS
#define FOO_API __declspec(dllexport)
#define FOO_TEMPLATE(type) template class FOO_API type
#else
#define FOO_API __declspec(dllimport)
#define FOO_TEMPLATE(type) extern template class FOO_API type
#endif
#endif
Since we compile Project1 as a static library, the dllexport path won't be taken (we define FOO_STATIC). Via the DLL of Project2 however, I want to expose the methods of Project1. I tried to create a .cpp file in Project2 that defines FOO_EXPORTS and then includes the headers of the files containing the methods I want to export. So:
// somefile_that_will_be_built.cpp
#define FOO_EXPORTS
#include "a.h"
#include "b.h"
#include "c.h"
My hope was that this would trigger the dllexport code in Project1 so it would be included in the DLL of Project2. I hoped that when Project3 included Project1 headers it would go the dllimport path and than the linker would find the required methods. So:
#include "a.h"
class WrapThis:
public:
SomeMethodInA();
Project3 compiles, but during linking the SomeMethodA() is not found. Is my approach not possible? Do I need to write a module definition file in Project2 instead? I would hope to prevent this as we have some name ambiguity, and name mangling does not help either (I know this can be turned off, but I wouldn't want to do this for other reasons).
Any help would be appreciated as my experience in this part of development is limited.
UPDATE
Remaining errors (took 4 as example):
2>Stdafx.obj : error LNK2028: unresolved token (0A000683) "public: void __cdecl fooEx::Load(char const * const)" (? Load#fooEx#Namespace4#Namespace1#Namespace2#Namespace3##$$FQEAAXQEBD#Z) referenced in function "public: void __clrcall Namespace1::Namespace2::Namespace3::Namespace4::FooEx::Load(class System::String ^)" (?Load#FooEx#Namespace4#Namespace1#Namespace2#Namespace3##$$FQE$AAMXPE$AAVString#System###Z)
2>Stdafx.obj : error LNK2028: unresolved token (0A000684) "public: void __cdecl fooEx::LoadHeader(char const * const)" (?LoadHeader#fooEx#Namespace4#Namespace1#Namespace2#Namespace3##$$FQEAAXQEBD#Z) referenced in function "public: void __clrcall Namespace1::Namespace2::Namespace3::Namespace4::FooEx::LoadHeader(class System::String ^)" (?LoadHeader#FooEx#Namespace4#Namespace1#Namespace2#Namespace3##$$FQE$AAMXPE$AAVString#System###Z)
2>Stdafx.obj : error LNK2028: unresolved token (0A000686) "public: void __cdecl fooEx::Save(char const * const,double,double)" (?Save#fooEx#Namespace4#Namespace1#Namespace2#Namespace3##$$FQEAAXQEBDNN#Z) referenced in function "public: void __clrcall Namespace1::Namespace2::Namespace3::Namespace4::FooEx::Save(class System::String ^,double,double)" (?Save#FooEx#Namespace4#Namespace1#Namespace2#Namespace3##$$FQE$AAMXPE$AAVString#System##NN#Z)
2>Stdafx.obj : error LNK2028: unresolved token (0A000687) "public: void __cdecl fooEx::Save(char const * const)" (?Save#fooEx#Namespace4#Namespace1#Namespace2#Namespace3##$$FQEAAXQEBD#Z) referenced in function "public: void __clrcall Namespace1::Namespace2::Namespace3::Namespace4::FooEx::Save(class System::String ^)" (?Save#FooEx#Namespace4#Namespace1#Namespace2#Namespace3##$$FQE$AAMXPE$AAVString#System###Z)
Project1 - classA (compiled with FOO_EXPORT) into static lib.
class FOO_API fooEx : public foo
{
public:
fooEx();
virtual void Free();
void Load(const char filename[]);
void LoadHeader(const char filename[]);
virtual void LoadRawData();
void Save(const char filename[]);
}
May be important:
Project1 uses precompiled headers.
Load & LoadHeader are defined in multiple files in the exact same way (other extensions of foo class).
virtual methods are defined in the base class as well as in the other implementations of that base class.
Project2 - Compiled as DLL. Includes Project1.lib via Linker input, additional dependencies.
Project3 - Compiled as DLL. Example class that has methods that cannot be linked.

Answer 1

This cannot work of course, the .lib code was compiled with the wrong #define in effect. So its functions won't be exported.
You'll either have to rebuild the .lib with FOO_EXPORTS defined or write a .def file that lists the functions that must be exported. Rebuilding is of course by far the least painful solution, you could simply add another configuration to the lib project and include the project in your DLL solution. Or always build the lib with FOO_EXPORTS defined, it is still a static library that can be linked into a non-DLL project.

Answer 2

All the compiled binary code for project1 is contained within the .lib file.
You can't use it from another project without including it at compilation time.
You could redefine the parts of project1 that you wish to share at run time as a shared library (i.e. a DLL).