I have a single solution containing several projects but am only running two right now.
Project 1 runs as a windows service in Release mode but runs as a console app in Debug mode. Project 2 is an MMC snapin (output type=class library). They communicate via WCF.
TIME A
When I first started debugging yesterday after a fresh build my callstack window showed this:
lines in service...
[External Code]
--Transition from Client to Server --
lines in client...
I could double-click any line to go to that line. I could set breakpoints in either project and they would be hit.
TIME B (Sometime later in the day)
I started seeing flags on breakpoints in the client (project 2) indicating "The breakpoint will not currently be hit. The source code is different from the original version" even though I just rebuilt all projects. I had made a few code changes but (as far as I know) no project or build changes. I did a solution "clean" but that did not help. The call stack still worked the same as during TIME A.
TIME C (Next day--this morning)
I rebooted. I deleted all obj and bin directories. I rebuilt the entire solution and launched hoping a fresh start would improve the situation. Now it is worse. Breakpoints are flagged with "The breakpoint will not currently be hit. No symbols have been loaded for this document." The call stack has deteriorated to showing the client as external code:
lines in service...
[External Code]
--Transition from Client to Server --
[External Code]
If I select show external code in the call stack it lists lines from the client assembly (mixed in with system assemblies of course) but all greyed out. In the Module window (debug >> windows >> module) the client assembly is not listed.
If I select symbol load information from a line in the call stack it shows "cannot find or open the PDB file" for 5 different locations, the most curious one being under my project's obj/Release directory--not the obj/Debug directory--even though my project is set to Debug configuration.
If I select load symbols from a line in the call stack then select the pdb file in either my obj/Debug or bin/Debug directory, it reports "A matching symbol file was not found in this folder".
Configuration manager shows that all projects are set to Debug configuration and all are included in the build.
I have reviewed similar SO questions, which helped me find all the above things to examine, but have not yet found any rhyme or reason to my situation.
How can I save Visual Studio from its delirium and recover my lost symbols?
OK, Visual Studio, as I should have expected, it was me, not you. You have, through thick and thin [clients], continued to show your steadfast support [functions]. Can we still be [virtual] friends? It boils down to a difference in our cultures. I take things at face value; you like to bury yourself in your registry data, ignoring my MMC snapin code that was right in front of you shouting "I'm here, I'm here!".
Sigh.
I'm here.
I mean, just because it did not replace your last relationship with InstallUtil is that any reason to dredge up the past, bringing those long-forgotten bits [of code] to the surface, keeping the dll forever separate from the pdb? Apparently you think so. Aye, there's the rub! I just did not understand you, but now I do.
Oh, yes; now I do.
Related
Sorry if this is a duplicate -- I've looked at this and this and others, but I can't find my problem.
A program I build debugs successfully on my local machine, but when I try to debug it remotely, I can't set breakpoints in my code. I've opened the modules window in the debugger, and under Symbol Status for my executable, it tells me "Cannot find or open the PDB file." I try to load it manually, and get the error, "A matching symbol file was not found in this folder."
I created a minimal (hello world) app, and I can debug that, so I'm able to reach the remote PC. Indeed, the app does start up and run on the remote system. So, it isn't an access issue.
Not sure what else to say about this, other than to show you my project debugging configuration:
Any ideas are MOST welcome. Thanks...
Well, I found the answer -- I needed to check the "deploy" box in the Configuration Manager window. This surprised me a little, as using the "deploy" command (available from right-clicking the project property) didn't do the trick. Evidently, there's some behind-the-scenes magic that takes place when the deploy box is checked.
This is a weird problem, which luckily (?) also happens on other machines.
I've never had problems with debugging, and now I have: it shows an exclamation mark at my breakpoints which says :'The debugging symbols are not loaded for this document'.
The difference with other projects is that I run this web application in IIS:
I've created a new website in IIS 7.5 (win7), listening on port 80 to
local.comparer.nl
I've added the url local.comparer.nl to my hosts
file, redirecting it to 127.0.0.1
I've edited the start page of the
project (asp.net 3.5) to local.comparer.nl in 'use local IIS
webserver'
When I start the site, it first says 'unable to start remote debugging'. I don't know why it looks for remote debugging, but when I started the remote debugging monitor, it still didn't work.
When I unloaded the debugging monitor, it didn't complain about the remote debugging anymore, but the exclamation mark still was there.
Solutions which -sometimes- help at my colleagues pc's:
Delete everything from the \bin directory and rebuild
Rebuild again (n number of times)
Choose 'clean solution'
Any idea?
Are you building full debugging symbols? If not then the debugger has no information to relate the source code to the in memory activity under the debugger. This is set in the project properties per configuration.
Also ensure the symbols are in the bin folder.
You can validate that VS is loading the right symbols with the Debug | Modules window.
I had this issue bothering me for quite long. Finally, what resolved my problem is :-
1) Make Internet Explorer the default browser
2) Clean the solution
3) Build the solution
In my case I renamed an asp.net page and disconnected the code behind. Strange it still ran but did not run the code behind and therefore did not hit breakpoints in it.
You have to in Visual Studio 2010
Select "Build" Meanu > Clean [Project/Solution Name]
Rebuild [Project/Solution]
Try debug again... Good luck
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 no idea how this started so I'm guessing there's a setting somewhere that I've been unable to find. I have a test that calls a method but when I run debug, it simply will NOT step into that dll. At all. Period. Throws an exception just fine, but it's kind of worthless when I can't step into see what's actually going on.
When another team member picks it up, he's able to debug the exact method I was attempting to target. Yes, same breakpoints, yes, same code (I checked in, he got it, ran just fine)
What the hell?
update : checked the test project for stupid entires, deleted the debug/release folders for fun, I've went though and dumped the project completely and got it back out of tfs. I've nuked the appdata/local/ms/vs/10.0 folder and the /appdata/roaming/ms/vs/10.0 folder. Deleted the local test results.
You probably need to investigate your project references. Is the DLL possibly GAC'd? Take a close look at the *.csproj file.
The fact that it can be debugged no problem on someone else's machine indicates to me that you're having an environment issue. Some sort of multiple library reference issue.
Another possibility: Visual Studio (and all its embedded tools) can have many strange caching behaviors. You might want to clear out extraneous MSTest-related temporary cache files/dirs.
Ok, got it. You can't do one of those things and it works. I had to do them all prior to opening up vstudio again. It'll blow your settings away just as a heads up.
Kill the AppData/Local/Microsoft/visualstudio/10.0 folder
Kill the AppData/Roaming/Microsoft/visualstudio/10.0 folder
Kill your entire project ... all of it.
Get latest (force)
And it works again.
Using Visual Studio 2010 beta, when I run my application within the IDE for debugging, it works perfectly the first time. However, after closing the debug session, either by closing the application or clicking the stop debugging button, all subsequent attempts to debug the application fail with:
Error 1 Unable to copy file "obj\Debug\Application.dll"
to
"bin\Debug\Application.dll".
The process cannot access the file
'bin\Debug\Application.dll'
because it is being used by another
process.
Handle.exe from SysInternals does show handles open, but even if I close the handles, the error doesn't go away. Any attempts to delete the file manually result in an "Access Denied" error message.
To fix this, I have to completely restart Visual Studio, afterwhich the Debug session will work once and stop again.
I'm not entirely sure when this started happening, but I'm pretty sure it's fairly recently.
UPDATE: After I force close the handles on Application.dll, I get the following error from VS:
Error 1 Unable to copy file
"obj\Debug\Application.dll"
to
"bin\Debug\Application.dll".
The requested operation cannot be
performed on a file with a user-mapped
section open.
What the heck is a "user-mapped section"??
UPDATE 2: It appears that this problem occurs when I have a Form open in Design view when trying to debug. I'm going to do some more troubleshooting and then post my results.
UPDATE 3: I think I've narrowed it down to a form using a UserControl.
To be honest with you, it sounds like a bug in VS2010. For some reason it isn't closing the open handles when the debugger stops. Killing the VS process automatically closes those handles, allowing you to access the file again. As a work around, you might look at unlocker it's free and works exceptionally well. I know that's not a great answer, but it should be faster than restarting VS. You might to consider sending a bug report too...
Unlocker doesn't work on 64-bit OS, LockHunter does though.
Here is how I solved this problem
*I open the project Properties,
*select the build tab,
*Clear the output path,
*and buid(this will create the dll in the root folder)
*come back to the output path and select browse(browse to the bin directory to either debug/release)and voila!
As per Error: Cannot access file bin/Debug/… because it is being used by another process answer by TarmoPikaro, sometimes Visual Studio creates multiple msbuild.exe ghost processes, which persist after build. These ghost processes seem to be causing file locks.
Solution 1 - Kill ghost MSBuild.exe's
Killing msbuild.exe's is a one time solution, it needs to be done per build basis.
You can kill the processes as follows mrtumnus:
taskkill /f /im MSBuild.exe
Solution 2 - Disable parallel builds in Visual Studio
You can disable parallel build once and for all:
Tools > Options > Projects and Solutions > Build and Run > "maximum numbers of parallel project builds" - by default it has value of 8, switch it to 1.
Of course builds are bit slower now, but mileage may vary depending on your use case.
This is related to
Error: Cannot access file bin/Debug/... because it is being used by another process
I've seen the Windows Indexing Service cause this. Disabling it helped. Virus scanners can also be at fault. Mutliple Application.Close() calls can supposedly cause this, too.
Of course, since it always works the first time, I suppose these are unlikely.
Had the same problem. The following things helped
Closing all design files while debugging
using unlocker
Also my application opens a port. While debugging an exception was thrown and program quit. While ending the program I closed the port. That helped too.
But definitely, bug with VS2010.
I encountered the same problem and in my case I had the file in question open in Visual Studio. Closing all files helped.
I faced the same error and I was stuck in it for many days. Finally resolved the issue.
I was working on a project that had many class libraries added in it. I added the reference of these libraries to my main project and mistakenly added reference to same project to itself. So when I removed self reference, it worked.
I had this issue myself. I had the project properties window open and that apparently creates a file lock. Even after I closed the window the file lock remained and I had to restart VS.
P.S. I'm using VS 2019. Just posting this for anyone having the issue I had and coming to this post.
If you get this error on VS Code;
Click on terminal screen and use "Ctrl + C" for stop running.