Использование DLL и других файлов на основе архитектуры

Question

В настоящее время я делаю приложение OpenGL в Visual Studio 2015 и успешно связал и включил все свои вещи для GLFW, GLEW и т.д.

Однако, когда я запускаю свое приложение, мне нужно включить glew32.dll , никаких проблем. Я просто иду и хватаю x64 dll и добавляю его в папку проекта. Однако теперь, когда я запускаю свою программу в 32-битном режиме, она ломается, и наоборот, если бы я использовал 32-битную dll в 64-битной программе. Единственный дешевый способ исправить это - включить специфичные для архитектуры библиотеки DLL в папки сборки.

Есть ли способ, которым я могу включить DLL на основе конкретной архитектуры, потому что я хочу разместить свою результирующую программу в такой форме, как:

Каталог программ

• game.exe
• game_x64.exe
• х64 (папка)
  • glew32.dll
• х32 (папка)
  • glew32.dll

Если что-то подобное не возможно, я более чем счастлив иметь glew32.dll и glew32_x64.dll в одной папке, но это, вероятно, никогда не произойдет, потому что библиотека не ищет новую DLL. ..

Answer 1

В статье о порядке поиска в Dynamic-Link Library на самом деле есть кое-что о том, как изменить то, как приложение ищет DLL. А именно он ссылается на SetDllDirectory и LoadLibraryEx и даже на некоторые другие.

Answer 2

Есть несколько способов решить проблему.

Система сборки

MSBuild имеет много функций, которыми нельзя управлять из графического интерфейса Visual Studio. Вы можете использовать переменные почти везде, а иногда и условия.

Вы можете объявить условные блоки в вашем файле .vcxproj (который является просто XML), например так:

<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>

Есть и другие решения, такие как это:

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

Это не решает вашу проблему напрямую, но дает дополнительное представление о возможностях MSBuild.

Когда-то у меня было рабочее решение для очень похожей проблемы (ссылка на нативные библиотеки из .NET со сборками отладки / выпуска), но оно осталось у моего предыдущего работодателя.

Если вы чувствуете, что MSBuild слишком ограничен, вы всегда можете создавать задачи после сборки.

Это решение также может быть частью решения для отдельной директории с двойной архитектурой, упомянутого ниже, поскольку оно помогает лучше автоматизировать процесс сборки.

Предварительная загрузка DLL

Вызовите LoadLibrary или LoadLibraryEx и загрузите правильную DLL вручную. Это возможно только в том случае, если у вас есть контроль до автоматической загрузки DLL загрузчиком ОС.

Отдельные каталоги

Поместите лаунчер в каталог верхнего уровня. Затем поместите сборки x86 и x64 в отдельные каталоги:

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

Путь поиска

ИМХО, это никогда не должно быть необходимо в полностью контролируемой среде.