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.
4 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
#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