Pourquoi l'erreur fatale «LNK1104: impossible d'ouvrir le fichier« C: \ Program.obj »» se produit-elle lorsque je compile un projet C ++ dans Visual Studio?

J'ai créé un nouveau projet C ++ dans Visual Studio 2008. Aucun code n'a encore été écrit; Seuls les paramètres du projet ont été modifiés.

Lorsque je compile le projet, je reçois l'erreur fatale suivante:

erreur fatale LNK1104: impossible d'ouvrir le fichier 'C: \ Program.obj'

Ce problème particulier est causé par la spécification d'une dépendance à un fichier lib contenant des espaces dans son chemin. Le chemin doit être entouré de guillemets pour que le projet se compile correctement.

Dans l' onglet Propriétés de configuration -> Éditeur de liens -> Entrée des propriétés du projet, il existe une propriété Dépendances supplémentaires . Ce problème a été résolu en modifiant cette propriété de:

C: \ Program Files \ sofware sdk \ lib \ library.lib

À:

"C: \ Program Files \ sofware sdk \ lib \ library.lib"

Où j'ai ajouté les citations.

Cela peut se produire si le fichier est toujours en cours d'exécution.

: -1: erreur: LNK1104: impossible d'ouvrir le fichier 'debug \ ****. Exe'

Le problème a disparu pour moi après la fermeture et la réouverture de Visual Studio. Je ne sais pas pourquoi le problème est survenu, mais cela vaut peut-être la peine d'être essayé.

C'était sur VS 2013 Ultimate, Windows 8.1.

Vérifiez également que vous ne l'avez pas activé: Propriétés de configuration -> C / C ++ -> Préprocesseur -> Prétraitement vers un fichier .

J'ai eu le même problème. Il était causé par un "," dans le nom d'un dossier de chemin de bibliothèque supplémentaire. Il a été résolu en changeant le chemin de bibliothèque supplémentaire.

Mon problème était une .libextension manquante , je faisais juste un lien mylibet VS a décidé de chercher mylib.obj.

Dans mon cas, il s'agissait d'une référence mal orientée. Project faisait référence à la sortie d'un autre projet, mais ce dernier n'a pas produit le fichier où le premier cherchait.

Solution 1 (pour mon cas): redémarrez le processus Windows Explorer (oui, le gestionnaire de fichiers Windows).

Solution 2:

1. Fermez Visual Studio. Déconnexion Windows
2. Connectez-vous, rouvrez Visual Studio
3. Construisez comme d'habitude. Il se construit maintenant et peut accéder au fichier problématique.

Je suppose que parfois le système de fichiers ou quiconque le contrôle se perd avec ses autorisations. Avant de redémarrer la session Windows, essayé de tuer les msbuild32.exeprocessus zombie , redémarrez Visual Studio, ne cochez aucune même en affichant le fichier problématique. Aucun problème de configuration de construction. Cela arrive de temps en temps. Une chose interne dans Windows ne résout pas, nécessite un redémarrage.

