Copie de commande terminée avec le code 4 lors de la construction - le redémarrage de Visual Studio le résout

De temps en temps, lorsque je construis ma solution ici (avec 7 projets), j'obtiens l'erreur redoutée 'Copie de commande sortie avec code 4', dans Visual Studio 2010 Premium ed.

Cela est dû au fait que l'événement post-build ne peut pas passer.

Voici ce qui résout le problème, temporairement

• Parfois: un redémarrage de Visual Studio et je suis en mesure de créer la solution
• Parfois: un redémarrage de Visual Studio et du gestionnaire de fichiers de mon choix (Q-Dir 4.37) le résout.

Voici à quoi ressemble l'événement post-build:

xcopy "$(SolutionDir)Solution Items\References\*.dll" "$(TargetDir)" /Y

Lorsque vous obtenez la commande copy terminée avec une erreur de code [insérer une valeur], c'est normalement à cause de ce qui suit:

• autorisations de lecture / écriture
• fichiers manquants
• mauvais répertoires

Cependant - évidemment, lorsque je construis la solution, il n'y a pas de problème.

Pour info, j'ai désinstallé ReSharper 5.1.1 il y a deux semaines et Visual Studio m'a donné des erreurs depuis lors (parmi lesquelles ne pas pouvoir déboguer). J'ai réinstallé Visual Studio et cela fonctionne mieux depuis, mais j'ai toujours ce problème. Cela pourrait-il avoir à voir avec des trucs ReSharper quelque part?

Avez-vous eu le même problème et l'avez-vous résolu? Ou avez-vous une solution possible?

