Yes, I've seen this previous question here and none of the solutions have worked.
On Visual Studio Community 2019 I was debugging a project that I've been working on for years. I have a common library project, that I've built, that I use on multiple solutions - one web, one exe.
In working on the EXE solution, which is one windows app project + about half a dozen other custom libraries, I was debugging along without issue. Changed a bit of code and then started another debugging cycle and suddenly symbols couldn't be loaded for one of the libraries.
If I look in the output folder, the PDB file for the library IS there. If I look in the Debugging Windows... Modules, the library does NOT show up.
If I load up the web project which also uses this library, it debugs fine and the module shows up in the modules window.
I've tried everything in the thread I've referenced above. I've also tried:
Build, Clean, rebuild, in all sorts of different orders - the PDB is ALWAYS there.
Removing and readding references to the project from the EXE
Creating a whole new solution
Going to a different PC entirely - one that I knew was working yesterday - grabbing my latest code, and still the same problem.
Reverting back to several different old branches of code, on BOTH the new machine and the old machine, same issue.
Installing VS updates
Repairing VS
Checking my GAC to make sure there was nothing for these libraries in there
Played with every project setting I could find
Cursing and praying to the programming Gods
I have no clue what to do next. Obviously this one specific project is not loading the DLL, but I can't figure out any possible reason why. The only thing that changed between a successful debug and the missing symbols error was me changing a few lines of code and clicking Run again. (And I even removed the code changes and it still failed.)
I just don't understand what could have caused this, for this singular library, on this single solution.
To anyone who finds this later, I've solved the problem and my code is debugging fine again.
And I have zero clue about what changed, why it started working, or if I even did anything at all. I came back to it the next day, systematically started working through various tests, and suddenly everything was fine - though I didn't do anything differently than the day before.
These are the times that try men's souls.
Recently, whenever I change something in my code, rebuild, and attempt to debug, I get the error "This breakpoint will not currently be hit, No symbols have been loaded for this document."
But then as soon as I restart my computer, everything is fine and I can debug properly. Why is this happening? It's really frustrating having to restart my desktop every time I try to debug my code. I've looked all over stack overflow and MSDN and can't find any solution to my particular problem. Any help is appreciated
"This breakpoint will not currently be hit, No symbols have been loaded
for this document."
(As for this error message, it's common error which has different causes. I can't give the most direct correct answer for this issue, I can only give you some tips for trouble-shooting. In order to avoid losing contact in the round-trip comments, I post those content as answer instead of comments.)
Since VS2015 have been released for long time, I would think this issue is a particular one, not found similar issues online.
First of all, please create a new simple project to check if this issue occurs in new project when debugging.
If it persists in new project, I think this issue has something to do outside environment like VS settings, VS config files or Debug options.
You can try:
1.Go Tools=>Import and Export Settings=>Reset all settings =>No,just reset settings=>Finish
2.Repair VS IDE since it seems to work well in the past, and just got the issue recently, so maybe something is broken for your IDE(In Control Panel find VS2015, right-click=>change=>repair). Also, make sure you have the latest VS2015 Update3 instead of earlier versions.
And if it works well in new project, then maybe the issue is about the whole project or solution itself. You can try:
1.Navigate to solution folder, close all vs instance, delete the .vs, bin and obj folders and restart VS to check if it helps.
2.Make sure you've loaded the required symbols, check the content in your Modules window during debugging, there's possibility you don't load necessary symbols successfully.
3.Check the output folder after your rebuild, check in folder like bin\debug folder if you have both the .exe and .pdb files. And make sure the .exe and .pdb files are up-to-date after your rebuild by checking their Date Modified.
Hope it helps and more info about the project type, dependencies would be better:)
When I debug my project, I get following error:
"Unable to copy file "obj\Debug\My Dream.exe" to "bin\Debug\My Dream.exe". The process cannot access the file 'bin\Debug\My Dream.exe' because it is being used by another process."
Using Process Explorer, I see that MyApplication.exe was out but System process still uses it although I stopped debug before.
Whenever I change my code and start debug it is going to happen. If I copy project to USB and debug, it runs OK.
Why? How can I fix this error?
I use Window 7 Professional. With Xp I have never got this error.
Ugh, this is an old problem, something that still pops up in Visual Studio once in a while. It's bitten me a couple of times and I've lost hours restarting and fighting with VS. I'm sure it's been discussed here on SO more than once. It's also been talked about on the MSDN forums. There isn't an actual solution, but there are a couple of workarounds. Start researching here.
What's happening is that VS is acquiring a lock on a file and then not releasing it. Ironically, that lock prevents VS itself from deleting the file so that it can recreate it when you rebuild the application. The only apparent solution is to close and restart VS so that it will release the lock on the file.
My original workaround was opening up the bin/Debug folder and renaming the executable. You can't delete it if it's locked, but you can rename it. So you can just add a number to the end or something, which allows you to keep working without having to close all of your windows and wait for VS to restart. Some people have even automated this using a pre-build event to append a random string to the end of the old output filename. Yes, this is a giant hack, but this problem gets so frustrating and debilitating that you'll do anything.
I've later learned, after a bit more experimentation, that the problem seems to only crop up when you build the project with one of the designers open. So, the solution that has worked for me long term and prevented me from ever dealing with one of those silly errors again is making sure that I always close all designer windows before building a WinForms project. Yes, this too is somewhat inconvenient, but it sure beats the pants off having to restart VS twice an hour or more.
I assume this applies to WPF, too, although I don't use it and haven't personally experienced the problem there.
I also haven't yet tried reproducing it on VS 2012 RC. I don't know if it's been fixed there yet or not. But my experience so far has been that it still manages to pop up even after Microsoft has claimed to have fixed it. It's still there in VS 2010 SP1. I'm not saying their programmers are idiots who don't know what they're doing, of course. I figure there are just multiple causes for the bug and/or that it's very difficult to reproduce reliably in a laboratory. That's the same reason I haven't personally filed any bug reports on it (although I've +1'ed other peoples), because I can't seem to reliably reproduce it, rather like the Abominable Snowman.
<end rant that is directed at no one in particular>
I've had this error crop up on me before, even in Visual Studio 2008. It came back and more prevalent in Visual Studio 2012.
Here is what I do.
Paste this in the troublesome project's pre-build event:
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
Computer (right-click) -> manage -> Service & Application -> service -> Enable Application experience
Worked For me!
I had the same issue in Visual Studio 2013. I'm not sure what caused this for my project, but I was able to fix it by cleaning the solution and rebuilding it.
Build > Clean Solution
Build > Rebuild Solution
I understand this is an old question. Unfortunately I was facing the same issue with my .net core 2.0 application in visual studio 2017. So, I thought of sharing the solution which worked for me. Before this solution I had tried the below steps.
Restarted visual studio
Closed all the application
Clean my solution and rebuild
None of the above steps didn't fix the issue.
And then I opened my Task Manager and selected dotnet process and then clicked End task button. Later I opened my Visual Studio and everything was working fine.
At least in my case I've noticed that visual studio 2012 was creating at least two msbuild.exe ghost processes, which did not perish after build. These zombies apparently are causing file locks to appear.
Killing msbuild.exe's is one time solution, it needs to be done per build basis.
But then I've figure out that I could disable parallel build once and for all - went into Tools > Options > Projects and Solutions > Build and Run > "maximum numbers of parallel project builds" - by default it has value of 8, I've switched to 1. Works like charm.
Of course builds are bit slower now, but better safe than sorry.
At least for this particular small project I did not need more than one build thread.
See my answer here if you're having this problem while running unit tests. Answer copied below:
Building upon Sébastien's answer, I added a pre-build step to my test
project to automatically kill any vstest.* executables still
running. The following pre-build command worked for me:
taskkill /f /im vstest.*
exit 0
The exit 0 command is at the end to prevent build failure when there
are no vstest.* executables running.
I solved this problem..
near the debug you see drop down menu with some configuration. Default there was Any CPU. Select x86 and run the program it will work. If x86 not there go to configuration manager and add the x86
Recently I've been in a trouble with Visual Studio 2012 with same error description: "The process cannot access the file because it is being used by another process..."
To fix this first of all you need to understand the application which still use it. I've shutdown all processes like "MSBuild" and "MSBuild host". But this is not enough. If you have installed "Code Contracts" and turned on then it sometimes takes your DLLs for checking and hanging up on this operation.
So, you need to stop all processes of "CCCheck.exe" and that's all.
Finally, to understand that process is using your DLL you always may try to just Delete "obj" folder in your File Manager and this operation will fail, you may see the "Message Window" with description of the hanging operation. Also, as a variant, you can try to use "Sys Internals Suite" application.
Worked for me.
Task Manager -> Name of project -> End task. (i had 3 same processes with my project name);
VS 2013; Win 8;
Make sure that any previous run of the application (for example, start without debugging option) is actually stopped. I was working on a WPF application, started without debugging and had it minimized when I kept getting the error. After closing the application VS behavior got back to normal.
I have been plagued by this issue in Visual Studio 2017. It started about two or three weeks ago, and has severely eaten into my productivity. Clean and Rebulid haven't worked; even restarting my machine doesn't do the job.
One way to deal with the issue is to clean the offending assembly, and to build (as opposed to rebuild) the project you want to run immediately afterwards. This works about 30% of the time.
However, probably the most reliable solution I've found is to open a Developer Command Prompt, and use msbuild directly. I've been doing this for the last three days, and so far the problem hasn't happened once.
In my case was that I have enable "Show All Files".
Visual Studio 2017
Run taskmanager.
Locate netcore and delete it.
You can then delete the file manually or by running Clean.
This is pure speculation, and not an answer.
However, I have been having this problem for a while.
I came after a time to suspect an interaction between VS and my AV precautions.
After some playing, it seems that it may have gone away when I modified my antivirus so that everything under the
C:\Users[username]\AppData\Local\Microsoft\VisualStudio\10.0\ProjectAssemblies
folder was not included in the real-time protection.
It looks as if the build actually writes the DLL here first, then copies it to the final build location.
It could be too late. But, I encountered similar problem and in my case the project had self reference. Hence, deleting it from the References worked like a charm!!!
I've found the quickest way without closing forms or restarting VisualStudio is go to the project's compile page and click "Advanced Compile Options..." button. Then make any change to one of the options (say, changing Generate Debug Info from Full to pdb-only), then click OK.
It works every time and will have to do until MS fixes this bug (I've never had this problem until I switched from VS2012 to VS2013)
Another note, if you can't clean the project or solution, it won't build. The files are definitely locked by VS (not a antivirus problem, at least not in my case)
I tried all these suggestions as well as other suggestions found elsewhere and the only thing that worked for me was restarting my computer. Then I did a clean solution followed by rebuilding. I am using Visual Studio 2013 for reference.
I have run to this same issue, and what I found is there are actually running mulitple Windows form application in the background. It happens when your application has two forms and you close the 2nd form which is not your main form so the application will not totally exited.
I usually run my application
through its exe or
run without debugging
Solution is close the other instance of Windows form application.
This is one way to always close your application instance.
Pre build command
(if exist "$(TargetDir)*old.pdb" del "$(TargetDir)*old.pdb") & (if exist "$(TargetDir)*.pdb" ren "$(TargetDir)*.pdb" *.old.pdb)
Helped
[Solved] Error: Cannot access file bin/Debug/… because it is being used by another process:
I am approaching that you get this error while you was trying to run two windows form one after another such as first loading a form then after sometimes it will automatically disappear and the second form loaded onto the screen.
Basically, you need to close your first form which is running in the background and the main reason behind this error.
To close the first form you have to add these two lines of code in the second form load event handler.
Form1 form = new Form1();
form.Close();
This will solve the error perfectly.
One simple solution is you go to bin\Debug folder, delete all the files in that folder, then rebuild. If it doesn't work, close Visual Studio then go to bin\Debug folder using file explorer, on the left coner, click on File> Open Command Prompt> Open Command Prompt as Administrator > Enter this command "DEL /F /Q /A *" > then rebuild
i found Cody Gray 's answer partially helpful, in that it did direct me to the real source of my problem which some of you may also be experiencing: visual studio's test execution stays open by default and maintains a lock on the files.
To stop that predominantly useless behaviour, follow the instructions from https://connect.microsoft.com/VisualStudio/feedback/details/771994/vstest-executionengine-x86-exe-32-bit-not-closing-vs2012-11-0-50727-1-rtmrel
Uncheck Test menu -> Test Settings -> "Keep Test Execution Engine Running"
My problem was dotnet got hung up and whenever VS would try to make a new dll, or access an old one, the dotnet process would latch onto the dll and stop visual studio from cloning the dll. Solution is just to end all dotnet tasks in task manager(it will only actually remove the dead one, if you are trying to end one and it won't shut down, that means it's working).
Close VisualStudio, ctrl-alt-delete, select Task Manager, find and end all MSBuild processes - VisualStudio basically has a pretty severe bug where it loses control of its debugger and the debugger maintains a lock on the .pdb file in the debug/bin folder. After you end all the MSBuild (debugger) processes, delete the /debug/bin folder and reopen your solution in Visual Studio. You're good to go now. Microsoft needs to fix this crap.
I have opened a separate question regarding VS 2017 that had a similar behavior after one update. The problem seemed to be generated by the antivirus program although.
I have added the bin folder to the antivirus exclude list, restarted the machine and now it seems to work.
I have faced the same issue, but none of the answers above helped me! I just simply closed my Visual Studio 2017 then re-run it, and It worked!
I've tried every answered here and this worked for me
Close your Project.
Stop running tasks in task manager
Restart your pc
Open and build project again
it worked for me.
I got this error because I was running my solution, but not in debug mode. I had forgotten this. I realized it and stopped my solution from running. This cleared up the issue.
Another kludge, ugh, but it's easy and works for me in VS 2013. Click on the project. In the properties panel should be an entry named Project File with a value
(your project name).vbproj
Change the project name - such as adding an -01 to the end. The original .zip file that was locked is still there, but no longer referenced ... so your work can continue. Next time the computer is rebooted, that lock disappears and you can delete the errant file.
As you can notice
Symbols are been correctly loaded.
I just created a view GetCompanies.cshtml using the AddView shortlink
But, no matter what I do, I can't debug in the View.
What I did so far:
Close and Open Solution
Close and open Visual Studio
Shutdown all ASP.NET Development Server's
Deleted all Symbol Libraries .pdb
Clean Solution
Re-Build Solution
did not (yet) shutdown Windows 7 x64 :-/
Sometimes if you have a hard stop, Visual Studio temp cache will be screwed.
Clear the cache by deleting these folders:
C:\Windows\Microsoft.NET\Framework\<.net version>\Temporary ASP.NET Files\(ApplicationName)
C:\Windows\Microsoft.NET\Framework64\<.net version>\Temporary ASP.NET Files\(ApplicationName)
I am finding the same behavior from time to time when debugging silverlight. My solution is to clean the browser's cache (on latest IE click on the wheel button, Developer tools), as it sometimes will cache the binary files and not load the new ones.
Perhaps is could be the same with your views?
Been messing with this problem for a couple hours trying everything above. I finally changed my Target Framework to .NET Framework4.5 and it all started magically working.
This is always weird. I just had this problem and solved it with a full rebuild of the entire solution.
There was also another strange symptom, though: a new unit test that I had written using NUnit, mocking with NSubstitute, wouldn't pass because NSubstitute wasn't returning what I wanted it to return. I lost a few minutes trying to figure out if I did something wrong programming NSubstitute, then when I tried to attach the debugger to the NUnit GUI I saw that warning.
That's when I decided to do a full rebuild of the solution, and that worked for me.
So I guess the lesson to be learned is "before smashing your head against the wall, try a full rebuild".
For me, I somehow switched my target build to Release instead of Debug
Remember that views are actually compiled when you request the page (by default).
This means when you set a breakpoint in a view:
It shows the "No Symbols" error. This just means the view isn't
compiled yet.
It shows the breakpoint fine. This just means
that it found SOME compiled version of the page. Like the LAST working version...
So basically its not meaningful information to look at what it says when you mouseover the breakpoint in a view (at least in this regard)
If you are trying to debug this page, then you have a problem. Look at what the debugger is outputting to your BROWSER instead and fix that first. I think we'll be surprised about how many people are going to facepalm at this.
I had this problem with SL5 project (VS2012). And to fix this, I was needed to set "Silverlight" option enabled in %MyProjectName%.Web project properties, under Web tab.
In my case, the .PDB file was hosed (from which the symbols are loaded) in VS 2012, so performing a Clean and Build reconstructed the .PDB file and everything started workign again.
I was attempting to debug a deployed WCF windows services (compiled in Release mode) and had the exact same issue. Give this a shot...
Save All. You may even want to try to clean the solution
Rebuild all and install or deploy
BEFORE starting the service (or exe) I copied the .pdb files over to the install folder
Start the service (or exe) and attach the debugger to the process
Worked like a charm (finally) for me.
delete bin and obj directories
run solution again.
Note: Unless that cshtml loads at runtime the symbols are not loaded. On page load that breakpoint will be hit. So wait till control goes to that page
I have a solution in Visual Studio that is comprised of 5 projects. The projects build to assemblies (.dll). I have the output path of each project set to \my-web-server\wwwroot\bin, which works fine on one project. In the properties for all of my projects, I have the output path set to the same directory, but when I try building all but one of the projects, I get the error:
Unable to copy file "obj\Release\Index.dll" to "\my-web-server\wwwroot\bin\Index.dll". Access to the path '\my-web-server\wwwroot\bin\Index.dll' is denied.
I assume it could be an issue with permissions, because my organization keeps things locked down, but I have no control over granting permissions. Any help in the right direction is much appreciated.
It must've been something silly. I deleted the .dll manually, then rebuilt. Looks like everything's working normally. Thanks.
The solution for me was to delete everything in bin and obj folders in every project. Just ran this powershell script as described here.
I had the same issue. A copy of Visual Studio (devenv.exe) was still running invisible in the background keeping the particular dll locked.
Delete all DLLs from the bin folder and build the solution.
just had the same issue, built a new project/solution, got it all working and then added to TFS.
Unfortunately I did not clean the build before adding and this meant some files that should not have been under source control were and were then read only(not checked out).
Manually deleting the files before rebuilding fixed the issue.
Most likely a program is running using that library.
This happens to me when running something to debug, and I forget to close it (not attached to IDE debugger).
And since this looks like a website, it is potentially due to the website being hosted from the development build folder, and someone is accessing it.
Similar to what Aequitarum said, it's mostly likely a locked file because it's in use. Since you have multiple projects, you mostly likely have references between them. And since you have all the projects outputting to the same folder any of the referenced projects will most likely get copied more than once if you have those files set to be deployed in the child project. (In a C# web application, you can view the properties of the reference and look at the "Copy Local" property.) And if you have the MsBuild project set to use multiple processors for the build, two child projects are both trying to copy the file at approximately the same time and one is erring out.
It's a very unique situation, but it is possible.
Working solution
Just go to Task Manager and search Detail (if its Win10) and search with your application name (for easy search just look at your windows user id wise)
And right click shows properties. just give the permission like Administrator access.
That's all its working fine for me. ( I was struggling for 1 week and its killed more my time)
It looks like WSearch Service locks up the files and does not release them. I disabled the service on WINDOWS 10 and was able to rebuild the solution.