Atualmente estou fazendo um aplicativo OpenGL no Visual Studio 2015, e vinculei e incluí todas as minhas coisas para GLFW, GLEW, etc.
No entanto, quando executo meu aplicativo, preciso incluir glew32.dll , sem problema algum. Eu apenas vou pegar o x64 dll e adicioná-lo à pasta do projeto. No entanto, agora, quando eu executo meu programa no modo de 32 bits, ele quebra, e vice-versa, se eu fosse usar a dll de 32 bits em um programa de 64 bits. A única solução barata para isso é incluir as DLLs específicas da arquitetura nas pastas de construção.
Existe uma maneira de incluir as dlls em uma base específica de arquitetura, porque quero abrigar meu programa resultante de uma forma como:
Se algo assim não for possível, estou mais do que feliz em ter um glew32.dll e glew32_x64.dll alojados na única pasta, mas isso provavelmente nunca acontecerá devido à biblioteca não estar procurando nova dll ...
O artigo sobre Ordem de pesquisa da biblioteca de vínculo dinâmico realmente tem algo sobre como alterar a maneira como um aplicativo procura por uma DLL também. Ou seja, ele está se referenciando SetDllDirectory e LoadLibraryEx e até mais alguns.
Existem várias maneiras de resolver o problema.
O MSBuild tem muitos recursos que não podem ser controlados a partir da GUI do Visual Studio. Você pode usar variáveis em quase todos os lugares, às vezes também em condições.
Você pode declarar blocos condicionais em seu arquivo .vcxproj (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, como esta :
<Content Include="..\..\MyContentFiles\**\*.*">
<Link>%(RecursiveDir)%(Filename)%(Extension)</Link>
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</Content>
Ele não resolve diretamente seu problema, mas fornece informações adicionais sobre os recursos do MSBuild.
Eu já tive uma solução funcional para um problema muito semelhante (referenciando bibliotecas nativas do .NET com compilações de depuração / release), mas permaneceu no meu empregador anterior.
Se achar que o MSBuild é muito restrito, você sempre pode criar tarefas pós-compilação.
Essa 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 criação.
Chame LoadLibrary ou LoadLibraryEx e carregue a DLL correta manualmente. Isso só é possível se você tiver controle antes que a DLL seja carregada automaticamente pelo carregador do SO.
Coloque um lançador no diretório de nível superior. Em seguida, coloque as construções x86 e x64 em diretórios separados:
.\Launcher.exe
.\x64\Game.exe
.\x64\glew32.dll
.\x86\Game.exe
.\x86\glew32.dll
IMHO isso nunca deve ser necessário em um ambiente completamente controlado.