ID:1619961
 
(See the best response by DarkCampainger.)
How should I build/compile my .dll in Visual Studio Express 2013?

I can use my Dynamic Library with ease, but when I let somebody else use it, they get an error saying "Library could not be loaded" or such.

Any tips?
Do you mean that the dll file can not be found after you compile and run the game? If so, would something like this help?

var/dll = list(
1 = 'Files/DLLs/Test.dll',
2 = 'Files/DLLs/Test2.dll',
3 = 'Files/DLLs/Test3.dll',
4 = 'Files/DLLs/Test4.dll',
)


You'd use them like this:
//dll[1] -> Test.dll
//dll[2] -> Test2.dll
//dll[3] -> Test3.dll
//dll[4] -> Test4.dll
No haha, not at all. The file does exist, just when I have somebody run it, like so:

call("xinputBYOND.dll","ConnectController")()


the library "xinputBYOND.dll" can not be loaded.
It exists in the directory, just dream seeker won't load it
I imagine these days you need to compile and link with /LD /MD in order to link up against the multi-threaded DLL version of msvcrt, which is what BYOND presumably also requires. By default in Visual Studio, you build a DLL with just /LD, which implies /MT and so statically links in msvcrt, which I would guess causes issues with the loaded symbol tables for BYOND when it tries to dynamically load your DLL, as you'll be linked statically against whatever VS 2013 has provided, and they'll be on another system with probably another provided version of msvcrt.

Bandock is probably more up on what's required here, these days.

Also, have you defined a DLL entry point like DllMain at all?

When I create a new DLL in VS13, the DllMain is created by default with entry points.

I'm not really sure what to do here, I can use these dlls myself but when I distribute them to somebody else, it fails to load.
Yeah, my guess being a matter of msvcrt versions available on their system, versus what you have linked against for your DLL?
// dllmain.cpp : Defines the entry point for the DLL application.
#include "stdafx.h"

BOOL APIENTRY DllMain( HMODULE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}


is the default settings of the dllmain
Looking at my code generation, my Runtime Library is /MD.
In response to Stephen001
Best response
Stephen001 wrote:
Yeah, my guess being a matter of msvcrt versions available on their system, versus what you have linked against for your DLL?

It's probably this. When I first released my DLLs, I was building against v100 of the toolset and a fair number of people didn't have the corresponding Microsoft Visual C++ 2010 Redistributable Package installed. I eventually found a way to downgrade to v90 (MSVC 2008) which worked for most out of the box. You could probably aim higher nowadays.

Looks like VS2013 defaults to v120 of the toolset. If they're willing, see if downloading Visual C++ Redistributable Packages for Visual Studio 2013 solves the problem.

If you want to target a lower toolset, you can go into your project's properties and lower the "Platform Toolset" property. It's under Configuration Properties > General in VS2010 (not sure if it's still there in VS2013).

If no other platforms are available, you'll have to install an older release of Visual Studio, and then you can select it in VS2013. I believe the "Express" versions work for this, but it's been so long I don't entirely remember how I set it up.
Thanks @Stephen001 and @DarkCampainer.

@DarkCampainger

I could select the older versions, just it tells me it can't be found so I have to install them. I tried it in VC2008 and had a few errors I didn't feel like dealing with but they were resolved in the VC2010.