views:

4715

answers:

15

Hey all,

For one of my ASP.NET 3.5 applications, every single time I try to build the web app, it throws the following build errors in Visual Studio 2008:

Error 165 Unable to copy file "C:\InOne\Common\DexProcessor\bin\Debug\DexProcessor.dll" to "bin\DexProcessor.dll". The process cannot access the file 'bin\DexProcessor.dll' because it is being used by another process. InVision2 Error 166 Unable to copy file "C:\InOne\Common\DexParser\bin\Debug\InOne.DexParser.dll" to "bin\InOne.DexParser.dll". The process cannot access the file 'bin\InOne.DexParser.dll' because it is being used by another process. InVision2 Error 167 Unable to copy file "C:\InOne\Common\AlertProcessor\bin\Debug\InOne.Invision.AlertProcessing.dll" to "bin\InOne.Invision.AlertProcessing.dll". The process cannot access the file 'bin\InOne.Invision.AlertProcessing.dll' because it is being used by another process. InVision2 Error 168 Unable to copy file "C:\InOne\Common\InVision.BusinessLogic\bin\Debug\InVision.BusinessLogic.dll" to "bin\InVision.BusinessLogic.dll". The process cannot access the file 'bin\InVision.BusinessLogic.dll' because it is being used by another process. InVision2 Error 169 Unable to copy file "C:\InOne\Common\InVision.Common\bin\Debug\InVision.Common.dll" to "bin\InVision.Common.dll". The process cannot access the file 'bin\InVision.Common.dll' because it is being used by another process. InVision2 Error 170 Unable to copy file "C:\InOne\Data\bin\Debug\InVision.Data.dll" to "bin\InVision.Data.dll". The process cannot access the file 'bin\InVision.Data.dll' because it is being used by another process. InVision2 Error 171 Unable to copy file "C:\InOne\Common\InVision.DataAccessLayer\bin\Debug\InVision.DataAccessLayer.dll" to "bin\InVision.DataAccessLayer.dll". The process cannot access the file 'bin\InVision.DataAccessLayer.dll' because it is being used by another process. InVision2 Error 172 Unable to copy file "C:\InOne\Common\InVision.DataAccessLayer.SqlClient\bin\Debug\InVision.DataAccessLayer.SqlClient.dll" to "bin\InVision.DataAccessLayer.SqlClient.dll". The process cannot access the file 'bin\InVision.DataAccessLayer.SqlClient.dll' because it is being used by another process. InVision2

This just started happening a week ago and is very annoying... I have to go into the web app's bin folder and delete the pdb files and then it'll let me delete the dll's most of the time. Every once in a while it doesn't let me so I have to close Visual Studio and then it lets me delete them. I checked and it's Visual Studio (devenv) that is locking the dll's. Rebooting the machine doesn't help.

This is really reducing my productivity, is there anything I can do to resolve this?

Thanks,

Justin

EDIT:

As mentioned, Visual Studio 2008 (devenv.exe) is the process locking the DLLs.

I noticed something... When it compiles successfully, it's copying all the DLLs into the bin folder, then they are all deleted, then a new set are copied into the bin. When it isn't successfull, the first set of DLLs are copied in, then it fails. So it seems to be using the bin folder for 2 things when it should only be for 1. Does this help??

A: 

Use ProcessExplorer to find out what process has the file open and go from there.

If a process is currently using those DLL, you can't delete and re-write it. You'll have to kill or otherwise stop the process using those DLLs while you compile.

Ben S
A: 

You could download the excellent SysInternals Handle program. This will tell you which processes have a lock on the files concerned.

If it is an external program (e.g. virus scanner/indexer) then this should help. If it just reports Visual Studio (devenv.exe) as the culprit, then it will be of less help!

Rob Levine
A: 

I'm assuming you already know it's VS2008 which is locking the files. You can try running MSBuild from the command line and see if the problems disappear. Unfortunately Visual Studio can keep files locked when it shouldn't, in some hard-to-predict scenarios.

Vinay Sajip
+1  A: 

File locks are just part of working with Visual Studio. There aren't any great ways to get around this problem.

Chris Ballance
Hi guys. To the first two, I already checked and it's Visual Studio that is locking the files. To Chris, how can that be an answer?? Pretty much everytime I build the web project it fails because the referenced project dll's that are being copied to the web bin are in use by Visual Studio. This means that I need to close and reopen Visual Studio in order to build almost every time... this is not a solution! This is not happening in under solutions or project so it's something specific to this one web project, so saying this is just part of Visual Studio is crap...
Justin
Flip the switch on the "copy assemblies locally" option
Chris Ballance
Thanks that gets me close. The only build error left is: "Unable to copy obj\debug\web.dll to bin\web.dll. The process cannot access the file because bin\web.dll because it is being used by another process."
Justin
A: 

There was a specific bug in Visual Studio 2008 which was fixed in SP1 which may be your issue. It occurs when you reference an embedded JavaScript file and causes the problem you are seeing. See here for more details.

