I am getting this weird error on Windows 10 when I try to build any project. The projects are working fine if I build them on other OS.
The specified task executable "cmd.exe" could not be run. The
specified executable is not a valid application for this OS
platform.
When I tried to check the log I got to the following code in Nuget.targets file inside .nuget folder, I commented the code and the project builds fine now. I don't understand why the error. Any new projects that I create are working fine...
I am using Visual Studio 2013 on Windows 8, Windows Server 2008 and Visual Studio 2015 on Windows 10.
Code:
<Exec Command="$(RestoreCommand)"
LogStandardErrorAsError="true"
Condition="'$(OS)' == 'Windows_NT' And Exists('$(PackagesConfig)')" />
What is the reason for this error ?
Is it because of OS or because of Visual Studio ?
How do I resolve it? I don't think commenting the code is the way to do it...
I got the same error, and repairing the corrupted files solved my issue. Try this:
In administrator command prompt, run sfc /scannow
It should emit log file in %windir%\Logs\CBS\CBS.log. Confirm that it repaired cmd.exe. For me I saw something like this Repairing corrupted file [ml:48{24},l:46{23}]"\??\C:\WINDOWS\SysWOW64"\[l:14{7}]"cmd.exe" from store
If that doesn't help you can try DISM /Online /Cleanup-Image /RestoreHealth
See more here
It happened to me when building my project on Windows 10. The problem was that the path of one file was very long (longer than 260 characters). So, by making it shorter, the problem solved for me.
I had the same problem with VS c++ OpenFrameWorks. I tried your suggestion but could not solve the problem. I solved it differently as under.
Soln:
Project Properties ->
Build Events ->Post-Build Event -> Command line
"robocopy "$(OF_ROOT)/export/vs/$(Platform_Actual)/" "$(ProjectDir)bin/" "*.dll" /njs /njh /np /fp /bytes if errorlevel 1 exit 0 else exit %errorlevel%"
Removed Above line from command-line.
OK, Solved.
If you started to face this error after deleting some files :
Unload your project
Edit Your csprok
Delete any reference for the your deleted files
Reload your project and Build
I faced the same issue when building a .NetCore App using a template that includes an Angular app with it, and i tried to delete the ClientApp folder. I had to remove multiple Target and ItemGroup tags from within the csproj.
To those who have landed here:
If you get this message I suggest that you do not, as #Hans Passant suggested, first assume that your machine or Windows has been corrupted.
Instead, I recommend that you suspect that your anti-virus or Carbon Black installation is to blame.
This was the case for me.
Someone from my IT Department disabled a certain Carbon Black policy and everything magically worked again.
I want to copy binaries to stage server as the last step of build. Previously I was doing it for asp.net web sites powered by IIS. There were no problems as IIS doesn't block any boundaries. Now I need to do the same for executable server application (it executes some background tasks) which blocks at least its exe file. So I need somehow to close application, update binaries and then run application again.
What is the best way to achieve it using TeamCity?
I'm seems like your staging server is a windows machine. If that's the case, I'd recommend using two executables from the PsTools Suite (PsKill and PsExec) to kill/start your process. Here's how I would set everything up in TeamCity:
Download the PsTools Suite, and copy the contents of the zip file to a folder on the build server. I'll be using C:\Program Files\PsTools in my example.
Create a batch file that kills the executable server application, copies the appropriate binaries, and starts the application again. The batch file would look something like this:
"C:\Program Files\PsTools\PsKill" -accepteula \computername -u username -p password name_of_process_to_kill.exe
copy files - I'm assuming you copied binaries to your ASP.Net staging site using the command line. If not, I can provide more details later.
"C:\Program Files\PsTools\PsExec" -accepteula \computername -u username -p password -d "path_and_name_of_executable_on_remote_server" optional_commandline_args_here
Add a new command line build step to your TeamCity build configuration that executes the batch file created in step #2.
I hope this helps!
Here is how I solved it. I added Command Line step with following Custom Script:
taskkill /IM MyApplicationProcessName /F
xcopy RelativePathToBuildBinaires PathWhereToDeployBinaries /s /e /y
start PathToMyApplicationExeInDeployFolder
Initially it didn't work as TeamCity build agent worked as service (which do not have UI). Then I disabled service and started build agent as console (by TeamCityFolder/builagent/bin/agent.bat). And it worked.
Visual Studio 2010 on Windows 7 64bit is locking .aspx, .ascx, .css, and .js files. I'm a front-end web developer and I've written a ROBOCOPY script to prevent me from having to do a full build of our solution. The solution has a post-build step to copy all the web asset files (non compiled files) into the deploy directory. The problem is that this triggers IIS to restart the app and requires a re-login, so that's a painful option especially when I want to be able to make fast, incremental updates to the css, js, and html templates.
ROBOCOPY bat file:
robocopy C:\**sln dir**\Content C:\**deploy dir**\Content /MIR /ZB /B /XD "*.svn"
robocopy C:\**sln dir**\Views C:\**deploy dir**\Views /MIR /ZB /B /XD "*.svn"
robocopy C:\**sln dir**\Scripts C:\**deploy dir***\Scripts /MIR /ZB /B /XD "*.svn" "*.idea"
Cmd output:
2011/02/16 11:16:01 ERROR 32 (0x00000020) Copying File C:\*** etc ***\Edit.aspx
The process cannot access the file because it is being used by another process.
Every consecutive time I run the script, the lock is dropped on one file, then crashes on the next, until finally, all the files copy over. I have tried the /W:n flag, but the lock is never release until I ctrl+C then try again. Are there any ways to either get robocopy to accept locked files or for VS2010 to not lock files that are open for editing?
You can use the SysInternals tools to find out which process is locking your files, I'm guessing it's the Cassini webserver. If so, then Visual Studio 2010 with SP 1 Beta (beta yikes) and IIS Express can be used in place of Cassini. I don't know if this even makes sense for your development environment or if it would prevent your files from getting locked when you want to do the robocopy, but could be worth taking a peek at.
Every now and then when I build my solution here (with 7 projects in it) I get the dreaded 'Command copy exited with code 4' error, in Visual Studio 2010 Premium ed.
This is because of the post-build event not being able to go through.
Here's what solves the problem, temporarily
Sometimes: A restart of Visual Studio and I'm able to build the solution
Sometimes: Both a restart of Visual Studio and my file manager of choice (Q-Dir 4.37) solves it.
Here's what the post-build event looks like:
xcopy "$(SolutionDir)Solution Items\References\*.dll" "$(TargetDir)" /Y
When you get the command copy exited with code [insert value] error, it's normally because of the following:
read / write permissions
missing files
wrong directories
However - obviously at times when I build the solution, there's no problem.
FYI, I uninstalled ReSharper 5.1.1 two weeks ago and Visual Studio's been giving me some errors since then (among them not being able to debug). I re-installed Visual Studio and it's working better since then, but still get this problem. Could it have to do with some ReSharper stuff being somewhere?
Have you had the same problem and solved it? Or do you have any possible solution to it?
While /C may ignore errors, it might not be the real solution as there could be files that MUST be copied in order for the build to be successful.
The most common issue is the missing quotes around the pre-defined command tags (such as $TargetDir). When one creates various branches and paths in code or TFS, there is a very high chance for this to occur.
Sometimes if the file is read only, it will cause issues too. Add the /R option to allow read only files to be copied over. You can find list of available options at:
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/xcopy.mspx?mfr=true
Another possible issue is that the underlying folder cannot be accessed. If so, trying performing "start xcopy" instead of "xcopy". This will open another command window but with admin priveleges.
I've invariably found this to be a file locking issue. Code 4 is Cannot Access File. One partial solution I found is to use the /C option for xcopy (which continues on error). Not really a solution but mostly it has stopped my builds from failing.
Another solution which only works on 32 bit is to use the unlocker tool to release the windows handles on the file before the copy.
Edit: I've just realised that it works under 64 bits too.
I crossed the same error, but it is not due to the file is locked, but the file is missing.
The reason why VS tried to copy an not existing file, is because of the Post-build event command.
After I cleared that, problem solved.
UPDATE:
As #rhughes commented:
The real issue is how to get the command here to work, rather than to
remove it.
and he is absolutely right.
I have also faced this problem.Double check the result in the error window.
In my case, a tailing \ was crashing xcopy (as I was using $(TargetDir)). In my case $(SolutionDir)..\bin. If you're using any other output, this needs to be adjusted.
Also note that start xcopy does not fix it, if the error is gone after compiling. It might have just been suppressed by the command line and no file has actually been copied!
You can btw manually execute your xcopy commands in a command shell. You will get more details when executing them there, pointing you in the right direction.
In case the post build event contains copy/xcopy command for copying build output to some directory(which usually is the most common post build operation) the problem can occur in case the full directory path either of source or target destinations contain folder names which include spaces. Remove space for the directory name(s) and try.
As mentioned in many sites, there are various reasons for this. For me it was due to the length of Source and Destination (Path length). I tried xcopy in the command prompt and I was unable to type the complete source and path (after some characters it wont allow you to type). I then reduced the path length and was able to run.
Hope this helps.
This can happen in multiple cases:
When the complete string path is longer than 254 chars.
When the name of the file to be copied is wrong.
When the target path is wrong.
When the readonly attribute is set on the copied file or target folder.
I got this error because the user account that TFS Build Service was running under did not have permissions to write to the destination folder. Right-click on the folder-->Properties-->Security.
Run VS in Administrator mode and it should work fine.
I got this error because of the file was opened in another instance.
when i closed the file and again re-build the solution, it was successfully copied.
I faced the same issue in case of XCOPY after build is done. In my case the issue was happening because of READ-ONLY permissions set on folders.
I added attrib -R command before XCOPY and it solved the issue.
Hope it helps someone!
I had the same error with xcopy in connection with the Test Engine. I am using VisualStudio Professional 2013. By default Test -> Test Settings -> Keep Test Execution Engine Running seems to be the reason for my error code 4 with xcopy. Switching it off solved the problem. The execution engine seems to keep hold on some .dlls.
I had the same problem.
A simple 'Clean Solution' in VS cleared the error, but it was a temporary solution.
I found that setting the file's Copy To Output Directory parameter to Copy Always seems to have cleared up the locking issue. Although now I have 2 copies of the files and need to delete one.
I had the same problem. However, nothing worked for me. I solved the issue by adding
exit 0
to my code. The problem was that while I was doing copying of the files, sometimes the last file could not be found, and the bat returned a non-zero value.
Hope this helps someone!
If you are running Windows 7 onward, you can try the new 'robocopy' command:
robocopy "$(SolutionDir)Solution Items\References\*.dll" "$(TargetDir)"
More information about robocopy can be found here.
I faced same issue.
I deleted post-build events and it started working.
Some times when we add some SQL components it may add post build commands also.
I am getting something similar using an xcopy with the /exclude option. In my case, I found that editing the post-build event (something harmless like a newline after the command) and saving the project causes the error to happen. Re-saving the file specified in the /exclude option causes it to work again.
As I am writing a DLL library I used the xcopy command to copy the library where the program can find and load it. After several times of opening and closing the program there was still an open process of it in taskmanager which i did not recognized.
Look for any process from which the file may be used and close it.
What fixed it for me:
dig down to the specific solution for the project you want i.e NOT the overall solution file for all the projects.
Do try - I tried everything else mentioned here but to no avail.
I don't see anything in here to suggest that this is a web-app but I have experienced this issue myself - I've got two xcopy commands on a post-build event and only one of them was failing. Something had a lock on the file, and it wasn't Visual Studio (as I tried restarting it.)
The only other thing that would have used the dll I built was IIS. And lo and behold,
A simple iisreset did the trick for me.
I had the same issue.
It was caused by having the same flag twice, for example:
if $(ConfigurationName) == Release (xcopy "$(TargetDir)." "$(SolutionDir)Deployment\$(ProjectName)\" /e /d /i /y /e)
Observe that the "/e" flag appears twice. Removing the duplicate solved the issue.
In my case my $(OutDir) was simply ..\..\Build\ i.e. some relative path. And, when I was trying to xcopy as follows
xcopy /y "$(OutDir)Proj1.dll" "Anypath\anyfolder\" I was getting the exit code error 4.
What's happening was, this command was getting executed in the $(OutDir) (in my case build folder) itself and not the directory where the csproj file of the project was located (as we would normally expect). Hence, I kept getting File not found error (corresponding to exit code 4).
I couldn't figure this out until I wrote cd in the Post Build events, to print which directory this was getting executed in.
So, to summarize, if we're wishing to copy / xcopy files from the $(OutDir), either use "$(TargetDir)" (which is complete path for output directory) or need not specify any path at all.
Can be caused by VMWare Workstation with Shared Folders
I have the problem always when the destinatinon folder of the xcopy is also mapped as Shared Folder in a VM.
I solved it with a script running in the vm and deleting the content of the shared folder.
To expand on rhughes answer,
The robocopy works beautifully, just incase you need to include sub directories you can use /e to include subs and copy empty directories or /s to include subs excluding empty directories.
Also robocopy will report back a few things like if new files were copied, this will cause VS to complain since anything above 0 is a failure and robocopy will return 1 if new files have been found. Its worth to mention that robocopy first compares the Source/Dest and only copies the updated/new files.
To get around this use:
(robocopy "$(SolutionDir)Solution Items\References\*.dll" "$(TargetDir)") ^& IF %ERRORLEVEL% LEQ 4 exit /B 0
If you are here because your project fails to build on a build server, but builds fine "manually" on a dev machine, and you are doing xcopy only for debugging and to emulate a production environment on a dev machine, then you may want to look at this solution:
https://stackoverflow.com/a/1732478/2279059
You simply turn off post build events on the build server using
msbuild foo.sln /p:PostBuildEvent=
This is not good enough if you have other post build events that also need to run on the build server, and it is not a general solution. However, since there are so many different causes of this problem, there cannot be a general solution. One of the many answers to this question (and its duplicates) will probably help, but be careful with approaches that only somehow circumvent error handling (such as xcopy /C). Those may work for you, particularly also in the build server scenario, but I think this one is more reliable, IF it can be used.
It has also been suggested that with newer versions of Visual Studio, the problem no longer exists, so if you are using an old version, consider updating your build tools.
Error code 4 can mean a lot of things, so I recommend reading the other answers as well until you find a solution that works for you AND you understand WHY it works (some solutions only disable error handling, which may only mask the problem but not solve it).
This can be a file locking issue related to parallel building. A workaround is to not use parallel building. This is the default behavior, but if you are using the -m option, then projects will be built in parallel. The following variations should not build projects in parallel, so you will not run into the file locking problem.
msbuild -m:1
msbuild -maxcpucount:1
msbuild
Note that, contrary to what has been said here, this even happens with the "latest" version of MSBuild (from Build Tools for Visual Studio 2019).
The best solution is probably to make sure you don't need to copy files in a post-build step. In some situations, you can also disable post-build steps when building with MSBuild on a build server: https://stackoverflow.com/a/55899347/2279059
I want to amplify and crystallize these two answers: #Vemul's, #Srihari Chinna's.
Make sure that your source path exists and that the process has access to it.
This is especially true if you're using variable substitution to assemble the source path.