☰

Sistema de construcción

tag-icon • tag-icon visual-studio dll libraries c++ cpu-architecture
Sistema de construcción

Actualmente estoy creando una aplicación OpenGL en Visual Studio 2015 y he vinculado e incluido con éxito todas mis cosas para GLFW, GLEW, etc.

Sin embargo, cuando ejecuto mi aplicación, necesito incluirla glew32.dll, no hay ningún problema. Simplemente voy, tomo el dll x64 y lo agrego a la carpeta del proyecto. Sin embargo, ahora, cuando ejecuto mi programa en modo de 32 bits, se rompe y viceversa si usara la DLL de 32 bits en un programa de 64 bits. La única solución económica para esto es incluir las DLL específicas de la arquitectura en las carpetas de compilación.

¿Hay alguna manera de incluir los archivos DLL según una arquitectura específica, porque quiero alojar mi programa resultante en una forma como:

Directorio de programas

  • juego.exe
  • juego_x64.exe
  • x64 (carpeta)
    • glew32.dll
  • x32 (carpeta)
    • glew32.dll

Si algo como esto no es posible, estoy más que feliz de tener un glew32.dllarchivo glew32_x64.dllalmacenado en una carpeta, pero eso probablemente nunca sucederá debido a que la biblioteca no busca el nuevo dll...

Respuesta1

El artículo sobreOrden de búsqueda de biblioteca de vínculos dinámicosDe hecho, también tiene algo sobre cómo cambiar la forma en que una aplicación busca una DLL. Es decir, está haciendo referenciaSetDllDirectoryyLoadLibraryExe incluso algunos más.

Respuesta2

Hay varias formas de resolver el problema.

Sistema de construcción

MSBuild tiene muchas características que no se pueden controlar desde la GUI de Visual Studio. Puede utilizar variables en casi todas partes y, a veces, también condiciones.

Puedes declarar bloques condicionales en tu .vcxprojarchivo (que es solo XML),como esto:

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

Hay otras soluciones, comoÉste:

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

No resuelve directamente su problema, pero brinda información adicional sobre las capacidades de MSBuild.

Una vez tuve una solución funcional para un problema muy similar (haciendo referencia a bibliotecas nativas de .NET con compilaciones de depuración/lanzamiento), pero permaneció en mi empleador anterior.

Si cree que MSBuild está demasiado restringido, siempre puede crear tareas posteriores a la compilación.

Esta solución también puede ser parte de la solución de directorio independiente de arquitectura dual que se menciona a continuación porque ayuda a automatizar mejor el proceso de compilación.

Precarga de DLL

Llame a LoadLibraryo LoadLibraryExy cargue la DLL correcta manualmente. Esto solo es posible si tiene control antes de que el cargador del sistema operativo cargue automáticamente la DLL.

Directorios separados

Coloque un iniciador en el directorio de nivel superior. Luego, coloque las compilaciones x86 y x64 en directorios separados:

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

Ruta de búsqueda

En mi humilde opinión, esto nunca debería ser necesario en un entorno completamente controlado.

información relacionada