VS 2010 issue around MSB3021 is really bad…

I’m still somehow hoping that somebody can give me a tip that will work around this issue. I blogged about it recently, and there was a reaction in the form of a pointer at link to the MS Connect site. Of course this doesn’t necessarily lead to any solutions soon…

Now I found that my problem is really much worse than it seems to be described anywhere. I have no idea why that is. I just went through the following steps, which seem to reproduce it reliably for me (oh, and I was still running in a VM, but not on the TrueCrypt drive I mentioned before).

Create a new console application project, for .NET 4 Client Profile

Enter a line of code in the Main method:

Console.WriteLine("Hello World");

Hit Ctrl-F5 – no problem, application runs

Add a second line to the Main method (and don’t spend forever typing it — a few seconds are fine though):

Console.WriteLine("Second line");

Hit Ctrl-F5 again and BOOM — MSB3021 comes up

C:WindowsMicrosoft.NETFrameworkv4.0.30319Microsoft.Common.targets(2868,9): error MSB3021:
Unable to copy file "objx86DebugConsoleApplication1.exe"
to "binDebugConsoleApplication1.exe". The process cannot access the file
'binDebugConsoleApplication1.exe' because it is being used by another process.

I have to say, this is a really big problem for me, because in presentations I regularly do quick change/run cycles. This is impossible right now and I have still not found a workaround for it. Maybe I should put up the steps above on Connect separately — may do that later. Any feedback?

Update: Just one thing — for a while there I thought I had found a workaround, which is that when I run in the debugger (F5 instead of Ctrl-F5), I don’t get exactly the same behaviour. But then I found that with an actual test project instead of the tiny one described above, I was seeing very odd behaviour with F5 as well — many times the application would simply not be run when hitting F5, without any message. I suspect that in these cases the same problem came up in the background somehow, but VS didn’t show me what happened.

Update 2: Second update — I don’t want to waste anybody’s time! I found a temporary workaround for now with an older VM snapshot. There must be something weird going on with my current VM, which results in files being inaccessible (although Process Explorer doesn’t show the file being in use) for a while. I’ll look into this more later, not enough time now. (And no, I’m not even using a virus scanner. Nothing that comes to mind really. It’s all very odd :-))

Still too much to do to look into this in more detail, but for those of you who have similar issues, I thought I should post a solution I’m using right now. Quite simply: run VS as Administrator. Yes, that’s it. The problem, whatever it is, only comes up when running as a non-Admin user.

I saw the following funny behaviour though. I ran VS as a normal user, created a test app, ran it, changed it – the error came up. Then I restarted VS as Administrator and opened the same project, tried to build, and the same error came up! So it seems once the error is there for a project, being Admin doesn’t help. But being Admin from the start prevents the issue from coming up in the first place.