LINK: erreur irrécupérable LNK1104: impossible d'ouvrir le fichier 'D:\...\MyProj.exe'
À l'aide de Visual Studio 2010, lorsque je construis + exécute mon application à intervalles rapprochés, l'erreur suivante survient souvent. Si je ne fais qu'attendre une minute ou deux et réessayer, cela fonctionne bien. Unlocker prétend qu'aucun descripteur ne verrouille le fichier exécutable.
Comment puis-je découvrir ce qui le verrouille?
Si c'est Visual Studio lui-même, que dois-je faire pour l'arrêter? ou alternativement pour libérer le fichier?
1>------ Build started: Project: MyProj, Configuration: Release Win32 ------
...
1>InitializeBuildStatus:
1> Creating "Release\MyProj.unsuccessfulbuild" because "AlwaysCreate" was specified.
1>ClCompile:
1> All outputs are up-to-date.
1> SomeFile1.cpp
1>ResourceCompile:
1> All outputs are up-to-date.
1>LINK : fatal error LNK1104: cannot open file 'D:\...\MyProj.exe'
1>
1>Build FAILED.
1>
1>Time Elapsed 00:00:00.94
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
Eu ce problème après une réinstallation aujourd'hui. Assurez-vous que le service Application Experience est démarré et n'est pas désactivé. Si son réglage est manuel, je crois que VS le lancera.
Vous avez probablement eu un processus de construction errant qui bloquait l'exécutable, et le processus n'a pas été nettoyé. Dans ce cas, fermez Visual Studio, ouvrez l'Explorateur de processus et supprimez tous les processus associés à Visual Studio. Ouvrez à nouveau Visual Studio et essayez de reconstruire votre projet.
Je suis conscient que c'est assez vieux, mais j'ai juste eu le même problème avec Visual Studio 2010, tous corrigés, de sorte que d'autres peuvent encore le rencontrer.
L'ajout du chemin de mon projet aux "éléments exclus" dans mes paramètres antivirus AVG semble avoir résolu le problème.
Essayez de désactiver tout bouclier antivirus/résident et voyez si cela résout le problème. Si tel est le cas, ajoutez votre chemin de projet aux répertoires exclus de votre configuration AV.
le fichier peut être verrouillé car il est en cours d'exécution. Essayez de tuer le processus avec un gestionnaire de tâches.
Comme Jonathan l'a dit, oui, renommer peut aider à résoudre ce problème. Mais, par exemple. J'ai été obligé de renommer l'exécutable cible plusieurs fois, c'est fastidieux et pas terrible.
Le problème réside dans le fait que lorsque vous exécutez votre projet et obtenez plus tard un message d'erreur, vous ne pouvez pas le construire - car il est toujours exécutable (votre projet) (vous pouvez le vérifier via le gestionnaire de tâches.) Si vous renommez simplement la construction cible, vous obtiendrez également la même erreur avec un nouveau nom et, si vous ouvrez un gestionnaire de tâches, vous verrez que vous détruisez le système avec vos projets non terminés.
Pour créer une nouvelle version, Visual Studio doit supprimer le fichier exécutable précédent et en créer un nouveau au lieu d'un fichier ancien. Il ne peut pas le faire tant que le fichier exécutable est toujours en cours d'exécution. Donc, si vous voulez faire une nouvelle construction, le processus de l'ancien exécutable doit être fermé! (il est étrange que Visual Studio ne le ferme pas tout seul et oui, cela ressemble à un comportement buggy).
C'est fastidieux de le faire manuellement, vous pouvez donc juste un fichier chauve-souris et cliquez dessus quand vous avez un tel problème:
taskkill /f /im name_of_target_executable.exe
cela fonctionne pour moi au moins… .. Comme une supposition: je ne ferme pas correctement mon programme en C++, il est donc peut-être normal que Visual Studio le maintienne en cours d'exécution.
ADDITION: Il y a une grande chance de l'être, à cause d'une application non finie. Vérifiez si vous avez appelé PostQuitMessage à la fin, afin de faire savoir à Windows que vous avez terminé.
Vous avez peut-être pas fermé la sortie. Fermez la sortie, nettoyez et reconstruisez le fichier. Vous pourrez peut-être exécuter le fichier maintenant.
J'ai conclu qu'il s'agissait d'une sorte de bogue de Visual Studio. C Johnson a peut-être raison - le processus de construction garde peut-être le fichier verrouillé.
J'ai une solution de contournement qui fonctionne - chaque fois que cela se produit - je modifie le nom de cible de l'exécutable dans les propriétés du projet (cliquez avec le bouton droit sur le projet, puis sur Propriétés\Propriétés de configuration\Général\Nom de la cible).
De cette manière, VS crée un nouvel exécutable et le problème est résolu. Toutes les quelques fois que je fais cela, je retourne au nom d'origine, parcourant ainsi environ 3 noms.
Si quelqu'un trouve la raison de cela et une solution, répondez-moi et je pourrai la déplacer vers la vôtre, car la mienne est une solution de contournement.
J'ai eu le même problème, cependant en utilisant Codeblocks. A cause de ce problème, j'ai quitté la programmation parce que chaque fois je voulais juste jeter mon ordinateur par la fenêtre.
Je tiens à remercier user963228 pour sa réponse est vraiment une solution à cela. Vous devez activer Application Experience au démarrage manuel (vous pouvez le faire en recherchant des services dans le menu Démarrer de Windows 7, puis en recherchant Application Experience et en cliquant sur les propriétés).
Ce problème survient lorsque les utilisateurs souhaitent modifier leur machine Windows 7 et décident de désactiver certains services inutiles. Ils recherchent donc un guide d'optimisation et la plupart de ces guides indiquent que la fonctionnalité Application Experience peut être désactivée sans danger.
Je pense que ce problème devrait être lié à Windows 7 problème pas VS problème et il devrait être plus visible - il m'a fallu beaucoup de temps pour trouver cette solution.
Merci encore!
Je viens de rencontrer le même problème avec VS2013, la création de pilotes de périphérique en C++, et rien de ce qui précède ne semblait résoudre le problème. Cependant, je viens de découvrir que, dans mon cas, le problème semble avoir été lié à VMWare.
J'exécutais un client de poste de travail VMWare avec un dossier partagé défini sur le VM sur l'intégralité de mon lecteur C:. Lorsque j'ai désactivé les dossiers partagés dans les paramètres VM, VS2013 a été en mesure de créer avec joie mes fichiers .exe.
Mon nouveau processus est:
1) Désactivez le dossier partagé sur la machine virtuelle (Paramètres de la VM | Options | Dossiers partagés - et décochez la case) 2) Exécutez la construction sur le PC hôte 3) Réactivez le dossier partagé (et continuez à partir de Là)
J'espère que cela pourrait aider quelqu'un d'autre.
(En passant, les erreurs que vous recevez sont dues au fait que le fichier .exe (ou d’autres fichiers) est verrouillé ou nécessite l’autorisation de l’administrateur, mais il s’agit là d’un fouillis rouge.
Juste pour ajouter une autre solution à la liste, ce que j'ai trouvé, c'est que Visual Studio (2012 dans mon cas) verrouille parfois des fichiers sous différents processus.
Donc, lors d’un plantage, devenv.exe est peut-être toujours en cours d’exécution et conserve le fichier. Alternativement (comme je viens de le découvrir), vstestrunner ou vstestdiscovery pourrait également conserver le fichier.
Tuez tous ces processus et cela pourrait résoudre le problème.
Le mien est que si vous définissez l'option de fichier de liste MASM avec une sélection supplémentaire, cela vous donnera cette erreur.
Juste utiliser
Enable Assembler Generated Code Listing Yes/Sg
Assembled Code Listing $(ProjectName).lst
c'est bon.
Mais tout extra vous avez un problème.
Utilisation de Bjarne Stroustrup Principes et pratique de la programmation Utilisation de l'exemple "FLTK" de C++ J'ai la même erreur, mais après une heure, j'ai eu une idée. , dans mon cas, j’ai suivi le fichier kernel32.lib pour voir où se trouvait et ai vu qu’il y avait beaucoup de fichiers kernel32.lib dans différents dossiers. J'ai donc commencé à copier les bibliothèques FLTK dans ces dossiers et le dernier que j'ai essayé a fonctionné. Visual Studio 2013 Express a trouvé le fichier fltkd.lib et le code a fonctionné.
Dans mon cas, le chemin correct était C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x86
Je ne sais pas comment définir cette route dans Visual Studio.
Je ne sais pas si ce dossier de kits Windows a été créé lors de l’installation du SDK Microsoft Windows pour Windows 7 et de .NET Framework 4 (ISO) http://www.Microsoft.com/en-us/download/details.aspx?id= 8442
J'espère que cela vous aide les gens.
L'erreur provient (du moins parfois) de chemins trop longs. Dans mon projet, il suffit de réduire le chemin du fichier de sortie pour effectuer le travail suivant: "Propriétés/Propriétés de configuration/Général/Répertoire intermédiaire"
On dirait que j'ai atteint la limite du chemin de 250 caractères.
Je viens d'avoir le même problème. Avec moi, l'exécutant fonctionnait toujours, mais je ne pouvais pas le terminer avec le gestionnaire de tâches. Juste en redémarrant VS, cela a fonctionné pour moi.