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:
- 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):
- 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 :-))