Comment puis-je me débarrasser des problèmes de «DLL manquante»?


15

J'ai fait quelques jeux avec Visual C ++ 2015 et OpenGL. Lorsque je l'ai exécuté sur ma machine, il n'y a eu aucun problème, mais lorsque je l'ai exécuté sur d'autres machines, cela montre que certaines DLL sont manquantes. Je veux savoir comment m'assurer que cela ne se produira pas la prochaine fois et que dois-je prendre en compte pour éviter les problèmes de fichiers manquants?


8
Tout d'abord, assurez-vous de créer une version Release.
user253751

3
Si vous voulez être absolument sûr qu'il n'y a pas de dépendances de VS lui-même - mais il a ses propres inconvénients - dans les paramètres de génération de code, vous pouvez choisir d'aller avec le débogage multi-thread / multi-thread (pour les versions de débogage) au lieu de MT DLL / DLL de débogage MT . Cela augmente votre taille exécutable et votre binaire compilé de cette manière ne bénéficiera pas des mises à jour des DLL d'exécution. Mais ça dépend de vous. Le côté positif est que votre exécutable n'aura pas de dépendances "externes". Je ne posterai pas cela comme une réponse car ce n'est pas une solution à votre problème, juste une solution de contournement.
Gizmo

@Gizmo une solution de contournement est toujours une réponse et les commentaires sont temporaires et utilisés pour clarifier les messages auxquels ils se trouvent, et peuvent être supprimés. Donc, si c'est utile, vous devez le poster comme réponse.
user1306322

Hm bien. Je le posterai alors comme réponse.
Gizmo

Réponses:


22

Vous devez installer les redistribuables pour la version de Visual Studio que vous avez utilisée sur toute machine qui souhaite exécuter les exécutables, par exemple https://www.microsoft.com/en-us/download/details.aspx?id=48145 pour VS2015 . Vous pouvez également avoir besoin de redistributions pour DirectX ou d'autres composants.

Les installateurs d'applications installent généralement tous les redistribuables pour n'importe laquelle de leurs dépendances. Vous pouvez créer un tel programme d'installation avec InnoSetup, NSIS, WIX ou divers autres outils.

Il est possible de créer des exécutables qui n'ont pas besoin de redistributions, mais vous êtes alors limité à un sous-ensemble des fonctionnalités de base de Windows, ce qui n'est généralement pas suffisant pour créer un jeu significatif ou une grande application. Les programmes d'installation eux-mêmes sont un exemple d'applications qui ne nécessitent aucune dépendance pour s'exécuter.


Est-il possible d'utiliser VS pour construire un tel programme d'installation? Je pensais avoir déjà vu quelque chose appelé OneClick dans les paramètres du projet.
user1306322

@ user1306322: absolument, une solution a été mentionnée dans les commentaires de la question par Gizmo. Il s'agit simplement de savoir quels runtimes / DLL vous liez. Les paramètres par défaut vous permettent d'établir une liaison avec la DLL CRT spécifique à la version, mais cela peut être modifié en supprimant les options de l'éditeur de liens. Liez simplement contre MSVCRT.DLL(inclus avec Windows lui-même) au lieu de MSVCPxxx.DLL(versions spécifiques à la version incluses dans les versions de Visual Studio).
Sean Middleditch

Ou si vous voulez créer un programme d'installation complet, c'est essentiellement ce que WIX est. Il s'agit d'un crapfest Microsoft trop complexe et trop complexe, mais cela fonctionne. Il y avait aussi des «projets d'installation», mais je pense que ceux-ci ont disparu depuis 2013 ou 2015.
Sean Middleditch

7

J'utilise Dependency Walker pour retrouver les DLL manquantes:

Dependency Walker est également très utile pour résoudre les erreurs système liées au chargement et à l'exécution des modules. Dependency Walker détecte de nombreux problèmes d'application courants tels que les modules manquants, les modules invalides, les incompatibilités d'importation / exportation, les erreurs de dépendance circulaire, les types de modules de machine incompatibles et les échecs d'initialisation des modules.


Il existe également une option de compilation dans VS pour lier statiquement les DLL:

  • La liaison statique signifie que les DLL sont incluses dans le fichier EXE.
  • La liaison statique augmente la taille du fichier EXE.
  • La liaison statique signifie que cette version de la DLL sera toujours utilisée.
  • Cependant, la liaison statique signifie également que vous n'aurez jamais de problème avec les DLL manquantes.

1
Le marcheur de dépendance est assez vieux. Il n'émule plus correctement les mécanismes de Windows pour charger les DLL. Menant souvent à de faux messages sur l'impossibilité de trouver des DLL.
jpmc26

Et la liaison statique peut être interdite dans la licence d'une dépendance.
KeyWeeUsr

6

