[Day21~Day23] DLL generated, but not loaded/used.

EDIT:
TL;DR: DLL generated. Don't know how to get the EXE to load the DLL that was dynamically compiled/build after EXE finishes compiling and starts executing in Visual Studio 2013. Would like a solution for this.

I'm probably making a mess in my solution directory in Visual Studio 2013.

The DLL has been generated, as shown here.



I have made my HandmadeHeroEXE project dependent on HandmadeHeroDLL project in the Solution Project Dependencies manager.

But the most confusing of all is LoadLibrary() not loading the handmade.dll, even when using an absolute file path. So, it isn't being used or loaded in correctly.

Here's a picture of my Project Properties configuration:

HandmadeHeroDLL Project Properties:



HandmadeHeroEXE Project Properties:



Is it because of the output directories/intermediate directories? Or is there something else I'm not doing right?

Edited by Thompson Lee on
Looks like your DLL is being built as 64-bit (x64 platform), but your executable is 32bit (Win32 platform).
Does that actually make a difference? I was wondering since the end result was the same. :S


I quickly did a check to see if I can make the executable to for the x64 platform, but it gave me an error after setting it up in the configuration manager, saying:

This platform could not be created because a solution platform of the same name already exists.

Fixing that gave another error when building:

Debugging information for 'HandmadeHeroEXE.exe' cannot be found or does not match. Binary was not built with debug information.

Do you want to continue debugging?

Pressing Yes still gives the same results, which is the DLL wasn't loaded/used.

Edited by Thompson Lee on
After mucking around for 10 hours, I was able to export functions into the DLL, but I'm not happy.

In Day 21, Casey mentions using __declspec(dllexport) to export a function out into the DLL, but then said to use /EXPORT linker command switch to minimize platform dependency. Is he implying that we could use either the /EXPORT or the __declspec(dllexport), and not worry about future cross-platform, non-platform-specific building/compiling?

I started to do some research on exporting functions to DLL. It turns out that you can't export functions without using __declspec(dllexport) or /EXPORT linker command.

So, for 10 hours, I am looking for a way to make the code work that takes 30 seconds to fix. Thus, I'm not happy.

Please enlighten me, is there a way to export functions into DLLs without specifying __declspec(dllexport) or using the /EXPORT? If not, I guess this is the only way to go, and I'm going to move on.

Edited by Thompson Lee on
Does that actually make a difference?
Yes it makes a difference. You can not use 32-bit in 64-bit process directly and vice versa.

This platform could not be created because a solution platform of the same name already exists.
That means to are trying to add solution platform which already exists. So don't do that. Add only new project platform for HandmadeHeroEXE project.

Instead of /EXPORT you can use __declspec(dllexport). It doesn't matter which one. Both will get you same result. Casey simply doesn't want to put compiler specific things (__declspec) in game code so he uses /EXPORT cmdline option. Third option would be to use .def file - you can put names of exported functions and use /DEF linker option to point to .def file.
Thanks, that cleared things up nicely.