Visual C++/Atelier: configuration de l'Application incorrecte?

Mon C (++), un programme écrit et compilé avec Visual C(++)/Visual Studio, fonctionne très bien sur ma machine, mais refuse de s'exécuter sur une autre machine. Le message d'erreur que j'obtiens est "Cette application n'a pas pu démarrer car la configuration de l'application est incorrecte. La réinstallation de cette application peut corriger ce problème."

Cela semble être une double question: stackoverflow.com/questions/87405/...
Concernant les réponses ici: les avantages et les inconvénients entre statique et dynamique de la liaison: stackoverflow.com/questions/1993390/static-linking-vs-dynamic-linking

OriginalL'auteur Thomas | 2008-09-19

  1. 5

    Si vous écrivez un programme C++, il lie de manière dynamique à la Bibliothèque Runtime C, ou CRT pour faire court. Cette bibliothèque contient votre printf, votre malloc, votre strtok, etcetera. La bibliothèque est contenue dans le fichier appelé MSVCR80.DLL. Ce fichier n'est pas installé par défaut sur un système Windows, donc, l'application ne peut pas s'exécuter.

    La solution? Soit installer la DLL sur l'ordinateur cible à travers VCREDIST.EXE (Visual C++ Redistributable Package), ou un lien vers le CRT de manière statique (plug le code pour les fonctions utilisées directement dans votre EXE).

    Distribution et l'installation de VCREDIST avec une application simple est une douleur dans le cul, j'ai donc opté pour la deuxième option: liaison statique. C'est vraiment simple: rendez-vous à propriétés de votre projet, déplier C/C++, cliquez sur la Génération de Code, et de l'ensemble de la Bibliothèque d'Exécution à l'un des non-DLL options. C'est tout là est à lui.

    Bonne réponse, je veux juste ajouter que la liaison statique peut augmenter considérablement la taille de votre application.
    aussi - si l'on utilise les MFC, doivent également définir la propriété. Voir mon post ci-dessous pour l'emplacement.

    OriginalL'auteur Thomas

  2. 5

    Le problème ici est une DLL manquante de la dépendance, comme le CRT (C Runtime Library). Un bon outil pour diagnostiquer ce genre de problème est Dependency Walker (depends.exe), que vous pouvez retrouver ici:

    http://www.dependencywalker.com/

    Vous exécutez ce programme sur l'ordinateur qui génère le message d'erreur que vous avez posté, et l'utiliser pour ouvrir le fichier exe qui est à l'origine de cette erreur. Dependency Walker va vite et graphiques indiquent toutes les Dll sont nécessaires, mais pas disponible sur la machine.

    À l'aide de depends.exe n'aide pas si il y a manifeste problème lié et c'est la cause n ° 1 pour l'erreur spécifiée.
    Astuce: exécuter dependency walker, puis "Enregistrer sous..." dans un fichier texte. Ce faire sur les deux machines, puis de comparer les fichiers. Dans mon cas, cela m'a montré que le side-by-side de configuration est erronée, et que le Visual C++ transmissibles n'ont pas été trouvés correctement. À son tour, cela semble avoir été causés par l'utilisation d'un vcredist_x86.exe téléchargé à partir de Microsoft, pas livré avec ma propre installation.

    OriginalL'auteur Charlie

  3. 1

    Les Chances sont élevées que vous manquez le runtime des bibliothèques Visual Studio (CRT, entre autres), vous pouvez vous débarrasser de ces dépendances (lien statique) ou installer le VC redist paquets sur l'ordinateur cible.

    En fonction de la version de Visual C++, vous pouvez utiliser, vous devez installer les différents paquets :

    Visual C++ 2005

    Visual C++ 2005 SP1

    Visual C++ 2008

    Avertissement : ces paquets contiennent uniquement les versions des bibliothèques, si vous voulez être en mesure de distribuer des versions de débogage de votre application, vous aurez à prendre soin de la DLL requis vous-même.

    OriginalL'auteur Drealmer

  4. 1

    C'est beaucoup le plus simple lien vers le moteur d'exécution de manière statique.

    c++ -> Génération de Code -> Bibliothèque d'Exécution et sélectionnez l'option "multi-thread /MT"

    Toutefois, cela ne veut faire votre exécutable quelques centaines de Ko de plus. Ce pourrait être un problème si vous installez un grand nombre de petits programmes, étant donné que chacun d'eux devra être accablé par sa propre copie de l'exécution. La réponse est pour créer un programme d'installation.

    Nouveau projet -> "le programme d'installation et de déploiement" -> "configuration de projet"

    Charge de la sortie de vos projets d'application ( défini à l'aide de la DLL de la version du moteur d'exécution ) dans le programme d'installation du projet et de le construire. La dépendance sur le runtime DLL sera remarqué, inclus dans le package du programme d'installation, et proprement et discrètement installé au bon endroit sur la machine cible.

    OriginalL'auteur ravenspoint

  5. 1

    La bonne VC Redist paquet pour vous est une partie de votre installation de Visual Studio. Pour VC 8, vous pouvez le trouver ici:

    \Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\vcredist_x86
    Ce problème m'ont rendu fou. Il était facile de trouver des versions de vcredist_x86.exe pour télécharger à partir de Microsoft, mais pas celle de mon VS d'installation. Ceux-ci n'ont pas de résoudre le problème. Ni celle d'un montant de copie manuelle de la personne Dll et se manifeste à partir de la VS de l'installation. Enfin, en identifiant où vcredist_x86.exe était situé dans mon VS d'installation, et en cours d'exécution que sur ma machine cible, tout a fonctionné.

    OriginalL'auteur Scott

  6. 1

    SOLUTION POSSIBLE........

    EDIT: (supprimé la plupart de mon post)
    Longue histoire courte, j'ai eu des problèmes similaires, l'obtention de la "Configuration de l'Application Incorrecte" des messages, etc etc.
    Depends.exe a été seulement de trouver de ieshims.dll et wer.dll que possible des questions, mais ce n'est pas le problème.
    J'ai fini par utiliser le Multithread (/mt) option de compilation.
    Ce qui A fonctionné bien, comme une solution viable, c'est de faire un programme d'installation InstallShield.
    J'ai sélectionné plusieurs modules de fusion dans installshield builder, et il semble avoir corrigé mon problème. Les modules retenus étaient:
    VC++ 9.0 CRT, VC++ 9.0 DEBUG CRT et le CRT WinSXS MSM module de fusion.
    Je suis assez sûr que c'est la WinSXS module de fusion qui a fixé.

    DEBUG CRT: j'ai remarqué que quelque part (n'importe comment dur j'ai essayé, et de toute évidence échoué jusqu'à présent), ma version dépendait toujours de la DEBUG CRT. Si c'est toujours le cas, l'Installation du module de fusion a maintenant placé le DÉBOGAGE CRT dossier dans mon dossier WinSXS 🙂 etant un peu novice dans ce domaine avec VC++ je suppose que ce serait normalement utilisé pour distribuer les versions de débogage de vos programmes à d'autres personnes. Pour tester si c'est qu'est-ce résolu mon problème, j'ai enlevé le DÉBOGAGE CRT dossier de le dossier WinSXS et la demande toujours travaillé. (À moins que quelque chose est toujours en cours d'exécution en arrière-plan, etc etc - je ne suis pas en elle)

    De toute façon, cela a eu des choses de travail pour moi sur un XP SP3 entièrement mise à jour de la machine, et également sur un VMWare XP SP3 machine avec l'os à nu (.net 3.5 et VC++ 2008 RTM) - et aussi sur un compagnon de la machine XP où il a précédemment ne fonctionnait pas.

    Afin de donner à ces choses à essayer, vous pourriez avoir de la chance.

    Cela devrait être une question, pas une réponse. De toute façon... Si vous utilisez /CLR:pure, vous écrivez une application gérée. Votre problème est probablement très différent de celui-ci.

    OriginalL'auteur mad_dog

  7. 1

    Première chose que vous devez utiliser

    #define _BIND_TO_CURRENT_VCLIBS_VERSION 1

    ou ajouter _BIND_TO_CURRENT_VCLIBS_VERSION=1 pour les directives de préprocesseur.

    Le problème est lié à la liaison et le manifeste types, vous pouvez trouver plus de http://www.nuonsoft.com/blog/2008/10/29/binding-to-the-most-recent-visual-studio-libraries/

    En faisant cela, votre application sera exécutée avec la plus large gamme de bibliothèques d'exécution des versions.

    OriginalL'auteur sorin

  8. 0

    Souvent cette erreur est le résultat de la tentative d'exécution de la version de débogage d'une application qui utilise .NET. Depuis l' .NET redistributable package n'inclut pas les versions de débogage de la dll qui est installé avec Visual Studio, votre demande sera souvent cette erreur lors de l'exécution sur une autre machine qui n'a pas de Visual Studio est installé. Si vous ne l'avez pas déjà, essayez de créer une version de votre application et voir si cela fonctionne.

    OriginalL'auteur BeachRunnerFred

  9. 0

    Notez aussi que si vous changer de la statique de l'exécution, vous devrez faire de même pour MFC si votre application utilise les MFC. Ces paramètres sont les propriétés->Configuration/Général

    OriginalL'auteur Tim

  10. 0

    J'ai rencontré ce problème et a réussi à résoudre ce problème très simplement.

    Visual studio vous donne l'option (activée par défaut) pour construire un manifeste pour chaque build.

    Le manifeste a été mis dans le dossier de lancement, mais c'était une version différente du dossier que l'exe.

    Même en utilisant les utilitaires de configuration, il n'était pas emballé.

    Vous devriez regarder pour un fichier de noms de quelque chose comme myprogram.exe.indermediate.manifeste

    Si c'est dans le même dossier que l'exe (et vous avez toutes les dll), il devrait fonctionner

    OriginalL'auteur Jeff