J'ai invariablement trouvé qu'il s'agissait d'un problème de verrouillage de fichier. Le code 4 est impossible d'accéder au fichier. Une solution partielle que j'ai trouvée est d'utiliser l'option / C pour xcopy (qui continue en cas d'erreur). Ce n'est pas vraiment une solution, mais cela a surtout empêché mes builds d'échouer.

Une autre solution qui ne fonctionne que sur 32 bits est d'utiliser le Unlocker outil pour libérer les poignées de fenêtres sur le fichier avant la copie.

Edit: Je viens de réaliser que cela fonctionne aussi sous 64 bits.

Bien qu'il /Cpuisse ignorer les erreurs, ce n'est peut-être pas la vraie solution car il peut y avoir des fichiers qui DOIVENT être copiés pour que la construction réussisse.

Le problème le plus courant concerne les guillemets manquants autour des balises de commande prédéfinies (telles que $TargetDir). Lorsqu'on crée diverses branches et chemins dans le code ou TFS, il y a de très fortes chances que cela se produise.

Parfois, si le fichier est en lecture seule, cela entraînera également des problèmes. Ajoutez l' /Roption permettant d'autoriser la copie des fichiers en lecture seule. Vous pouvez trouver la liste des options disponibles sur:

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/xcopy.mspx?mfr=true

Un autre problème possible est que le dossier sous-jacent n'est pas accessible. Si tel est le cas, essayez de jouer "start xcopy"au lieu de "xcopy". Cela ouvrira une autre fenêtre de commande mais avec les privilèges d'administrateur.

J'ai traversé la même erreur, mais ce n'est pas parce que le fichier est verrouillé, mais le fichier est manquant.

La raison pour laquelle VS a essayé de copier un fichier inexistant est à cause de la commande d'événement post-build.

Après avoir effacé cela, le problème est résolu.

METTRE À JOUR:

Comme l'a commenté @rhughes:

Le vrai problème est de savoir comment faire fonctionner la commande ici, plutôt que de la supprimer.

et il a absolument raison.

J'ai également rencontré ce problème. Vérifiez le résultat dans la fenêtre d'erreur.

Dans mon cas, un tailing \plantait xcopy (comme je l'utilisais $(TargetDir)). Dans mon cas $(SolutionDir)..\bin. Si vous utilisez une autre sortie, cela doit être ajusté.

Notez également que start xcopycela ne résout pas le problème, si l'erreur a disparu après la compilation. Il a peut-être été supprimé par la ligne de commande et aucun fichier n'a été copié!

Vous pouvez btw exécuter manuellement vos commandes xcopy dans un shell de commande. Vous obtiendrez plus de détails lors de leur exécution là-bas, vous dirigeant dans la bonne direction.

Dans le cas où l'événement post build contient la commande copy / xcopy pour copier la sortie de build dans un répertoire (ce qui est généralement l'opération post build la plus courante), le problème peut survenir au cas où le chemin complet du répertoire des destinations source ou cible contient des noms de dossier qui incluent les espaces. Supprimez de l'espace pour le (s) nom (s) de répertoire et essayez.

Comme mentionné dans de nombreux sites, il y a plusieurs raisons à cela. Pour moi, c'était dû à la longueur de la source et de la destination (longueur du chemin). J'ai essayé xcopy dans l'invite de commande et je n'ai pas pu taper la source et le chemin complets (après certains caractères, cela ne vous permettra pas de taper). J'ai ensuite réduit la longueur du chemin et j'ai pu courir. J'espère que cela t'aides.

Exécutez VS en mode administrateur et cela devrait fonctionner correctement.

J'ai eu cette erreur parce que le compte d'utilisateur sous lequel TFS Build Service s'exécutait n'avait pas les autorisations d'écrire dans le dossier de destination. Right-click on the folder-->Properties-->Security.

Cela peut se produire dans plusieurs cas:

1. Lorsque le chemin d'accès complet de la chaîne dépasse 254 caractères.
2. Lorsque le nom du fichier à copier est incorrect.
3. Lorsque le chemin cible est erroné.
4. Lorsque l'attribut readonly est défini sur le fichier copié ou le dossier cible.

J'ai eu cette erreur parce que le fichier a été ouvert dans une autre instance.

lorsque j'ai fermé le fichier et reconstruit à nouveau la solution, il a été copié avec succès.

J'ai rencontré le même problème dans le cas de XCOPY une fois la construction terminée. Dans mon cas, le problème se produisait en raison d'autorisations en lecture seule définies sur les dossiers.

J'ai ajouté la commande attrib -R avant XCOPY et cela a résolu le problème.

J'espère que cela aide quelqu'un!

J'ai eu la même erreur avec xcopy en relation avec le moteur de test. J'utilise VisualStudio Professional 2013. Par défaut Test -> Test Settings -> Keep Test Execution Engine Running semble être la raison de mon code d'erreur 4 avec xcopy. Le désactiver a résolu le problème. Le moteur d'exécution semble conserver certains fichiers .dll.

J'ai eu le même problème. Une simple «solution propre» dans VS a effacé l'erreur, mais c'était une solution temporaire.

J'ai trouvé que la définition du paramètre Copier dans le répertoire de sortie du fichier sur Copier toujours semble avoir résolu le problème de verrouillage. Bien que maintenant j'ai 2 copies des fichiers et que je dois en supprimer une.

J'ai eu le même problème. Cependant, rien n'a fonctionné pour moi. J'ai résolu le problème en ajoutant

exit 0

à mon code. Le problème était que pendant que je copiais les fichiers, le dernier fichier était parfois introuvable et la chauve-souris renvoyait une valeur non nulle.

J'espère que cela aide quelqu'un!

Si vous exécutez Windows 7 en avant, vous pouvez essayer la nouvelle commande 'robocopy':

robocopy "$(SolutionDir)Solution Items\References\*.dll" "$(TargetDir)"

Vous trouverez plus d'informations sur la robocopie ici .

J'ai fait face au même problème. J'ai supprimé les événements post-build et cela a commencé à fonctionner. Parfois, lorsque nous ajoutons des composants SQL, cela peut également ajouter des commandes post-build.

J'obtiens quelque chose de similaire en utilisant un xcopy avec l'option / exclude. Dans mon cas, j'ai trouvé que l'édition de l'événement post-build (quelque chose d'inoffensif comme une nouvelle ligne après la commande) et l'enregistrement du projet provoquaient l'erreur. La réenregistrement du fichier spécifié dans l'option / exclude le fait fonctionner à nouveau.

Pendant que j'écris une bibliothèque DLL, j'ai utilisé la commande xcopy pour copier la bibliothèque où le programme peut la trouver et la charger. Après plusieurs fois d'ouverture et de fermeture du programme, il y avait encore un processus ouvert dans le gestionnaire de tâches que je n'ai pas reconnu.

Recherchez tout processus à partir duquel le fichier peut être utilisé et fermez-le.

Qu'est-ce qui l'a arrangé pour moi le problème : recherchez la solution spécifique pour le projet que vous souhaitez, c'est-à-dire PAS le fichier de solution globale pour tous les projets.

Essayez - j'ai essayé tout le reste mentionné ici mais en vain.

Je ne vois rien ici pour suggérer qu'il s'agit d'une application Web, mais j'ai moi-même rencontré ce problème - j'ai deux commandes xcopy sur un événement post-build et une seule d'entre elles a échoué. Quelque chose avait un verrou sur le fichier, et ce n'était pas Visual Studio (comme j'ai essayé de le redémarrer.)

La seule autre chose qui aurait utilisé la dll que j'ai construite était IIS. Et voici,

Un simple a iisresetfait l'affaire pour moi.

J'ai eu le même problème. Cela a été causé par le fait d'avoir le même drapeau deux fois, par exemple:

