Error Creating Debug Information - Code Won't

问题:

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.

回答1:

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.

回答2:

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.

回答3:

Have you tried closing VS, deleting obj folder then restarting VS?

回答4:

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.

回答5:

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.

回答6:

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.

回答7:

To avoid that problem just open the project properties, go to Debug tab an untick "Enable the Visual Studio hosting process"

回答8:

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.

回答9:

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.

回答10:

Right Click The Folder that contains debug .pdb and uncheck the folders read-only propertys then ok. thats it.

回答11:

This works for me with web projects in Visual Studio Express 2012 for Web:

1. Press F5 to begin debugging
2. "Do you want to execute last successful build?" - hit YES
3. At this point you could try a request - not sure if this step is necessary
4. Hit the stop button
5. Recompile successfully

回答12:

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.

回答13:

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

回答14:

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.

回答15:

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.

回答16:

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. :)

回答17:

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.

回答18:

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

回答19:

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.