I found a msdn forum post with exactly the same issue: http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/42647eff-ecb8-412c-a884-a152b6fdd40d
It turns out that it is NOT msbuild but it is SN.exe leaving the temp files behind when resigning assemblies. I suppose you could easily come to this conclusion when watching the build and those files are flashing by so quickly.
On reflection a custom task will not help either…
This post has more details on the issue with a link to a hot fix (haven’t tried it yet): http://blogs.msdn.com/pfedev/archive/2008/10/24/sn-exe-and-empty-temp-files-in-temp.aspx
Recently at work we have be observing a very odd behaviour, a particular set of builds has been slowing by about 30 minutes every night.
We discovered that hundreds of temporary files were being created by the msbuild exec task. What happens is that the exec task will created a temp file, then use the temp file name to create a batch file with the command in it. In most cases it will delete the temp file and the batch file. If you are quick enough you can pause the build and look in the temp folder and observe these files.
Now the strange thing is we have observed a specific case of when msbuild will not delete that temporary file, thus adding a cumalative amount of time every night when it is trying to find a new temp file name. This occurs when we resign our assemblies using SN. If you use SN to verify the assemblies the temp file is cleaned up afterwards.
This is quite a baffling problem, when calling the same executable with a different command it just works, seems odd to me that it would cause such an issue. There is also little on the internet that hints at this issue, I suppose if people are careul and look after the servers with regular cleanup tasks this issue might never arise.
So at the moment to work around the issue we have written temp folder clean up tasks and a sceduled disk clean up task on the server. I might write a set of specific tasks wrapping the SN executable and its command line arguments to reduce the need for such measures.
If I can get any sort of grasp on the actual issue then I will create and link to an MSConnect issue.