xcopy wordt niet herkend als een interne of externe opdracht, een bruikbaar programma of een batchbestand

Ik heb een probleem met het commando 'xcopy'.

Ik bouw een C# -project met msbuild. Aan het einde van de build wordt een batchbestand aangeroepen om mijn assembly's te kopiëren van Debug/Release naar enkele andere mappen.

Hier is het probleem, mijn build mislukt en het foutenlogboek is 'xcopy wordt niet herkend als een interne of externe opdracht, bedienbaar programma of batchbestand'.

Het pad is correct ingesteld, xcopy werkt vanaf een Windows-opdrachtregel en vanaf de opdrachtregel van de visuele studio (die is ingesteld met de projectomgeving).

Ik heb geprobeerd het pad in het batchbestand in te stellen, maar het helpt niet.

Enige suggestie?

Ik gebruik Windows 7

Cheers :)

28

7 antwoord

Ik ben hetzelfde probleem tegengekomen.

Het lijkt een probleem te zijn met de padomgevingsvariabele binnen Visual Studio.

Toen ik een "pad" -instructie aan het begin van mijn build-gebeurtenis toevoeg, produceerde dit de volgende uitvoer:

PATH=

Dit lijkt erop te wijzen dat het pad leeg is in de VS-buildomgeving.

Toen ik het volledige pad naar xcopy op deze manier specificeerde, ging het probleem weg:

%systemroot%\System32\xcopy ...

Ik weet niet zeker waardoor Visual Studio het pad heeft verloren.

38
toegevoegd

Set Environment variable PATH = %systemRoot%\system32;%systemRoot%;%systemRoot%\System32\Wbem;%sYSTEMROOT%\System32\WindowsPowerShell\v1.0\

11
toegevoegd

Het overkwam mij nadat ik een van mijn Visual Studio-extensies had bijgewerkt, waarbij Visual Studio werd gesloten en opnieuw werd geopend door de updater. Ik kon mijn project niet meer goed opbouwen. Ik sloot Visual Studio en heropende het en het probleem ging weg.

6
toegevoegd
Hier ook. Het sluiten van VS en het opnieuw openen loste het probleem op.
toegevoegd de auteur Sebastian Krysmanski, de bron

Dit is geen probleem met Windows 7 of 8. Het is eigenlijk een probleem met applicaties die omgevingsvariabelen zoals PATH updaten. Het pad wordt opgeslagen in het register als een "waarde voor uitvouwbare tekenreeks" (REG_EXPAND_SZ), maar veel toepassingen schrijven het terug naar het register als een "tekenreekswaarde" (REG_SZ). Als uw pad iets bevat als% SYSTEMROOT%, wordt dit niet uitgebreid naar C: \ Windows (of wat het uwe is) als het pad is toegewezen aan een REG_SZ.

De oplossing is simpelweg om uw pad handmatig te bewerken via het bedieningspaneel. U moet een wijziging aanbrengen (bijvoorbeeld een; aan het einde van het pad toevoegen) en het vervolgens toepassen. Hiermee wordt uw pad in het register hersteld als REG_EXPAND_SZ. (Ga naar het systeembedieningspaneel en selecteer Advanced System Settings. Wijzig de Path Environment-variabele in het onderste vak en dat zou het probleem moeten oplossen.

U kunt zien of uw pad op deze manier is verbroken door een opdrachtprompt te openen en PATH in te voeren. Uw pad zal worden vermeld. Als u iets ziet dat is ingesloten in%%, wordt uw pad niet uitgebreid.

6
toegevoegd
Spot op Phil! In mijn geval was dit op Windows XP en de vermelding in het register (HKEY_LOCAL_MACHINE \ SYSTEM \ ControlSet001 \ Controle \ Sessiebeheer \ Omgeving \ Pad) was inderdaad ingesteld op REG_SZ. Het pad opnieuw instellen via Configuratiescherm> Systeem> Geavanceerd> Omgevingsvariabelen hebben dit in het register gecorrigeerd. Toen ik een nieuwe opdrachtprompt startte, was het pad goed "uitgebreid".
toegevoegd de auteur prairiehat, de bron

Ga naar de omgevingsvariabele en corrigeer PATh inclusief ; als laatste. Het zal werken, dit heeft helemaal niets te maken met OS of technologie. Het werkt voor mij, zelfs niet om OS opnieuw te starten, Open gewoon de nieuwe opdrachtprompt.

2
toegevoegd

I just experienced this for the first time with a batch file I use to copy an Access front-end app to the user's local machines. Their environment is a mix of Windows 7 & 8 and 32-64 bit machines. I noticed that the xcopy.exe was both in the System32 and the SysWOW64 folders and I wondered if there was some conflict. So -- I copied the xcopy.exe into the folder where the batch file resides and it now seems to be working. Just thought I'd share this.

Eileen

1
toegevoegd

Ik had ook een probleem met xcopy (dezelfde foutmelding) - met een heel eenvoudig batchprogramma dat ik gebruik om bestanden te back-uppen naar een verwisselbaar station. Gebruik dat programma minstens 5 jaar met nooit een probleem. Gisteren is xcopy niet bekend bij Win7. De vervanging van xcopy met% systemroot% \ System32 \ xcopy bij elk exemplaar loste het probleem op. Heel vreemd.

0
toegevoegd