File Lock Issue in Visual Studio When Building a Project

Musings of a Ph.D. student in Computer Science

File Lock Issue in Visual Studio When Building a Project

Published on April 20, 2008

One of the common issues for Visual Studio users is a file lock error when trying to build projects.

This is a generic error for all developers but is more common among Visual Studio Extensibility developers who try to build add-ins and debug them. I see that a newbie has to wrestle with this issue when developing an add-in.

Here I just want to show one of the several ways to work around this issue and of course, want to talk about a simple and easy to use solution. This has been a question for a few readers of my book and would be worthwhile to be mention here.

First let me describe the issue in more details. Sometimes when you try to build a project in Visual Studio, you get a build error that specifies that Visual Studio is unable to copy your new assembly file. The error text is something like this which usually comes with a warning with same details:

Unable to copy file "obj\Debug\MyAddin1.dll" to "bin\MyAddin1.dll". The process cannot access the file 'bin\MyAddin1.dll' because it is being used by another process.

And here is the snapshot of the error:

The reason to see this issue is your assembly is locked by one of the previous processes so Visual Studio is unable to delete the previous assembly and copy the new one so your build process fails.

There are several ways to reproduce this issue but I'm sure that you'll experience it after writing 2-3 add-in projects.

But how to solve this? There are various ways based on your project type but one simple solution that I recommend to Visual Studio add-in developers is to add a simple code to their project's build events.

You can add following lines of code to the pre-build event command line of your project.

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

To add this code, you need to get access to your project properties and then open the Build Events and add the code as is shown below.

Modify Build Events

This simply solves the issue. But how does this code work? It simply copies the locked file to a new location and lets your build process to be followed.

21 Comments

Fahrenheit Marketing is your resource for Search Engine Optimization in Austin.

Dew Drop - April 19, 2008 | Alvin Ashcraft's Morning Dew
Apr 19, 2008 8:17 PM
#

Pingback from Dew Drop - April 19, 2008 | Alvin Ashcraft's Morning Dew

Reflective Perspective - Chris Alcock » The Morning Brew #77
Apr 21, 2008 1:57 AM
#

Pingback from Reflective Perspective - Chris Alcock » The Morning Brew #77

Mike Heath
Apr 22, 2008 8:30 PM
#

Why is this STILL a problem on Windows? Linux, OS X, and other Unix like operating systems don't have this limitation. Why are we stuck with a second class file system in Windows?

Bit lock during out of process debugging workaround
Aug 04, 2008 10:44 AM
#

During out of process debugging occasionally the pdb file becomes locked and prevents builds from finishing

Tim
Aug 28, 2008 9:04 PM
#

Thanks, but I've had your code in my build event for quite a while and it doesn't work.

Nasser
Sep 22, 2008 9:31 AM
#

Thank you for your solution!

I am not building an Add-on, but had been getting this error for a while. I thought for a while that this might be caused by a cyclical reference, but found none. Your code nippet solved the problem.

Best regards

zobidabee
Nov 17, 2008 2:47 PM
#

you cannot move or rename a file if it's already used by another process... If you create an Addin, you need to unload it from your IDE, then quit all visual studio instances, then reload your addin project.

the reason is quite obvious, once you built your addin and added it to one instance of VS, it has been loaded, so you need to unload it if you want to rebuild it. but you may encounter a strange (for me) behaviour:if you didn't close your AddinSolution, you open another IDE, create a solution which will instanciate your addin classes, during the first load you can rebuild as many times as you want... but once your addin solution is closed, you open it for fixing some lines then you encounter the problem.

Ty
Apr 01, 2009 4:42 PM
#

It works 90% of the time, thank you!

Haggis
Apr 23, 2009 9:10 AM
#

Works well with XBAP's as this issue was aging me.

aj
Jun 25, 2009 5:09 PM
#

Hey this solved my long-standing issue! One of my class library projects would do this whenever I made a change and re-build the UI project referencing it.

I no longer have to exit VS and re-open

Thanks!!!