Liaison dynamique et statique et déploiement dans Visual Studio 2010

Question

J'ai un projet C++ non géré dans Visual Studio 2010. Il utilise boost, glut et une autre bibliothèque d'un fournisseur.

J'ai mis en place le projet pour créer un exécutable plus "dll-indépendant" possible. Toutes les bibliothèques boost sont liées statiquement et il n'y a pas besoin de DLL dans le répertoire où l'exécutable reste. Même chose pour le Glut, j'ai lié le glut32.lib statique au lieu du glut32.dll et encore aucun problème.

J'ai sélectionné pour les bibliothèques Runtime la version NON-dll, c'est-à-dire la mise au point multithread (pour la configuration de débogage) et la configuration multithread pour la version.

Maintenant, le fournisseur dont je parlais avant, fournit deux alternatives un Vendor.lib et un Vendor.dll. Le Vendor.lib est ajouté dans le Linker-> dépendances supplémentaires mais à l'exécution je dois toujours mettre le Vendor.dll dans le même répertoire de l'exécutable, sinon l'environnement d'exécution se plaint parce qu'il ne trouve pas le Vendor Bibliothèque .dll.

Comment est-ce que je devrais résoudre ce problème? Je voudrais éviter de mettre dans chaque répertoire le fichier .dll.

Je ne veux pas mettre la DLL dans le même répertoire de l'exe et en général quelles sont les directives pour déployer des applications de console C++ non managées dans Visual Studio?

Je sais qu'il y a beaucoup de questions et de pages à propos de cet argument, mais aucun d'entre eux ne m'a éclairci sur ce point.

Une idée?

Answer 1

Microsoft est un peu drôle dans la façon dont il gère cela: lorsque vous créez un .dll, vous créez également un fichier .lib, qui contient les symboles publics dans le .dll. Vous devez lier le .lib afin de charger le fichier .dll au runtime, mais ce .lib n'est toujours pas une bibliothèque statique. Si votre fournisseur fournit une version pour la liaison statique, il n'y aura pas de fichier .dll, ou deux .lib (vraisemblablement dans des répertoires différents ou avec des noms différents). Juste un autre exemple de Microsoft rendant le développement sérieux plus difficile que nécessaire.

Answer 2

La bibliothèque Vendor.lib doit être une bibliothèque statiquement compilée. Si quand vous liez ceci vous avez toujours besoin de Vendor.dll, cela ressemble à Vendor.lib est en fait une bibliothèque d'importation plutôt qu'une bibliothèque statique.

Vérifiez si le fournisseur fournit un autre Vendor.lib (qui devrait être un peu plus grand que votre fichier .lib actuel), qui est une bibliothèque statique et essayez d'établir une liaison avec celui-ci. Si c'est le cas, vous n'aurez pas besoin de la DLL.