Pour Visual C ++, vous avez plusieurs choix sur la façon de gérer la redistribution: exécutez un EXE à partir de votre programme d'installation (avec les droits d'administrateur), utilisez un module de fusion MSM avec votre programme d'installation MSI, ou même des DLL côte à côte. Voir MSDN pour les détails.

Le plus gros problème est OpenGL. La seule version d'OpenGL incluse avec Windows est un moteur de rendu OpenGL 1.5. Tout autre élément nécessite l'installation d'un ICD tiers.

C'est l'une des raisons pour lesquelles tant de jeux Windows utilisent plutôt DirectX car il est inclus avec le système d'exploitation. Voir Déploiement de Direct3D 11 pour les développeurs de jeux et Configuration pas si directe .


1
Le conseil OpenGL est obsolète - chaque pilote graphique moderne est livré avec un ICD OpenGL à jour.
user253751

J'ai personnellement dû installer des DLL openGL sur des machines aussi
jeunes

@Gnemlock Immédiatement après la réinstallation de Windows sur ledit ordinateur âgé d'un an, vous avez peut-être raison. Avez-vous continué à voir ce problème après avoir installé le package de pilote officiel de NVIDIA, AMD ou Intel?
Damian Yerrick

2
@Gnemlock - si vous installez manuellement des DLL OpenGL, vous faites quelque chose d'horriblement mal. Si vous voulez vraiment dire «installez le pilote de votre fournisseur de GPU», c'est exactement ce que Immibis vient de dire aussi.
Maximus Minimus

@Gnemlock - ah, donc pas pertinent pour le monde réel alors. Merci d'avoir clarifié cela.
Maximus Minimus

1

Avertissement: Ceci est une solution de contournement , pas une solution à votre réponse, mais toujours, une possibilité très viable.

Si vous voulez être absolument sûr qu'il n'y a pas de dépendances de VS lui-même - mais il a ses propres inconvénients - dans les paramètres de génération de code, vous pouvez choisir d'aller avec Multi Threaded (MT) / Multi Threaded Debug (MD) (pour les versions de débogage ) au lieu de MT DLL (MTd) / MT Debug DLL (MDd).

entrez la description de l'image ici

Quels sont les inconvénients?

  • Cela augmente votre taille exécutable et votre binaire (bien que si vous faites un jeu, cela est probablement négligeable)
  • compilé de cette façon ne bénéficiera pas des mises à jour des DLL d'exécution. (par exemple, si Microsoft publie VC ++ 2015 SP2, SP3, SP4, etc.) Mais cela dépend de vous.
  • Utilisation accrue de la RAM (également négligeable) car vous ne réutilisez pas le code existant / chargé (DLL)
  • Vous devez vous assurer que toutes les bibliothèques que vous liez sont compilées avec le même runtime, sinon la liaison pourrait échouer, ou des erreurs d'exécution intéressantes pourraient se produire (probablement pas, mais cela m'est arrivé une fois dans une vie dans un projet hérité qui a été mis à jour vers le plus récent VS)

Et quels sont les avantages?

  • votre exécutable n'aura pas de dépendances "externes" de VS lui-même (pas d'exigence msvc * .dll).
  • certaines personnes voient cela comme une augmentation des performances car vous éliminez la surcharge des appels DLL, alors que cela est théoriquement vrai, les améliorations sont négligeables dans la pratique

Consultez ce lien pour une explication plus élaborée et pour les pièges et les chutes que vous pourriez rencontrer avec l'utilisation d'un runtime statique.

Une autre solution consiste à placer toutes les DLL requises à l'emplacement de votre fichier binaire. Votre application ne bénéficiera pas de mises à jour (des bibliothèques d'exécution) mais c'est tout.

La vraie solution consiste à distribuer l'application en mode dll de libération / non débogage (MTd) et à fournir le programme d'installation redistribuable VC ++ correct (et tout autre programme d'installation de bibliothèque que vous pourriez utiliser, par exemple OpenAL, DirectX9, PhysX) et à laisser l'utilisateur exécuter avant d'exécuter votre application (comme d'autres réponses l'ont souligné).

Assurez-vous également de faire savoir à l'utilisateur qu'il doit éventuellement mettre à jour ses pilotes GPU (car ceux-ci contiennent également plusieurs temps d'exécution pour de nombreuses applications, par exemple OpenGL, Vulcan).


0

Ma solution était de copier et coller la DLL qui a provoqué l'erreur dans le dossier où se trouve le fichier .sln dans Visual Studio. Après la #includesection, je l'ai écrite #pragma comment (lib, "lost DLL name with .dll")et résolue!

Remarque: j'ai résolu le problème que j'ai rencontré avec une DLL de bibliothèque tierce (vulkan api). Peut-être que ce n'est pas connu mais 90% fonctionneront bonne chance :)

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.