Jon
I'm already using SP1, sorry I should've specified that.
Justin
+1  A: 

Hi I'm facing the same issue for a little while. It's very annoying.

I have an easier yet not so efficient solution for the problem. Cleaning the project or solution solves the problem.

I had the same problem with a WinForms application; Cleaning the project indeed solved the issue. Very strange - let's hope that this bug has disappeared from VS2010.
Pierre
+5  A: 

The issue ended up being that in the web.config someone had added:

hostingEnvironment shadowCopyBinAssemblies="false"

After commenting this out, everything started building ok. What a nightmare!!

Justin
A: 

Till Date, I find no solution to the problem below.

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

In my case, I have two projects under one Solution named "Tax2010"

1) Calc and Calc.DLL (contains .cs class files)

2) Tax2010 and Tax2010.DLL (contain .aspx pages along with respective .cs files and other .cs class files)

I have configured both the projects in a way that their respective .dll be copied to one common bin directory placed under Tax2010 directory.

Here is the genral hierarchy of the project.....

Tax2010 Tax2010 Bin Tax2010.DLL Calc.DLL UI ....aspx ....cs CL ....cs ....cs
Calc AK ....cs ....cs

The problem happens whenever I make any changes to .cs file and try to build the project.One interesting thing to note, though, is that I am not running the application through IIS. Its using WebDev.WebServer.Exe. How I am dealing with it right now ? 1) Delete the obj folder and build the peoject. It works fine or 2) CTRL + ALT + DEL - > Task Manager -> Processes -> WebDev.WebServer.Exe - > End Process.

Now I am sick and tired of doing this monotonous job. Please somebody come up with some wow solution. Enough is Enough now.

Rajib Banerjee
make sure it's not set to copy assemblies locally and ensure that shadowcopybinassembles line is removed from web.config
Justin
A: 

I have battled this issue FOR YEARS!

Have you tried adding this to your PREBUILD Event?

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

SEE THIS FOR MORE INFO: http://nayyeri.net/file-lock-issue-in-visual-studio-when-building-a-project

Here's another thread, with more things to try...

h t t p ://social.msdn.microsoft.com/forums/en-US/Vsexpressinstall/thread/5b71eb06-5047-483d-8fd3-b75c102d41e9/?prof=required

Developer22222222
A: 

What worked for me is the following pre-build event:

if exist "$(TargetPath).locked.bak" del "$(TargetPath).locked.bak"
if exist "$(TargetPath).bak" del "$(TargetPath).bak"
if exist "$(TargetPath).locked" ren "$(TargetPath).locked" "$(TargetPath).locked.bak"
if exist "$(TargetPath)" ren "$(TargetPath)" "$(TargetPath).bak"

What I have noticed in my case is that the 2 files are being created and can not be deleted. You can, however, rename them (and they are still in use if you try to delete them). On a next build, the renamed files are no longer in use (lock removed) and they can be deleted, which is what the above script does, after which it can safely rename the new locked files so there will be no problems in generating the build output.

The other pre-build events posted here and in other places did not help me a lot (they worked only for one extra build or only a few before the problem arose again). So now I am currently using the one posted above for my debugging purposes.

Marcel Gheorghita
A: 

Hi there !@ I did had simillar problem solution for me was to look at the *.csproj file and under i found missing file so and below was correct one so i just removed lines and it worked straight away

Marcin
A: 

@Marcin - what the heck did you just say?

Mike
A: 

Removing the following lines from my app.config solved this for me - I'm using VS2010.

<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
          <assemblyIdentity name="nunit.framework" publicKeyToken="96D09A1EB7F44A77" culture="neutral"/>
          <bindingRedirect oldVersion="0.0.0.0-2.5.7.10213" newVersion="2.5.7.10213"/>
      </dependentAssembly>
  </assemblyBinding>
</runtime>
Colin Pickard
A: 

Check if the user dll and the application referencing the dll target the same .NET framework. I had a case where the frameworks were different which caused this problem.

sterimick
A: 

I just wanted to say that this problem started with me today. (VS 2010, C#) I have been working on this program for a month without this problem, now today it started. I start VS, change code, compile and test and quit program. Make another change, compile and BOOM Unable to copy file "obj\x86\Debug\progname.exe" to "bin\Debug\progname.exe" because if is being used by another process.

ProcExp shows only Visual Studio (actually devenv.exe) using this file. There is only one instance of VS running. There are two listing on my debug\progname.exe, one is a Type DLL, the other is a Type handle.

Using devenv /ResetSettings did not resolve anything, but wasted 10 minutes putting everything back to my desired view.

Using the PREBUILD events rename trick mentioned above solves the problem for a couple of changes, but on the next change the "exe.locked" file is locked and cannot be deleted. Then the rename fails.

The debug\progname.exe file name remains locked even after closing the project.

Closing VS, manually delete the files in the debug folder, opening VS and my solution, then Build->Clean Solution seems to work for me, at least its working now after I did all of that stuff.

Hope this helps -rwg

rwg