For the last several months I’ve been building UE source version 4.26 with no problem. Today our company distributed licenses to switch from VS Community 2019 to VS Pro 2019 and so I updated to VS Pro 2019. Doing this caused all my modules to have to be rebuilt. I’ve got the UE4.sln loaded into VS Pro 2019, and when I try to build, everything builds until I get to the end when I get this:
1>Building 5 actions with 8 processes…
1> [1/5] dte80a.tlh
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Microsoft\VC\v160\Microsoft.MakeFile.Targets(45,5): error MSB3073: The command “…..\Build\BatchFiles\Build.bat -Target=“UE4Editor Win64 Development” -Target=“ShaderCompileWorker Win64 Development -Quiet” -WaitMutex -FromMsBuild” exited with code 6.
1>Done building project “UE4.vcxproj” – FAILED.
I’ve run Setup.bat and run through all the steps that you do for initial setup that I can think of. Does anyone have any idea what might be the issue or how to debug?
I found to edit out the extra quote, in Visual Studio open the UE4 project’s property page, and under Configuration Properties select NMake. This will show you a Build Command LIne, Rebuild All Command Line and a Clean Command Line. These can be edited to remove the extra quote.
But that didn’t fix anything for me. (Maybe it will for someone else though)
To fix my error I found this page:
And following the instructions there, I deleted my “Engine\Intermediate\Build\Win64\UE4Editor” folder and did a rebuild. After the delete, my build went fine.
Distributing 47 actions to XGE (TaskId:15)
Maximum number of concurrent builds reached. (TaskId:15)
This might look like a red herring (it did to me at first), but if you get this error, open up Task Manager and check if there are any orphaned ShaderCompileWorker threads. I had 2 of them. After ending those tasks my project starting building again
P.S. The quote after -Quiet is supposed to be there. In Visual Studio’s error message it just looks wrong
I’ve encountered the most hilarious situation. My project and engine are installed in a folder called “Epic Games”, and the space between them broke the command line. Make sure your file paths are without any space.
In case anyone else stumbles on this thread:
Actually, YES, do DO THAT.
For many problems, this is part of the fix. Delete the Intermediate folder (and the binaries folder too)
Then, right click the .uproject file, and select the ‘Generate Visual Studio Project Files’
to build a new .sln file based on the source files it finds.
The Intermediate folder is NOT part of that process, and it CAN safely be deleted.
Don’t delete it until you have tested it. Rename the folder to testDelete_intermediate (or something to that effect). Then test the build. If it still fails, you can restore the intermediate file if necessary.
I was like that too when I started with unreal, I (of course) backed up folders before deleting.
But now I know better; intermediate is not part of your project, it is an (intermediate, duh) product of it. IT IS SAFE TO DELETE, and more than that, it is ABSOLUTELY NOT something you want to include in source control (add it to the .gitignore if you use git/github), similarly, the VS solution (.sln) should also NOT be included in source control.
This may seem a little counter intuitive to anyone used to making other types of projects with VS, but it is how Unreal works - it makes the solution for you, and the intermediate folder is a part of what it does. Sometimes there can be problems because things get out of sync between what has been made in the intermediate folder and what is in your source code… So you delete that intermediate folder, and recreate a new .SLN
Feel comfortable that it IS perfectly fine to delete it, because a properly source controlled project should NEVER have either the .SLN or the intermediate folder in it - they get created, when you first download the project and generate the SLN, and then when you open that solution and start using it (and build, etc)
I even have a .bat file in the project folder which i run to automatically delete things and recreate the solution, because it is something you might need to do occasionally, especially if you are working on a collaborative project using Git where the source code pull can get the solution out of sync with the actual sourcecode you now have.