When doing a a build (especially a batch-build) of many projects (in my case 40+), Visual Studio seems to have a tendency to grab handles to its own output files, and then not to release those handles. Pretty bad behaviour. And.. pretty annoying, too, if you constantly close and re-open your Visual Studio in order to force-close those handles. Oh, and one more thing – this bug seems to have been around since VS 2005, continued for VS 2008, and even haunts people with VS 2010. Yet again, congratulations MS on the many not-yet-fixed bugs in VS (googling on a bug of your own might show you that you are not alone, and that your specific problem has not been fixed by MS for a looong time! As long as it has been made known to MS).
So you can easily find error descriptions on MS Connect like „MSB3021: Unable to copy file“ bug still not fixed in final version or error MSB3021 Unable to copy …..
Luckily for me, I have found a solution (at least for my problem). The problem is that a xxx.vshost.exe process has hogged those files (check with Process Explorer by Sysinternals or a similar tool). The xxx.vshost.exe is mostly used for debugging, so I was surprised to find it constantly running, even at build-time, with no debug having taken place. After a short search I found out another use of this process: it is used for editing-time syntax checks and similar feats. Oh, and it had the name of my selected start-up-project. So.. I found the simple solution to change the start-up-project to one that has no application as a build target, but rather a class library, and somehow.. the vshost.exe process vanished, leaving my compiles untouched and my nerves at ease.
Hope this will be useful to someone else, getting frustrated about the many bugs in VS 2008 (and 1000s of people must have stumbled upon them, like no variables in the output path.. again for many versions of VS).