VS 2k8 Doesn't Release File Handle After Debugging Stops: Unable to copy file X to output directory because it is being used by another process.

Question

Every once in a while, typically when I stop debugging in our UI assembly, I get the following error which requires a restart of Visual Studio 2008 and it's killing my productivity:

Error 13 Unable to copy file [UI assembly] to [output directory]. The process cannot access the file [output directory][UI assembly] because it is being used by another process.

After restarting, I get this error:

Error 1 Metadata file [utility function assembly in RELEASE folder] could not be found.

I find this really, really odd because we never use the Release configuration.

I'm using VS 2k8 SP1 on Windows Vista.

I know that it's the VS debugger that's not releasing its file handle by using the handle utility (formerly from Sysinternals). The process is devenv.exe.

I've tried closing and reopening the solution. Didn't work. Only a full VS2k8 restart works.

I've tried adding a pre-build event, to move the file as described here, but that doesn't work because Windows can't delete the file for the same reason it can't replace it: it's got an open handle.

I even tried manually closing the handle using the handle.exe util described above, then trying the pre-build event. Visual Studio apparently doesn't know its handle has been closed because the VS build fails, but handle.exe shows no open file handles on the file in question.

For the record, here are the add-ins I run:

• ReSharper 4
• Smart Paster 2008
• Typemock Isolator
• TestDriven.NET 2.13.2184

I also use Developer Express controls for this project, so that may have something to do with it as well.

Answer 1

I've had similar problems in VS2005 and VS2008 without any add-ins installed or any third-party controls in the project. The only solution I've found is to close Visual Studio and reopen it. It is a very intermittent problem and while annoying, one that it seems can't be resolved on your end.

Answer 2

There is Unlocker tool that might help you somewhat in the trouble.

Answer 3

We had a similar problem with VS2002 when building our projects. We fixed it when we moved up to VS2005 by building our application into a common build folder (i.e. {SolutionRoot}\Build).

Answer 4

I've begin to notice that it seems to be more likely to occur (and maybe only occurs) when doing a method that's called during Application.Idle.

Answer 5

You could try this pre-build event script:

if exist "$(TargetPath).locked" del "$(TargetPath).locked" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"

Some folks have reported that it fixes the problem.

UPDATE:

Do you by any chance have this in your .config (or machine.config?):

<hostingEnvironment shadowCopyBinAssemblies="false"/>

It seems this will create (or maybe just exacerbate) the original "unable to copy" during build issue. Of course, I only added that setting to my project because I was getting an error when debugging about ASP.NET being unable to shadow/copy the DLLs. However, in hind sight, that issue is quite a bit easier to deal with than the locking problem. With the shadow/copy issue, you just need to build and then wait a few seconds. It's slightly annoying, but certainly less of a problem than having to restart Visual Studio every time you want to do a build!

Answer 6

This seems to be fixed by changing the output name of the assembly to match the default namespace, for some reason.

I found this workaround via https://connect.microsoft.com/VisualStudio/feedback/Workaround.aspx?FeedbackID=114694. The pre-build script option works, but only if the assembly already exists. If you do a clean/build, it won't work.