☰

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

tag-icon • tag-icon visual-studio dll libraries c++ cpu-architecture
Система сборки

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

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

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

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

  • игра.exe
  • game_x64.exe
  • x64 (папка)
    • glew32.dll
  • x32 (папка)
    • glew32.dll

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

решение1

Статья оПорядок поиска в динамической библиотекена самом деле есть что-то о том, как изменить способ, которым приложение ищет DLL. А именно, ссылаетсяSetDllDirectoryиLoadLibraryExи даже больше.

решение2

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

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

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

Вы можете объявить условные блоки в своем .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

Путь поиска

По моему скромному мнению, в полностью контролируемой среде это никогда не понадобится.

Связанный контент