slmgr reconoce programa por lotes interno externo ejecutable dism como comando bootrec archivo xcopy

ejecutable - xcopy no se reconoce como un comando interno o externo, un programa operable o un archivo por lotes



shutdown no se reconoce como un comando interno o externo (7)

Acabo de experimentar esto por primera vez con un archivo por lotes que utilizo para copiar una aplicación de front-end de Access en las máquinas locales del usuario. Su entorno es una mezcla de máquinas de Windows 7 y 8 y 32-64 bits. Noté que xcopy.exe estaba en las carpetas System32 y SysWOW64 y me pregunté si había algún conflicto. Entonces, copié el xcopy.exe en la carpeta donde reside el archivo por lotes y ahora parece estar funcionando. Sólo pensé en compartir esto.

Eileen

Tengo un problema con el comando ''xcopy''.

Estoy construyendo un proyecto de C # con msbuild. Al final de la compilación, se llama a un archivo por lotes para copiar mis ensamblajes desde Debug / Release a otras carpetas.

Aquí está el problema, mi compilación falla y el registro de errores es "xcopy no se reconoce como un comando interno o externo, un programa ejecutable o un archivo por lotes".

La ruta está configurada correctamente, xcopy do funciona desde una línea de comandos de Windows y desde la línea de comandos de Visual Studio (la que está configurada con el entorno del proyecto).

Intenté establecer la ruta en el archivo por lotes pero no ayuda.

¿Cualquier sugerencia?

Estoy usando windows 7

Saludos :)


Establezca la variable de entorno PATH = %SystemRoot%/system32;%SystemRoot%;%SystemRoot%/System32/Wbem;%SYSTEMROOT%/System32/WindowsPowerShell/v1.0/


Esto no es un problema con Windows 7 u 8. En realidad, es un problema con las aplicaciones que actualizan variables de entorno como PATH. El PATH se almacena en el Registro como un "valor de cadena expandible" (REG_EXPAND_SZ), pero muchas aplicaciones lo escriben de nuevo en el Registro como un "Valor de cadena" (REG_SZ). Si su ruta contiene algo como% SYSTEMROOT%, esto no se expandirá a C: / Windows (o cualquiera que sea la suya) si la ruta se encuentra en un REG_SZ.

La solución es simplemente editar su ruta manualmente desde el panel de control. Debe realizar un cambio (por ejemplo, agregar un; al final de la ruta) y luego aplicarlo. Esto arreglará su ruta en el Registro para ser un REG_EXPAND_SZ. (Vaya al Panel de control del sistema y seleccione Configuración avanzada del sistema. Edite la variable Entorno de ruta en el cuadro inferior, y eso debería arreglarlo.

Puede saber si su ruta está rota de esta manera abriendo un símbolo del sistema y escribiendo PATH. Tu camino será listado. Si puede ver algo encerrado en%%, entonces su ruta no se está expandiendo.


Ir a la variable de entorno y corregir PATh incluyendo ; en última. Funcionará, esto no tiene nada que ver con el sistema operativo o la tecnología. Funciona para mí, ni siquiera es necesario reiniciar el sistema operativo, simplemente abra el nuevo símbolo del sistema.


Me encontré con el mismo problema.

Parece ser un problema con la variable de entorno de ruta en Visual Studio.

Cuando agregué una declaración de "ruta" al comienzo de mi evento de compilación, se produjo el siguiente resultado:

PATH=

Esto parece indicar que la ruta está vacía dentro del entorno de compilación de VS.

Cuando especifico la ruta completa a xcopy como esta, el problema desapareció:

%systemroot%/System32/xcopy ...

No estoy seguro de qué causó que Visual Studio perdiera su ruta.


Me sucedió después de actualizar una de mis extensiones de Visual Studio, durante la cual el actualizador cerró y volvió a abrir Visual Studio. Ya no pude construir correctamente mi proyecto. Cerré Visual Studio, lo volví a abrir y el problema desapareció.


También tuve un problema con xcopy (el mismo mensaje de error), con un programa por lotes muy simple que utilizo para hacer copias de seguridad de archivos en una unidad extraíble. He estado usando ese programa durante al menos 5 años sin ningún problema. Entonces ayer xcopy es desconocido para Win7. El reemplazo de xcopy con% systemroot% / System32 / xcopy en cada instancia resolvió el problema. Muy extraño.