I have recently migrated my test code from a simple 1 file main.cpp project into 1 main project (just starts up my framework) and another project entirely of framework features (controls, graphics, etc).

Upon doing so and completing my first 2 classes (Core and RenderingWindow), I proceded to build the dll. It was built and created a .dll file. I copied this dll file into the exe folder of the main project. I also added the include path in the compiler settings for the framework folder.

But, for some reason the main project can't see 1 of my header files. It can see the other files of my framework though as per the attached picture.

Does anybody have any ideas what might be happening?

Well today the main project can successfully see the header when I type "#include C". So that is a plus. Must've been resolved when shutting down and restarting Code::Blocks and/or my pc. Anyways, now that it sees the header, for some reason it still can't call the method. I am now including "Core.h"

I think my linking might be off. My framework is building 3 files, *.dll, *.a, and 1 without an extension visible (Export Definition File). I have found some suggestions of linking to the *.a file which I did in the linker settings of Code::Blocks. That didn't help overall. I am also including the *.dll inside the main projects *.exe folder.

So now when I try calling InitializeCore() I get "not declared in this scope" and when calling Core::InitializeCore() I get "undefined reference to Core::InitializeCore()".

Core::InitializeCore() shows up in intellisense (or w/e Code::Blocks calls it).

Did you use LoadLibrary/GetProcAddress etc. to actually bind the functions inside the DLL? Just including a header file is not enough to make your application 'see' them..

Moreover, you cannot just export some classes and expect to use them like normal source files. A C-style interface (extern "C") with plain functions is often more convenient. The advantage is that your library will also be usable from any language supporting this model (which is most of the ones that support libs at all).

I would also recommend to refrain from storing parts of your code in a library unless this serves a clear purpose and your code is fully debugged and tested. Debugging external libraries is awfully painful, especially since you won't be able to jump into the code when an error arises.

Hope this helps.

Did you use LoadLibrary/GetProcAddress etc. to actually bind the functions inside the DLL? Just including a header file is not enough to make your application 'see' them..

Moreover, you cannot just export some classes and expect to use them like normal source files. A C-style interface (extern "C") with plain functions is often more convenient. The advantage is that your library will also be usable from any language supporting this model (which is most of the ones that support libs at all).

I would also recommend to refrain from storing parts of your code in a library unless this serves a clear purpose and your code is fully debugged and tested. Debugging external libraries is awfully painful, especially since you won't be able to jump into the code when an error arises.

Hope this helps.

Thanks for the explanation.

I did not use LoadLibrary/GetProcAddress. First time hearing about them - researching now.

I come from a more C# oriented background where the use of separate projects and frameworks/dll's made life easier. We put C# projects (framework dll's) out so others could build plugins if they wanted using our wrapped OpenTK graphic libraries and custom controls. We sandboxed the plugins so if they crashed it wouldn't crash the main app, so the plugins were essentially free to do whatever they wanted.

So, in C++ I'm guessing a separate framework dll / plugin structure isn't quite what I pictured. Does that mean for every function/method I want exposed from the framework I have to manually add the code to export it? If so, I will probably forget about the framework altogether...

Yes, you would have to tag your exported functions or use a .def file as you mentioned. The exact syntax also differs between platforms and compilers, so that's another issue.

All in all it's not that hard, but if there really is no specific reason for using a library (sharing between multiple applications, porting to other platforms, hiding/protecting code etc.) I would just include the framework from regular source code. It will save you a lot of headaches.

Thank you so much for that link Fredericvo. That is probably the cleanest sample/explanation I've seen on the subject.