☰

Sistema de construção

tag-icon • tag-icon visual-studio dll libraries c++ cpu-architecture
Sistema de construção

Atualmente estou criando um aplicativo OpenGL no Visual Studio 2015 e vinculei e incluí com êxito todas as minhas coisas para GLFW, GLEW, etc.

Porém, quando executo meu aplicativo, preciso incluir glew32.dll, sem problema algum. Eu apenas pego a dll x64 e adiciono-a à pasta do projeto. No entanto, agora, quando executo meu programa no modo de 32 bits, ele quebra e vice-versa se eu usar a DLL de 32 bits em um programa de 64 bits. A única solução barata para isso é incluir DLLs específicas da arquitetura nas pastas de construção.

Existe uma maneira de incluir as DLLs com base em uma arquitetura específica, porque quero hospedar meu programa resultante em um formato como:

Diretório de programas

  • jogo.exe
  • game_x64.exe
  • x64 (pasta)
    • glew32.dll
  • x32 (pasta)
    • glew32.dll

Se algo assim não for possível, estou mais do que feliz em ter um glew32.dlle glew32_x64.dllalojado em uma pasta, mas isso provavelmente nunca acontecerá porque a biblioteca não está procurando a nova dll ...

Responder1

O artigo sobreOrdem de pesquisa da biblioteca de link dinâmicona verdade, também tem algo sobre como alterar a maneira como um aplicativo procura uma DLL. Ou seja, está fazendo referênciaSetDllDirectoryeLoadLibraryExe até mais alguns.

Responder2

Existem várias maneiras de resolver o problema.

Sistema de construção

O MSBuild possui muitos recursos que não podem ser controlados pela GUI do Visual Studio. Você pode usar variáveis ​​em quase todos os lugares, às vezes condições também.

Você pode declarar blocos condicionais em seu .vcxprojarquivo (que é apenas XML),assim:

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

Existem outras soluções, comoEste:

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

Ele não resolve seu problema diretamente, mas fornece informações adicionais sobre os recursos do MSBuild.

Certa vez, tive uma solução funcional para um problema muito semelhante (referenciando bibliotecas nativas do .NET com compilações de depuração/lançamento), mas ela permaneceu com meu empregador anterior.

Se achar que o MSBuild é muito restrito, você sempre pode criar tarefas pós-compilação.

Esta solução também pode fazer parte da solução de diretório separado de arquitetura dupla mencionada abaixo porque ajuda a automatizar melhor o processo de construção.

Pré-carregamento de DLL

Chame LoadLibraryou LoadLibraryExe carregue a DLL correta manualmente. Isso só é possível se você tiver controle antes que a DLL seja carregada automaticamente pelo carregador do sistema operacional.

Diretórios separados

Coloque um inicializador no diretório de nível superior. Em seguida, coloque as compilações x86 e x64 em diretórios separados:

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

Caminho de pesquisa

IMHO, isso nunca deveria ser necessário em um ambiente completamente controlado.

informação relacionada