Reputation: 2049
I'm using VS 2008. When ever I make a change in my code and try to compile I get the following error:
Error 7 Unexpected error creating debug information file 'C:\Documents and Settings\jbezanson\My Documents\MyProjects\DispatchBoard\DispatchBoard\obj\Debug\DispatchBoard.PDB' -- 'C:\Documents and Settings\jbezanson\My Documents\MyProjects\DispatchBoard\DispatchBoard\obj\Debug\DispatchBoard.pdb: The process cannot access the file because it is being used by another process. ' DispatchBoard
Using Process Explorer, it is always devenv.exe
that is locking the file. If I run in Release mode this does not happen. It started 2 days ago when I started a WPF application, and since then it happens with every application I work on.
The only info I could find from Google was referring to a bug in VS 2003.
Anyone else have this problem? How do I fix it? It is getting very annoying having to kill the file handle every time I want to compile.
Upvotes: 22
Views: 24727
Reputation: 299
The only thing that worked for me is to remove the optimizeCompilations="true" attribute from on the compilation element in my Web.Config file.
Compilation time may be a little longer, but it worked well.
Upvotes: 4
Reputation: 25628
This problem started occurring for me after changing from Cassini to IIS Express as my platform for debugging.
Cassini was much better than IIS Express but doesn't properly support the Integrated pipeline. IIS Express is hopeless.
This seems to be some sort of race condition in Visual Studio or IIS Express. It is nothing to do with one project locking another project - the locks are coming solely from the activity of the web application's build process.
Anyways, none of the above solutions worked for me. Unlocker doesn't seem to be supported for Windows 8 anymore. So instead I tried LockHunter. What I do is keep the LockHunter app open all day. If I get a complaint about some file being locked I copy and paste the file path into LockHunter then try again. This usually sorts out the problem but sometimes takes a few attempts.
Upvotes: 0
Reputation: 21
I also had the same issue. Tried all the suggestions above with no luck. I eventually change the Build Configuration from Debug to Release, the solution built...
Upvotes: 0
Reputation: 1
I had the same issue from time to time. Usually no problem but once in a while... This particular time, it was impossible to work. I would shut the application down, and even that didn't work most of the time. I saw this post and a person said they had no issues until they started a WPF application. I was playing music (radio station) in the background with Windows 8 "Music" app. I had the idea that it was a Microsoft App built with Visual Studio. Once I stopped playing music, I never encountered the error. If you are reading this, see if you have any Microsoft apps running.
Upvotes: 0
Reputation: 31
To avoid that problem just open the project properties, go to Debug tab an untick "Enable the Visual Studio hosting process"
Upvotes: 3
Reputation: 689
Not need to restart or delete the file.Deleting will not be possible , you will get error message. Just rename the file and that is enough. VS2010 will create another file for you as it wont find the origional. :)
Upvotes: 0
Reputation: 891
This works for me with web projects in Visual Studio Express 2012 for Web:
Upvotes: 1
Reputation: 11
Right Click The Folder that contains debug .pdb and uncheck the folders read-only propertys then ok. thats it.
Upvotes: 1
Reputation: 1
Old topic, but something that worked for me. I had 2 projects in my solution, a class library type project and a windows form project. The windows form project was referencing the compiled binary and not the project itself in my case which was causing the lock. After changing the reference to the class library project, it worked properly.
Upvotes: 0
Reputation: 191
If you have multiple instances of VS open, close other instances (apart from the one you are trying to compile) - this may resolve the issue.
Upvotes: 19
Reputation: 491
This worked for me. What I done was that close my visual studio and delete the .suo file and then re-open the solution. The locking should be disappeared now. Cheers.
Upvotes: 0
Reputation: 184
I changed the 'StartUp Project' of my solution to a project without reference to the locked file's project. This solved the issue for me using VS 2010 SP1.
(Process Explorer said msvsmon.exe (started by devenv.exe) locked the pdb file. After changing the startup project the processes msvsmon.exe and .vshost.exe disappeared and so did the file handle.)
Alex Clark, thank you for pointing me in the right direction.
Upvotes: 4
Reputation: 21
I had this issue today. In my case, I had just grabbed the data from my company's source control and instantly hit this issue when I tried to compile the project. The issue ended up being that the \bin folder was set to Read Only. To solve the issue, I just made the folder not Read Only.
Upvotes: 2
Reputation: 900
When I have problems with locked files, I use Unlocker. (If you tried everything and it's not working, try this ;)
In case of broken link, here's a mirror.
Upvotes: 9
Reputation: 51
I had the same problem this morning and noticed that I had another project open that had a reference to the one that would not compile or debug. I removed the reference (as I didn't actually need it) and it was fine.
Upvotes: 4
Reputation: 11
I just came across the same problem today. And then I realized what went wrong: I had couple of Visual Studio windows opened at the same time, and one of them was in debug mode.
When I stopped debug mode in that one, the problem was solved.
That happens when you have a "fistfull of VS windows" opened.
Upvotes: 1
Reputation: 36082
Since you say you have it on all applications you work on it sounds like a more global problem. You could try and reinit the vs2008 by writing
devenv.exe /setup
Edit: link to command line options
Upvotes: 0
Reputation: 34401
I have solved a similar problem by adding these lines as a pre-build event:
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" move "$(TargetPath)" "$(TargetPath).locked"
With proper modifications, it might help your problem.
Upvotes: 0