xcopy n'est pas reconnu comme une commande interne ou externe, un programme utilisable ou un fichier de commandes
J'ai un problème avec la commande 'xcopy'.
Je construis un projet C # avec msbuild. À la fin de la construction, un fichier de commandes est appelé pour copier mes assemblages de Debug/Release vers d'autres dossiers.
Voici le problème, ma construction échoue et le journal des erreurs est 'xcopy n'est pas reconnu comme une commande interne ou externe, un programme utilisable ou un fichier de commandes'.
Le chemin est correctement défini, xcopy fonctionne à partir d’une ligne de commande Windows et d’une ligne de commande de visual studio (celle définie avec l’environnement du projet).
J'ai essayé de définir le chemin dans le fichier de commandes, mais cela n'aide pas.
Toute suggestion?
J'utilise Windows 7
À votre santé :)
J'ai rencontré le même problème.
Cela semble être un problème avec la variable d'environnement de chemin d'accès dans Visual Studio.
Lorsque j'ai ajouté une instruction "path" au début de mon événement de construction, le résultat suivant a été généré:
PATH=
Cela semble indiquer que le chemin est vide dans l'environnement de génération de VS.
Quand je spécifie le chemin complet vers xcopy comme ceci, le problème a disparu:
%systemroot%\System32\xcopy ...
Je ne suis pas sûr de ce qui a fait perdre le chemin à Visual Studio.
Définir la variable d'environnement PATH = %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\
Cela m'est arrivé après la mise à jour de l'une de mes extensions Visual Studio, pendant laquelle Visual Studio a été fermé et rouvert par le programme de mise à jour. Je ne pouvais plus construire correctement mon projet. J'ai fermé Visual Studio, je l'ai rouvert et le problème a disparu.
Ce n'est pas un problème avec Windows 7 ou 8. C'est en fait un problème avec les applications qui mettent à jour des variables d'environnement telles que PATH . Le PATH est stocké dans le registre sous la forme d'une "valeur de chaîne extensible" (REG_EXPAND_SZ), mais beaucoup les applications l'écrivent dans le registre en tant que "valeur de chaîne" (REG_SZ). Si votre chemin contient quelque chose comme% SYSTEMROOT%, cela ne sera pas développé dans C:\Windows (ou quel que soit le vôtre) si le chemin est enregistré dans un REG_SZ.
Le correctif consiste simplement à modifier votre chemin manuellement à partir du panneau de configuration. Vous devez apporter une modification (par exemple, ajouter un; à la fin du chemin), puis l'appliquer. Cela corrigera votre chemin dans le registre pour qu’il soit REG_EXPAND_SZ . (Allez dans le Panneau de configuration du système et sélectionnez Paramètres système avancés. Modifiez la variable d’environnement de chemin dans la zone inférieure et corrigez-la.
Vous pouvez savoir si votre chemin est cassé de cette manière en ouvrant une invite de commande et en tapant PATH. Votre chemin sera répertorié. Si vous pouvez voir quelque chose enfermé dans%%, votre chemin n'est pas développé.
Je viens tout juste de faire l'expérience de ce type pour la première fois avec un fichier de traitement par lots que j'utilise pour copier une application frontale Access sur les ordinateurs locaux de l'utilisateur. Leur environnement est un mélange de machines Windows 7 & 8 et 32-64 bits. J'ai remarqué que xcopy.exe était à la fois dans les dossiers System32 et SysWOW64 et je me suis demandé s'il y avait un conflit. Donc, j'ai copié le fichier xcopy.exe dans le dossier contenant le fichier de commandes et il semble maintenant fonctionner. Je pensais que je partagerais ceci.
Eileen
J'ai également eu un problème avec xcopy (même message d'erreur) - avec un programme de traitement par lots très simple que j'utilise pour sauvegarder des fichiers sur un lecteur amovible. Utilise ce programme depuis au moins 5 ans sans jamais avoir de problème. Alors hier, xcopy est inconnu de Win7. Le remplacement de xcopy par% systemroot%\System32\xcopy à chaque instance a résolu le problème. Très étrange.
[Corrigé pour moi] Après avoir ajouté les chemins corrects à la variable d'environnement "Path", cela ne fonctionne toujours pas (pour cmd et VisualStudio) (même après le redémarrage du PC).
Le problème était lié au paramètre de registre cassé: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Gestionnaire de sessions\Environment] ParameterName = PATHEXT
J'ai eu la valeur .wlua;. | Exe. Peut-être a-t-il été cassé après l'installation de quelque chose….. Tout fonctionne à nouveau après l'avoir changé en: .COM; .WSH; .MSC
J'espère que cela aide si rien d'autre ne fonctionne.