J'ai eu la même erreur, juste avec un package Nuget que j'avais installé (un qui n'est pas seulement un en-tête), puis j'ai essayé de désinstaller.
Ce qui n'allait pas pour moi, c'est que j'incluais toujours un en-tête pour le package que je viens de désinstaller dans l'un de mes fichiers .cpp (assez idiot, oui).
J'ai même supprimé le lien vers les répertoires de bibliothèques supplémentaires Project -> Properties -> Linker -> General, mais bien sûr en vain, car j'essayais toujours de référencer l'en-tête inexistant.

Certainement un message d'erreur déroutant dans ce cas, car le nom de l'en-tête était <boost/filesystem.hpp>mais l'erreur m'a donné "cannot open file 'llibboost_filesystem-vc140-mt-gd-1_59.lib'"et aucun numéro de ligne ou quoi que ce soit.

J'ai eu le même problème, mais la solution pour mon cas n'est pas répertoriée dans les réponses. Mon programme antivirus (AVG) a déterminé que le fichier MyProg.exeétait un virus et l'a mis dans le «magasin de virus». Vous devez vérifier cet entrepôt et si le fichier est là - alors restaurez-le simplement. Cela m'a aidé.

Pour un projet d'assemblage (ProjectName -> Build Dependencies -> Build Customizations -> masm (selected)), la définition de Generate Preprocessed Source Listing sur True a également causé le problème pour moi, effaçant le paramètre l'a corrigé. VS2013 ici.

Je rencontre le même problème avec l'éditeur de liens se plaignant de l'exécutable principal manquant. Cela s'est produit lors de notre port de solution vers le nouveau Visual Studio 2013 . La solution est un mélange varié de projets / codes gérés et non gérés. Le problème (et le correctif) a fini par être un fichier app.config manquant dans le dossier de la solution. Il a fallu une journée pour comprendre celui-ci :(, car le journal de sortie n'était pas très utile.

J'ai vérifié tous mes paramètres selon cette liste: http://msdn.microsoft.com/en-us/library/ts7eyw4s.aspx#feedback . Cela m'est utile et pour ma situation, je découvre que la dépendance de lien des propriétés des projets a des guillemets doubles, qui ne devraient pas être là.

Je réponds parce que je ne vois cette solution particulière répertoriée par personne d'autre.

Apparemment, mon antivirus (Ad-Aware) signalait une DLL dont dépend un de mes projets et la supprimait. Même après avoir exclu le répertoire où réside la DLL, le même comportement a continué jusqu'à ce que je redémarre mon ordinateur.

Dans mon cas, j'avais remplacé les fichiers de bibliothèque mathématique d'un précédent cours Game Engine Graphics par GLM. Le problème était que je ne les ai pas ajoutés au projet dans l'Explorateur de solutions de Visual Studio (même s'ils étaient dans le référentiel du projet).

J'ai eu ce problème en conjonction avec l'erreur LNK2038, j'ai suivi ce post pour séparer les DLL RELEASE et DEBUG. Dans ce processus, j'avais nettoyé tout le dossier où résidaient ces dépendances.

Heureusement, j'avais une sauvegarde de tous ces fichiers et j'ai récupéré le fichier pour lequel cette erreur était renvoyée dans le dossier DEBUG pour résoudre le problème. Le code d'erreur était trompeur d'une certaine manière, car j'ai dû passer beaucoup de temps pour revenir à cette astuce à partir de l'une des réponses de ce message.

J'espère que cette réponse aide quelqu'un dans le besoin.

Je l'ai résolu en ajoutant un projet existant à ma solution , que j'ai oublié d'ajouter dans un premier temps.

J'ai eu la même erreur:

fatal error LNK1104: cannot open file 'GTest.lib;'

Cela a été causé par ;la fin. Si vous avez plusieurs bibliothèques, elles doivent être séparées par un espace vide (barre d'espace), pas de virgule ni de point-virgule!

Alors n'utilisez pas ;ou quoi que ce soit d'autre lors de la liste des bibliothèquesProject properties >> Configuration Properties >> Linker >> Input

J'ai essayé la solution ci-dessus mais n'a pas fonctionné pour moi. Donc, je renomme l'exe et reconstruit la solution. Ça marche pour moi.

J'ai eu cette erreur exacte lors de la création d'une DLL VC ++ dans Visual Studio 2019:

LNK1104: impossible d'ouvrir le fichier 'C: \ Program.obj'

Il s'est avéré que sous Propriétés du projet> Éditeur de liens> Entrée> Fichier de définition de module, j'avais spécifié un fichier def qui avait un guillemet double sans correspondance à la fin du nom de fichier. La suppression du guillemet double sans correspondance a résolu le problème.

Tué msbuild32.exeet reconstruit. Cela a fonctionné pour moi.

J'ai rencontré le même problème avec «Visual Studio 2013».

LNK1104: cannot open file 'debug\****.exe

Il s'est résolu après la fermeture et le redémarrage de Visual Studio.

J'avais le même problème, je viens de copier le code dans un nouveau projet et j'ai commencé la construction. Une autre erreur a commencé à arriver. erreur C4996: «fopen»: cette fonction ou variable peut être dangereuse. Pensez à utiliser fopen_s à la place

Pour résoudre à nouveau ce problème, j'ai ajouté ma propriété dans le projet Project comme ci-dessous. Projet -> Propriétés -> Propriété de configuration -> c / c ++. Dans cette catégorie, il y a le nom du champ Définitions du préprocesseur J'ai ajouté _CRT_SECURE_NO_WARNINGS ceci pour résoudre le problème J'espère que cela aidera ...

Merci