Using DLL's and other files on an architecture basis

Question

I'm currently making an OpenGL application in Visual Studio 2015, and have successfully linked and included all my things for GLFW, GLEW, etc.

However when I run my application, I need to include glew32.dll, no problem at all. I just go and grab the x64 dll and add it to the project folder. However now when I run my program in 32-bit mode, it breaks, and vice-versa if I was to use the 32-bit dll on a 64-bit program. The only cheap fix to this is to include the architecture specific dll's to the build folders.

Is there a way I can include the dll's on an architecture-specific basis, because I want to house my resulting program in a form such as:

Program Directory

• game.exe
• game_x64.exe
• x64 (folder)
  • glew32.dll
• x32 (folder)
  • glew32.dll

If something like this isn't possible, I'm more than happy to have a glew32.dll and glew32_x64.dll housed in the one folder instead, but that'll probably never happen due to the library not looking for the new dll...

Answer 1

The article on Dynamic-Link Library Search Order actually has something on how to change the way an application looks for a DLL as well. Namely it's referencing SetDllDirectory and LoadLibraryEx and even some more.

Answer 2

There are multiple ways to solve the problem.

Build System

MSBuild has many features that cannot be controlled from the Visual Studio GUI. You can use variables almost everywhere, sometimes conditions, too.

You can declare conditional blocks in your .vcxproj file (which is just XML), like this:

<Choose>
  <When Condition="'$(Platform)' == 'Win32'">
    <ItemGroup>
      <Reference Include="SomeProject">
        <HintPath>..\Libraries\x86\SomeProject.dll</HintPath>
      </Reference>
    </ItemGroup>
  </When>
  <Otherwise>
    <ItemGroup>
      <Reference Include="SomeProject">
        <HintPath>..\Libraries\x64\SomeProject.dll</HintPath>
      </Reference>
    </ItemGroup>
  </Otherwise>
</Choose>

There are other solutions, like this one:

<Content Include="..\..\MyContentFiles\**\*.*">
  <Link>%(RecursiveDir)%(Filename)%(Extension)</Link>
  <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</Content>

It doesn’t directly solve your problem, but gives additional insight into MSBuild’s capabilities.

I once had a working solution for a very similar problem (referencing native libraries from .NET with debug/release builds), but it remained at my previous employer.

If you feel MSBuild is too restricted, you can always create post-build tasks.

This solution can also be part of the dual-architecture separate directory solution mentioned below because it helps better automate the build process.

DLL Preloading

Call LoadLibrary or LoadLibraryEx and load the correct DLL manually. This is only possible if you have control before the DLL is automatically loaded by the OS loader.

Separate Directories

Put a launcher in the top level directory. Then, put the x86 and x64 builds into separate directories:

.\Launcher.exe
.\x64\Game.exe
.\x64\glew32.dll
.\x86\Game.exe
.\x86\glew32.dll

Search Path

IMHO this shouldn’t ever be necessary in a completely controlled environment.