The process cannot access the file because it is being used by another process

Sometimes working on large projects with many developers using Visual Studio .NET can be frustrating, simply because you have a lot of hard-to-control factors. You need to know every best practice of the tool, as well as every problem and workaround. At the same time, this must be communicated to the rest of the team effectively. If you don't master this, you will spend an awful lot of time solving tool-related problems for you or your co-developers. And still, new things come up. Like this one:

At random our developers encountered a "Cannot create/shadow copy 'XXX' when that file already exists." on their machines when starting up a web application. A few reloads and mumbling secret magic words usually made the error go away. Annoying anyway. It happened both in Visual Studio .NET 2005 and 2008.

So, googling for a solution I found suggestions like this and this. A single line in the web.config (under system.web) should cure the problem:

<hostingEnvironment shadowCopyBinAssemblies="false" /> 


Now don't stop reading! This cures the problem mentioned, however it produced another even worse problem: As the developers on the team got the latest version from our version control, they started having trouble building. Typically:

1. Build the web project. No problems
2. View the web project in the browser
3. Make some changes in code and build again - build error:

Unable to copy file [Some random dll] to bin\debug\[Some random dll]. The process cannot access the file because it is being used by another process.

It only happened for Visual Studio .NET 2005 users (but that is stil the majority in our team). Workarounds like restarting the local web server or deleting the dll manually worked for some, but not all. Rebuilding the entire solution worked, but in our 48 projects solution, this took way to long time on each build.

It took me some time to figure out that the web.config change was the cause - and still I would probably not be able to prove it in court. Maybe other characteristics in our solution played a part too (the error is a confirmed bug, see the Microsoft knowledge base). But removing the line from web.config cured the problem for everyone. Now we happily live with our occasional "Cannot create/shadow copy 'XXX' " errors ;-)

The final solution seems to be upgrading to Visual Studio .NET 2008 (where the bug seems to be fixed) and re-applying the web.config change!