La copie de commande est sortie avec le code 4 lors de la création - le redémarrage de Visual Studio le résout
De temps en temps, lorsque je construis ma solution ici (avec 7 projets), l'erreur redoutée "Erreur de copie de commande" avec le code 4 "apparaît dans Visual Studio 2010 Premium ed.
Ceci est dû au fait que l’événement post-build n’a pas pu passer.
Voici ce qui résout le problème, temporairement
- Parfois: Un redémarrage de Visual Studio et je suis capable de générer la solution
- Parfois: Un redémarrage de Visual Studio et mon gestionnaire de fichiers de choix (Q-Dir 4.37) le résolvent.
Voici à quoi ressemble l'événement post-build:
xcopy "$(SolutionDir)Solution Items\References\*.dll" "$(TargetDir)" /Y
Lorsque vous obtenez la copie de commande terminée avec le 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 votre information, j'ai désinstallé ReSharper 5.1.1 il y a deux semaines et Visual Studio m'a envoyé des erreurs depuis lors (parmi elles, l'impossibilité de déboguer). J'ai réinstallé Visual Studio et cela fonctionne mieux depuis, mais le problème persiste. Cela pourrait-il avoir à voir avec des choses ReSharper quelque part?
Avez-vous eu le même problème et l'avez-vous résolu? Ou avez-vous une solution possible à cela?
À votre santé.
J'ai toujours trouvé qu'il s'agissait d'un problème de verrouillage de fichier. Le code 4 est Cannot Access File. Une solution partielle que j'ai trouvée consiste à 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é que mes versions échouent.
Une autre solution qui ne fonctionne que sur 32 bits consiste à utiliser l’outil unlocker pour libérer les poignées Windows du fichier avant la copie.
Edit: Je viens de me rendre compte que cela fonctionne aussi en 64 bits.
Bien que /C puisse ignorer les erreurs, il se peut que ce ne soit pas la vraie solution, car certains fichiers 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 (tels que $TargetDir). Lorsque vous créez différentes branches et chemins en code ou TFS, il y a de très fortes chances que cela se produise.
Parfois, si le fichier est en lecture seule, cela causera également des problèmes. Ajoutez l’option /R pour 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 est inaccessible. Si c'est le cas, essayez d'exécuter "start xcopy" au lieu de "xcopy". Cela ouvrira une autre fenêtre de commande mais avec des 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 non existant est à cause de la commande d'événement Post-build.
Après avoir effacé cela, le problème est résolu.
METTRE À JOUR:
Comme @rhughes a commenté:
Le vrai problème est de savoir comment obtenir la commande ici au lieu de retirez-le.
et il a absolument raison.
J'ai également fait face à ce problème. Vérifiez le résultat dans la fenêtre d'erreur.
Dans mon cas, un \ en queue bloquait xcopy (car j’utilisais $(TargetDir)). Dans mon cas, $(SolutionDir)..\bin. Si vous utilisez une autre sortie, celle-ci doit être ajustée.
Notez également que start xcopy ne résout pas le problème si l'erreur disparaît après la compilation. Il vient peut-être d'être supprimé par la ligne de commande et aucun fichier n'a été copié!
Vous pouvez en outre exécuter manuellement vos commandes xcopy dans un shell de commandes. Vous obtiendrez plus de détails en les exécutant ici, en vous indiquant la bonne direction.
Si l'événement post-build contient la commande copy/xcopy permettant de copier le résultat de la construction dans un répertoire (opération généralement la plus courante), le problème peut survenir si le chemin du répertoire complet de la source ou de la destination contient des noms de dossier comprenant les espaces. Supprimez de l'espace pour le (s) nom (s) du répertoire et essayez.
Comme mentionné dans de nombreux sites, il y a plusieurs raisons à cela. Pour moi, cela é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 ne pouvais pas taper la source complète et le chemin (après quelques caractères, il ne vous permettra pas de taper). J'ai ensuite réduit la longueur du chemin et j'étais capable de courir… .. J'espère que cela aide.
J'ai eu cette erreur parce que le compte d'utilisateur sous lequel le service de compilation TFS était en cours d'exécution ne disposait pas des autorisations nécessaires pour écrire dans le dossier de destination. Right-click on the folder-->Properties-->Security.
Exécutez VS en mode Administrateur et cela devrait fonctionner correctement.
Cela peut arriver dans plusieurs cas:
- Lorsque le chemin de chaîne complet dépasse 254 caractères.
- Lorsque le nom du fichier à copier est incorrect.
- Lorsque le chemin cible est incorrect.
- Lorsque l'attribut readonly est défini sur le fichier copié ou le dossier cible.
J'ai eu la même erreur avec xcopy en relation avec Test Engine. J'utilise VisualStudio Professional 2013. Par défaut, Test -> Paramètres de test -> Conserver l'exécution de Test Execution Engine 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 retenir certains fichiers .dll.
J'ai eu cette erreur parce que le fichier a été ouvert dans une autre instance.
lorsque j'ai fermé le fichier et que j'ai reconstruit à nouveau la solution, elle a été copiée avec succès.
J'ai rencontré le même problème dans le cas de XCOPY après la construction. Dans mon cas, le problème se produisait à cause des autorisations READ-ONLY définies sur les dossiers.
J'ai ajouté la commande attrib -R avant XCOPY et le problème a été résolu.
J'espère que ça aide quelqu'un!
J'ai eu le même problème… .. Il a été causé par avoir le même drapeau deux fois, par exemple:
if $ (ConfigurationName) == Publication (xcopy "$ (TargetDir). " "$ (SolutionDir) Deployment\$ (ProjectName) \"/e/d/i/y/e)
Observez que l'indicateur "/ e" apparaît deux fois. Supprimer le doublon a résolu le problème.
Ce qui a résolu le problème pour moi : Détendez-vous dans la solution spécifique au projet que vous voulez, 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.
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 rencontré le même problème… .. J'ai supprimé les événements post-génération et cela a commencé à fonctionner… .. Parfois, lorsque nous ajoutons des composants SQL, il peut également ajouter des commandes post-génération.
Si vous utilisez Windows 7, vous pouvez essayer la nouvelle commande 'robocopy':
robocopy "$(SolutionDir)Solution Items\References\*.dll" "$(TargetDir)"
Plus d'informations sur robocopy peuvent être trouvées ici .
J'ai constaté que la définition du paramètre Copier vers le répertoire de sortie du fichier sur Copier toujours semblait avoir résolu le problème du verrouillage. Bien que maintenant j'ai 2 copies des fichiers et dois en supprimer un.
Alors que j'écris une bibliothèque DLL, j'ai utilisé la commande xcopy pour copier la bibliothèque où le programme peut trouver et le charger. Après plusieurs ouvertures et fermetures du programme, il y avait toujours 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.
Dans mon cas, ma $(OutDir) était simplement ..\..\Build\, c’est-à-dire un chemin relatif. Et, quand j’essayais de copier xcopy comme suit xcopy /y "$(OutDir)Proj1.dll" "Anypath\anyfolder\" Je recevais l’erreur 4 du code de sortie.
Ce qui se passait, c’était que cette commande était exécutée dans le répertoire $ (OutDir) (dans mon cas, build), et non dans le répertoire où se trouvait le fichier csproj du projet (comme nous l’attendions normalement). Par conséquent, j'ai gardé l'erreur File not found (correspondant au code de sortie 4).
Je ne pouvais pas comprendre cela avant d’écrire cd dans les événements Post Build, pour imprimer le répertoire dans lequel il était exécuté.
Donc, pour résumer, si nous souhaitons copy/xcopy les fichiers de la $(OutDir), utilisez soit "$(TargetDir)" (qui est le chemin complet du répertoire de sortie) ou ne spécifiez aucun chemin.
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, parfois, le dernier fichier était introuvable, et la chauve-souris renvoyait une valeur non nulle.
J'espère que cela aide quelqu'un!
Je ne vois rien ici qui puisse suggérer qu'il s'agisse d'une application Web, mais j'ai moi-même rencontré ce problème. J'ai deux commandes xcopy lors d'un événement post-build et un seul 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 voilà,
Un simple iisreset a fait l'affaire pour moi.
Je reçois quelque chose de similaire en utilisant un xcopy avec l'option/exclude. Dans mon cas, j'ai constaté que l'édition de l'événement post-génération (quelque chose d'inoffensif, comme une nouvelle ligne après la commande) et l'enregistrement du projet provoquaient l'erreur. Réenregistrer le fichier spécifié dans l'option/exclude le fait fonctionner à nouveau.
Le code d'erreur 4 peut signifier beaucoup de choses, je vous recommande donc de lire les autres réponses également jusqu'à ce que vous trouviez une solution qui vous convient ET vous comprenez POURQUOI cela fonctionne-t-il? 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. C'est le comportement par défaut, mais si vous utilisez l'option -m, les projets seront construits en parallèle. Les variantes suivantes ne doivent pas construire des projets en parallèle, vous ne rencontrerez donc pas le problème du 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 (à partir de Build Tools for Visual Studio 2019).
La meilleure solution consiste probablement à vous assurer que vous n'avez pas besoin de copier des fichiers dans une étape post-génération. Dans certaines situations, vous pouvez également désactiver les étapes post-génération lors de la génération avec MSBuild sur un serveur de génération: https://stackoverflow.com/a/55899347/2279059
Pour développer rhughes répondre,
Robocopy fonctionne à merveille. Si vous devez inclure des sous-répertoires, vous pouvez utiliser /e pour inclure des sous-répertoires et copier des répertoires vides, ou /s pour inclure des sous-répertoires vides.
De plus, robocopy rapportera quelques choses, comme par exemple si de nouveaux fichiers étaient copiés, cela entraînera une plainte de VS car tout dépassement de 0 est un échec et robocopy retournera 1 si de nouveaux fichiers ont été trouvés. Il vaut la peine de mentionner que robocopy compare d’abord le fichier Source/Dest et ne copie que les fichiers mis à jour/nouveaux.
Pour contourner cet usage:
(robocopy "$(SolutionDir)Solution Items\References\*.dll" "$(TargetDir)") ^& IF %ERRORLEVEL% LEQ 4 exit /B 0
Peut être causé par VMWare Workstation avec dossiers partagés
J'ai toujours le problème lorsque le dossier de destination de la xcopy est également mappé en tant que dossier partagé dans une VM.
Je l'ai résolu avec un script s'exécutant dans la machine virtuelle et supprimant le contenu du dossier partagé.
Si vous êtes ici parce que votre projet ne parvient pas à créer sur un serveur de compilation, mais construit correctement "manuellement" sur une machine de développement, et que vous utilisez xcopy uniquement pour le débogage et pour émuler un environnement de production sur une machine de développement, vous pouvez regardez cette solution:
https://stackoverflow.com/a/1732478/2279059
Vous désactivez simplement les événements post-build sur le serveur de build à l'aide de
msbuild foo.sln /p:PostBuildEvent=
Cela ne suffit pas si d'autres événements post-génération doivent également être exécutés sur le serveur de génération, et il ne s'agit pas d'une solution générale. Cependant, comme il existe de nombreuses causes différentes à ce problème, il ne peut y avoir de solution générale. Une des nombreuses réponses à cette question (et à ses doublons) aidera probablement, mais soyez prudent avec les approches qui contournent d'une manière ou d'une autre la gestion des erreurs (telle que xcopy /C). Ceux-ci peuvent fonctionner pour vous, en particulier également dans le scénario de 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. Par conséquent, si vous utilisez une ancienne version, envisagez de mettre à jour vos outils de génération.