File Lock Issue in Visual Studio When Building a Project
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.
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.
[advertisement] Axosoft OnTime 2008 is four developer tools in one: bug tracking, project wiki, feature management, and help desk. It manages your development process so developers can focus on coding. Installed or Hosted – Free Single-user license -- Free 30-day team trial.
10 Comments : 04.18.08
Feedbacks
Pingback from Reflective Perspective - Chris Alcock » The Morning Brew #77
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?
During out of process debugging occasionally the pdb file becomes locked and prevents builds from finishing
Thanks, but I've had your code in my build event for quite a while and it doesn't work.
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
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.
It works 90% of the time, thank you!
Works well with XBAP's as this issue was aging me.
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!!!
#1
Dew Drop - April 19, 2008 | Alvin Ashcraft's Morning Dew
04.19.2008 @ 8:17 PM
Pingback from Dew Drop - April 19, 2008 | Alvin Ashcraft's Morning Dew