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 for Server 2003: http://blogs.msdn.com/pfedev/archive/2008/10/24/sn-exe-and-empty-temp-files-in-temp.aspx

If you are using Server 2008 I would not recommend installing it.

Original:

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.

Download source

To use just define two properties: SearchPath, which is the parent folder to start looking in. It will search all subfolders as well by default. And BuildFolder, which is the desired target for building to.

All it does is very simple substring matching to check that it is valid.

For example, if I build a project to ..\bin\Debug and ..\bin\Release and the specify my build folder is ..\bin then both paths are valid. But if one of the build targets was set to something like ..\foo then it would be invalid

Again, this validator could be extended to check other parts of the project files.

So I built this MSBuild task to validate the assemblies after they have been built.

Download Source

It is very simple to use.

Create a property called ExpectedConfiguration that has the configuration.

Create inclusion and exclusion item groups called AssemblyInclusions and AssemblyExceptions.

Then use the ValidateAssemblies target.

It will then look for all assemblies and validate each ones configuration attribute.

This could be extended to validate assemblies much more extensively, like checking publisher and copyrigth details etc