MSB5108 – Warning: Failed to delete the temporary file
In a nutshell
AVG anti-virus was causing the temporary batch file to lock, disabling it solved the build warning.
Behind the scene
Last week I was facing this warning MSB5018 when compiling my C# project on my build machine, though this error was not occurring on my development system. In order to resolve the error I tried searching internet but hardly found any articles on internet about it.
The way build system on our company is architect-ed is that if it finds the compiler/linker output log to be not empty then it marks the build as failed. This works fine for our C++ projects since the C++ compiler has option to have separate the error and warning logs, but for .Net the warning and errors go to the same log file.
In order to work around this problem I changed project setting to ignore the warning number 5018, since I can only specify the digits in ignore warning list and not the whole “MSB5018”. This resulted in compiler errors since compiler was trying to look up for CS5018 instead of MSB5018. On further exploring the MSB warnings are part of the ms-build and not the C# compiler, these warnings cannot be ignored as per this discussion in MS forum.
For this warning MSB5018 I had to take a different approach, since build was running successfully on my system I started with comparing the differences between my development system and build system. There were a few differences, I had indexing switched off on my system and anti-virus on my system was different from that on the build machine in addition to the build system having a hardware RAID.
I tried turning off the indexing on the build machine and the build still fails, the reason for switching of the indexing was to be sure that the temporary batch files created by the .Net compiler which was causing the warning was not getting indexed causing the ms-build to fail.
The next step we was disabling the VIRUS and the build was successful. The anti VIRUS on build machine was AVG and it was causing the temporary batch files to lock.
During the process of troubleshooting we also checked for administrative privilege for build user on the build system and ensured his profile was not roaming. These kinds of warnings have nothing to do with programming but it does take lot of time to debug and troubleshoot.