¿Cómo puedo deshacerme de los problemas de "DLL faltante"?

Hice algunos juegos con Visual C ++ 2015 y OpenGL. Cuando lo ejecuté en mi máquina no había ningún problema, pero cuando lo ejecuté en otras máquinas, muestra que faltan algunas DLL. Quiero saber cómo asegurarme de que no sucederá la próxima vez y ¿qué cosas debo tener en cuenta para evitar problemas de archivos perdidos?

Debe instalar los redistribuibles para la versión de Visual Studio que utilizó en cualquier máquina que quiera ejecutar los ejecutables, por ejemplo Debe https://www.microsoft.com/en-us/download/details.aspx?id=48145 para VS2015 . También es posible que necesite redists para DirectX u otros componentes.

Los instaladores de aplicaciones generalmente instalan todos los redistribuibles para cualquiera de sus dependencias. Puede realizar dicho instalador con InnoSetup, NSIS, WIX u otras herramientas.

Es posible hacer ejecutables que no necesitan ningún redistribuible, pero luego está limitado a un subconjunto de la funcionalidad principal de Windows, que generalmente no es suficiente para crear ningún tipo de juego significativo o aplicación grande. Los propios instaladores son un ejemplo de aplicaciones que no necesitan dependencias para ejecutarse.

Uso Dependency Walker para rastrear las DLL que faltan:

Dependency Walker también es muy útil para solucionar errores del sistema relacionados con la carga y ejecución de módulos. Dependency Walker detecta muchos problemas comunes de aplicación, como módulos faltantes, módulos no válidos, desajustes de importación / exportación, errores de dependencia circulares, tipos de módulos de máquinas no coincidentes y fallas de inicialización de módulos.

También hay una opción de tiempo de compilación en VS para vincular estáticamente las DLL:

• La vinculación estática significa que las DLL están incluidas en el archivo EXE.
• La vinculación estática aumenta el tamaño del archivo EXE.
• La vinculación estática significa que esta versión de la DLL siempre se utilizará.
• Sin embargo, la vinculación estática también significa que nunca tendrá un problema con las DLL faltantes.

Para Visual C ++, tiene algunas opciones de cómo manejar la redistribución: ejecute un EXE desde su instalador (con derechos de administrador), use un módulo de combinación MSM con su instalador MSI o incluso DLL lado a lado. Ver MSDN para los detalles.

El mayor problema es OpenGL. La única versión de OpenGL que se incluye con Windows es un procesador de software OpenGL 1.5. Cualquier otra cosa requiere la instalación de un ICD de terceros.

Esta es una de las razones por las que muchos juegos de Windows usan DirectX, ya que está incluido con el sistema operativo. Consulte Implementación de Direct3D 11 para desarrolladores de juegos y Configuración no tan directa .

Descargo de responsabilidad: esta es una solución , no una solución a su respuesta, pero aún así, una posibilidad muy viable.

Si desea estar absolutamente seguro de que no hay dependencias de VS en sí, pero viene con sus propios inconvenientes, en la configuración de generación de código puede elegir ir con Multi Threaded (MT) / Multi Threaded Debug (MD) (para compilaciones de depuración) ) en lugar de MT DLL (MTd) / MT Debug DLL (MDd).

¿Cuáles son los inconvenientes?

• Aumenta tu tamaño ejecutable y tu binario (aunque si estás haciendo un juego esto probablemente sea insignificante)
• compilado de esta manera no se beneficiará de las actualizaciones de dlls en tiempo de ejecución. (p. ej., si Microsoft lanza VC ++ 2015 SP2, SP3, SP4, etc.) Pero eso depende de usted.
• Más uso de RAM (también insignificante) porque no reutiliza el código existente / cargado (DLL)
• Debe asegurarse de que todas las bibliotecas que vincule estén compiladas en el mismo tiempo de ejecución, de lo contrario, la vinculación podría fallar o podrían producirse interesantes errores de tiempo de ejecución (probablemente no, pero me sucedió una vez en la vida en un proyecto heredado que se ha actualizado a el más nuevo VS)

¿Y cuáles son los pros?

• su ejecutable no tendrá dependencias "externas" del propio VS (no se requiere msvc * .dll).
• algunas personas ven esto como un aumento del rendimiento porque está eliminando la sobrecarga de llamadas de DLL, mientras que esto es teóricamente cierto, las mejoras son insignificantes en la práctica

Mira este enlace para obtener una explicación más elaborada y las fallas y caídas que puede encontrar al usar un tiempo de ejecución estático.

Otra solución sería colocar todas las DLL necesarias donde está su binario. Su aplicación no se beneficiará de las actualizaciones (a las bibliotecas de tiempo de ejecución), pero eso es todo.

La solución real es distribuir la aplicación en modo dll de liberación / no depuración (MTd) y proporcionar el instalador redistribuible VC ++ correcto (y cualquier otro instalador de biblioteca que pueda usar, por ejemplo, OpenAL, DirectX9, PhysX), y dejar que el usuario ejecute eso antes de ejecutar su aplicación (como señalaron otras respuestas).

También asegúrese de informar al usuario que posiblemente necesita actualizar sus controladores de GPU (ya que también contienen múltiples tiempos de ejecución para muchas aplicaciones, por ejemplo, OpenGL, Vulcan).

Mi solución fue copiar y pegar la DLL que causó el error en la carpeta donde se encuentra el archivo .sln en Visual Studio. Después de la#include sección, lo escribí #pragma comment (lib, "lost DLL name with .dll")y lo resolví!

Nota: Resolví el problema que encontré con una DLL de biblioteca de terceros (vulkan api). Tal vez no se sabe, pero el 90% funcionará buena suerte :)