6

Visual Studio Express 2013 for web has been throwing this error a lot lately when I try to run my project, and the only resolution I have found is to quit and relaunch Visual Studio or (sometimes) completely restart Windows. What could cause something like this?

Full Error Dump

Error   19  Could not copy "obj\Debug\HobbsEventsMobile.dll" to "bin\HobbsEventsMobile.dll". Exceeded retry count of 10. Failed.    HobbsEventsMobile
Error   20  Unable to copy file "obj\Debug\HobbsEventsMobile.dll" to "bin\HobbsEventsMobile.dll". The process cannot access the file 'bin\HobbsEventsMobile.dll' because it is being used by another process.   HobbsEventsMobile
drewwyatt
  • 5,989
  • 15
  • 60
  • 106

4 Answers4

8

Create a pre-build action in your project by going to project properties (right-click on the project in the solution explorer, and select the Properties option), select the Build Events tab. Add this code:

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

https://social.msdn.microsoft.com/Forums/en-US/5b71eb06-5047-483d-8fd3-b75c102d41e9/unable-to-copy-from-objdebug-to-bindebug?forum=Vsexpressinstall&prof=required

Rolwin Crasta
  • 4,219
  • 3
  • 35
  • 45
6

1-Select Your Project

2-Go to view from view select property Page

3-make Sure That The Output path is empty like That

enter image description here

Prafulla Kumar Sahu
  • 9,321
  • 11
  • 68
  • 105
Abdo
  • 61
  • 1
  • 1
  • 1
    Mapping Output path to obj\Debug\ seems to work better because the assemblies don't get dumped into your root folder. – Mike Kuenzi Jun 05 '19 at 15:55
5

The clue appears to be in the error message: 

cannot access the file 'bin\HobbsEventsMobile.dll' because it is being used by another process

I would guess that the dll is still being used from a previous debug session. Can you kill the process that owns it? If you're not sure which process that is then run Process Explorer and do Find on the dll name -- that will show the process that still has the dll open.

Another wild guess: did you run outside the debugger with Ctrl-F5? If so then that may also explain why the dll is still in use.

the_mandrill
  • 29,792
  • 6
  • 64
  • 93
  • I am not at work right now, but one other thing I noticed today that (as well as making my life easier) may help is that running "clean" on the solution seems to fix the problem. I have to clean **every time** before I start the debugger again, but this is definitely bearable. – drewwyatt May 07 '14 at 04:25
  • Great! I had to restart my PC constantly. – Tassisto May 03 '16 at 11:30
  • Couldn't find the process in Task Manager, only in PE. It may help to know that PE and other troubleshooting utilities have been rolled up into a single suite of tools: https://learn.microsoft.com/en-us/sysinternals/downloads/sysinternals-suite – ntrch Jun 02 '19 at 08:53
1

You can also make clean solution and before you buid again, check in debugging folder if the .dll files still there. If the clean solution doesn't work, you can try change the file name and build the solution. You will see those errors disapearing.

jbernardes
  • 13
  • 4