if $ (ConfigurationName) == Release (xcopy "$ (TargetDir) . " "$ (SolutionDir) Deployment \ $ (ProjectName) \" / e / d / i / y / e)

Observez que l'indicateur "/ e" apparaît deux fois. La suppression du doublon a résolu le problème.

Dans mon cas, $(OutDir)c'était simplement ..\..\Build\un chemin relatif. Et, lorsque j'essayais de xcopy comme suit, xcopy /y "$(OutDir)Proj1.dll" "Anypath\anyfolder\"j'obtenais l'erreur de code de sortie 4.

Ce qui se passe, c'est que cette commande était exécutée dans le $ (OutDir) (dans mon dossier de construction de cas) lui-même et non dans le répertoire où se trouvait le fichier csproj du projet (comme on s'y attendrait normalement). Par conséquent, j'ai continué à recevoir une File not founderreur (correspondant au code de sortie 4).

Je ne pouvais pas comprendre cela jusqu'à ce que j'écrive cddans les événements Post Build, pour imprimer dans quel répertoire cela était exécuté.

Donc, pour résumer, si nous souhaitons vers copy/ xcopyfiles à partir de $(OutDir), utilisez "$(TargetDir)"(qui est le chemin complet du répertoire de sortie) ou ne devez pas spécifier de chemin du tout.

Peut être causé par VMWare Workstation avec des dossiers partagés

J'ai toujours le problème lorsque le dossier destinatinon du xcopy est également mappé en tant que dossier partagé dans une machine virtuelle.

Je l'ai résolu avec un script s'exécutant dans le vm et supprimant le contenu du dossier partagé.

Pour développer la réponse rhughes,

La robocopy fonctionne à merveille, juste au cas où vous auriez besoin d'inclure des sous-répertoires que vous pouvez utiliser /epour inclure des sous-répertoires et copier des répertoires vides ou /spour inclure des sous- répertoires à l'exclusion des répertoires vides.

De plus, robocopy rapportera certaines choses comme si de nouveaux fichiers ont été copiés, cela amènera VS à se plaindre car tout ce qui est supérieur à 0 est un échec et robocopy renverra 1 si de nouveaux fichiers ont été trouvés. Il vaut la peine de mentionner que robocopy compare d'abord la source / destination et ne copie que les fichiers mis à jour / nouveaux.

Pour contourner cette utilisation:

(robocopy "$(SolutionDir)Solution Items\References\*.dll" "$(TargetDir)") ^& IF %ERRORLEVEL% LEQ 4 exit /B 0

Si vous êtes ici parce que votre projet ne parvient pas à se construire sur un serveur de compilation, mais qu'il se construit correctement "manuellement" sur une machine de développement, et que vous faites xcopy que pour le débogage et pour émuler un environnement de production sur une machine de développement, alors vous voudrez peut-être regarder à cette solution:

https://stackoverflow.com/a/1732478/2279059

Vous désactivez simplement les événements de post-build sur le serveur de build en utilisant

msbuild foo.sln /p:PostBuildEvent=

Ce n'est pas suffisant si vous avez d'autres événements post-build qui doivent également s'exécuter sur le serveur de build, et ce n'est pas une solution générale. Cependant, comme il existe tant de causes différentes de ce problème, il ne peut y avoir de solution générale. L'une des nombreuses réponses à cette question (et ses doublons) vous aidera probablement, mais soyez prudent avec les approches qui ne font que contourner d'une manière ou d'une autre la gestion des erreurs (comme xcopy /C). Ceux-ci peuvent fonctionner pour vous, en particulier aussi dans le scénario du serveur de construction, mais je pense que celui-ci est plus fiable, SI il peut être utilisé.

Il a également été suggéré qu'avec les versions plus récentes de Visual Studio, le problème n'existe plus, donc si vous utilisez une ancienne version, envisagez de mettre à jour vos outils de génération.

Le code d'erreur 4 peut signifier beaucoup de choses, je vous recommande donc de lire les autres réponses jusqu'à ce que vous trouviez une solution qui fonctionne pour vous ET que vous compreniez POURQUOI cela fonctionne (certaines solutions ne désactivent que la gestion des erreurs, ce qui ne peut que masquer le problème mais pas résoudre).

Cela peut être un problème de verrouillage de fichier lié à la construction parallèle. Une solution de contournement consiste à ne pas utiliser la construction parallèle. Il s'agit du comportement par défaut, mais si vous utilisez l' -moption, les projets seront créés en parallèle. Les variantes suivantes ne doivent pas générer de projets en parallèle, vous ne rencontrerez donc pas le problème de verrouillage de fichier.

msbuild -m:1
msbuild -maxcpucount:1
msbuild

Notez que, contrairement à ce qui a été dit ici, cela se produit même avec la «dernière» version de MSBuild (de Build Tools pour Visual Studio 2019).

La meilleure solution est probablement de vous assurer que vous n'avez pas besoin de copier des fichiers dans une étape post-construction. Dans certaines situations, vous pouvez également désactiver les étapes post-build lors de la création avec MSBuild sur un serveur de build: https://stackoverflow.com/a/55899347/2279059